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
|
Список | 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 по дате отправления: