Re: pg_locks display of speculative locks is bogus

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Melanie Plageman <melanieplageman(at)gmail(dot)com>
Subject: Re: pg_locks display of speculative locks is bogus
Date: 2020-02-11 20:24:50
Message-ID: CAH2-Wz=bwOyKbD-BQCCV6tr24epPLCpeZg4v0r80B1Hwhuhpqg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 11, 2020 at 12:03 PM Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2020-02-11 20:37:14 Re: Portal->commandTag as an enum
Previous Message Shichao Jin 2020-02-11 20:19:07 Re: Memory-comparable Serialization of Data Types