| From: | Takeshi Ideriha <iderihatakeshi(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Zhijie Hou <houzhijie22(at)gmail(dot)com>, shihao zhong <zhong950419(at)gmail(dot)com>, 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-22 04:55:50 |
| Message-ID: | 31ce67ec-f31a-4e8d-89e5-833fbb4c648a@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 2026/10/22 12:13, Michael Paquier wrote:
> Yeah, I don't think that we should begin using SetHintBits() outside> of
heapam_visibility.c when it comes down to heap as a table AM.
Sure, thank you for the reply.
>> However, it would still be another API violation, wouldn't it? We also
>> needs to figure out the multixact race issue. I'm trying to look into
>> multixact part as much as possible.
>
> What do you think about the first SetHintBits() added for the
> subtransaction aborted case? This one seems acceptable here, by
> itself..
+1 for this. Setting the hint bit for the aborted subtransaction inside
HeapTupleSatisfiesVacuumHorizon is safe and not harmful for the
performance.
Regards,
Takeshi Ideriha
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2026-10-22 05:42:51 | BUG #19788: Chinese translation uses incorrect term for “transaction” in “no transaction is in progress” |
| Previous Message | Michael Paquier | 2026-10-22 04:22:09 | Re: BUG #19763: ManualBug2 NULL pointer dereference in make_build_data via examine_expression bypass of lookup_var_a |