Re: pg_locks display of speculative locks is bogus - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: pg_locks display of speculative locks is bogus
Date
Msg-id CAH2-Wz=bwOyKbD-BQCCV6tr24epPLCpeZg4v0r80B1Hwhuhpqg@mail.gmail.com
Whole thread Raw
In response to pg_locks display of speculative locks is bogus  (Andres Freund <andres@anarazel.de>)
Responses Re: pg_locks display of speculative locks is bogus
List pgsql-hackers
On Tue, Feb 11, 2020 at 12:03 PM Andres Freund <andres@anarazel.de> wrote:
> Doesn't seem great.
>
> It's trivial to put the xid in the correct place, but it's less obvious
> what to do with the token? For master we should probably add a column,
> but what about the back branches? Ignore it? Put it in classid or such?

My vote goes to doing nothing about the token on the back branches.
Just prevent bogus pg_locks output.

Nobody cares about the specifics of the token value -- though perhaps
you foresee a need to have it for testing purposes. I suppose that
adding a column to pg_locks on the master branch is the easy way of
resolving the situation, even if we don't really expect anyone to use
it.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Shichao Jin
Date:
Subject: Re: Memory-comparable Serialization of Data Types
Next
From: Mark Dilger
Date:
Subject: Re: Portal->commandTag as an enum