| From: | Takeshi Ideriha <iderihatakeshi(at)gmail(dot)com> |
|---|---|
| To: | shihao zhong <zhong950419(at)gmail(dot)com> |
| Cc: | Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>, alpkeles99(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19760: CLUSTER loses a row the transaction inserted and then updated in a rolled-back subtransaction |
| Date: | 2026-10-20 02:32:44 |
| Message-ID: | 949ad7b3-2b0e-40dc-b6ac-e84da432149b@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hi Shihao
>> So I believe we can just rely on HeapTupleHeaderXminInvalid hint bit.
>
> I tried it and it keeps the row in both cases. But it also needs the
> logical_rewrite_heap_tuple() call in end_heap_rewrite(). Without it,
> logical decoding after VACUUM FULL pg_class fails:
>
> ERROR: could not map filenumber "base/16490/16491" to relation OID
>
Thank you for replying. Glad to know it worked for both two cases.
Regarding logical_rewrite_heap_tuple() part, you are completely right. I
tested by myself yesterday and hit the same error while decoding the
vacuum full scenario. Thank you for pointing out. I was not aware of DDL
case with logical replication.
Regards,
Takeshi Ideriha
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2026-10-20 02:54:53 | BUG #19773: pg_dump omits a different generation expression of an inherited column in a child table |
| Previous Message | shihao zhong | 2026-10-20 02:22:21 | Re: BUG #19760: CLUSTER loses a row the transaction inserted and then updated in a rolled-back subtransaction |