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
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 |