| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Joel Jacobson <joel(at)compiler(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue |
| Date: | 2025-11-04 14:44:28 |
| Message-ID: | 515740.1762267468@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> Fortunately that's easy to fix: We can move the IsListeningOn() check
> after releasing the lock. See attached.
> The elephant in the room of course is that a lookup in a linked list is
> O(n) and it would be very straightforward to replace it with e.g. a hash
> table. We should do that irrespective of this bug fix. But I'm inclined
> to do it as a separate followup patch.
There is a different patch series that's concerned with improving
NOTIFY throughput [1]. I think this one should just focus on
fixing the XID problem.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrei Lepikhov | 2025-11-04 14:46:35 | Re: MergeAppend could consider sorting cheapest child path |
| Previous Message | Arseniy Mukhin | 2025-11-04 14:40:31 | Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue |