Re: pg_locks display of speculative locks is bogus

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: pg_locks display of speculative locks is bogus
Дата
Msg-id CAH2-Wz=bwOyKbD-BQCCV6tr24epPLCpeZg4v0r80B1Hwhuhpqg@mail.gmail.com
обсуждение исходный текст
Ответ на pg_locks display of speculative locks is bogus  (Andres Freund <andres@anarazel.de>)
Ответы Re: pg_locks display of speculative locks is bogus  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Shichao Jin
Дата:
Сообщение: Re: Memory-comparable Serialization of Data Types
Следующее
От: Mark Dilger
Дата:
Сообщение: Re: Portal->commandTag as an enum