| From: | Antonin Houska <ah(at)cybertec(dot)at> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Treat <rob(at)xzilla(dot)net> |
| Subject: | Re: Adding REPACK [concurrently] |
| Date: | 2026-03-19 20:37:35 |
| Message-ID: | 34692.1773952655@localhost |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> So here's v43. Here, I've changed the CONCURRENTLY implementation to go
> through table AM. This necessitated changing it to use tuples in slots
> instead of HeapTuple. This is good because we can avoid repeated tuple
> form/deform, which could get pretty expensive. Antonin's 0004 patch
> here looks suspicious here though, because it deforms the tuple and
> forms it again, which sounds unnecessary now.
I suppose you mean
v42-0004-Serialize-decoded-tuples-without-flattening.patch. This deforms the
tuple to get the external attributes and to write them to file. The tuple the
logical worker received from reorderbuffer.c cannot be passed to the backend
executing REPACK because it may contain "external indirect" attributes,
i.e. pointers to the worker's memory.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2026-03-19 20:38:23 | Re: pg_plan_advice |
| Previous Message | Mahendra Singh Thalor | 2026-03-19 20:30:33 | Re: pg_restore: TAP test case typo(wrong word) for an error hint in 001_basic.pl |