| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Takeshi Ideriha <iderihatakeshi(at)gmail(dot)com> |
| 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 03:13:09 |
| Message-ID: | atl_RW26JlkZcTGb@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Thu, Oct 22, 2026 at 11:53:29AM +0900, Takeshi Ideriha wrote:
> Thank you for sorting the issue out and setting the direction. I was
> thinking of leaving first SetHintBits() in
> HeapTupleSatisfiesVacuumHorizon() and moving the second SetHintBits() to
> heapam_relation_copy_for_cluster() to solve the performance issue.
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.
> 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..
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Manu | 2026-10-22 03:22:00 | Re: BUG #19705: One NaN box makes a BRIN box_inclusion_ops index omit unrelated rows |
| Previous Message | Michael Paquier | 2026-10-22 03:09:56 | Re: pg_stat_statements stores WITH HOLD cursor query with literals |