On Fri, Nov 18, 2022 at 9:13 AM Andres Freund wrote:
> Agreed. I had started on a set of patches for some of the SHM_QUEUE uses, but
> somehow we ended up a bit stuck on the naming of dlist_delete variant that
> afterwards zeroes next/prev so we can replace SHMQueueIsDetached() uses.
>
> Should pr
Andres Freund writes:
> On 2022-11-17 14:20:47 -0500, Robert Haas wrote:
>> Not that I object to a targeted fix
> Should we backpatch this fix? Likely this doesn't cause active breakage
> outside of 32bit builds under ubsan, but that's not an unreasonable thing to
> want to do in the backbranches
Hi,
On 2022-11-17 14:20:47 -0500, Robert Haas wrote:
> On Wed, Nov 16, 2022 at 8:42 PM Andres Freund wrote:
> > Afaict the problem is that
> > proc = (PGPROC *) &(waitQueue->links);
> >
> > is a gross gross hack - this isn't actually a PGPROC, it's pointing to an
> > SHM_QUEUE, bu
On Wed, Nov 16, 2022 at 8:42 PM Andres Freund wrote:
> Afaict the problem is that
> proc = (PGPROC *) &(waitQueue->links);
>
> is a gross gross hack - this isn't actually a PGPROC, it's pointing to an
> SHM_QUEUE, but *not* one embedded in PGPROC. It kinda works because ->links
>
Hi,
On 2022-11-16 17:42:30 -0800, Andres Freund wrote:
> Afaict the problem is that
> proc = (PGPROC *) &(waitQueue->links);
>
> is a gross gross hack - this isn't actually a PGPROC, it's pointing to an
> SHM_QUEUE, but *not* one embedded in PGPROC. It kinda works because ->links
>
