Re: tracking commit timestamps

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: tracking commit timestamps
Дата
Msg-id 20141201223413.GH1737@alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: tracking commit timestamps  (Petr Jelinek <petr@2ndquadrant.com>)
Ответы Re: tracking commit timestamps  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: tracking commit timestamps  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Petr Jelinek wrote:
> On 25/11/14 16:30, Alvaro Herrera wrote:
> >Petr Jelinek wrote:
> >>On 25/11/14 16:23, Alvaro Herrera wrote:
> >>>Robert Haas wrote:
> >
> >>>>Maybe 0 should get translated to a NULL return, instead of a bogus timestamp.
> >>>
> >>>That's one idea --- surely no transaction is going to commit at 00:00:00
> >>>on 2000-01-01 anymore.  Yet this is somewhat discomforting.
> >>
> >>I solved it for xids that are out of range by returning -infinity and then
> >>changing that to NULL in sql interface, but no idea how to do that for
> >>aborted transactions.
> >
> >I guess the idea is that we just read the value from the slru and if it
> >exactly matches allballs we do the same -infinity return and translation
> >to NULL.  (Do we really love this -infinity idea?  If it's just an
> >internal API we can use a boolean instead.)
>
> As in returning boolean instead of void as "found"? That works for me
> (for the C interface).

Petr sent me privately some changes to implement this idea.  I also
reworked the tests so that they only happen on src/test/modules (getting
rid of the one in core regress) and made them work with both enabled and
disabled track_commit_timestamps; in make installcheck, they pass
regardless of the setting of the installed server, and in make check,
they run a server with the setting enabled.

I made two more changes:
1. introduce newestCommitTs.  Original code was using lastCommitXact to
check that no "future" transaction is asked for, but this doesn't really
work if a long-running transaction is committed, because asking for
transactions with a higher Xid but which were committed earlier would
raise an error.

2. change CommitTsControlLock to CommitTsLock as the lock that protects
the stuff we keep in ShmemVariableCache.  The Control one is for SLRU
access, and so it might be slow at times.  This is important because we
fill the checkpoint struct from values protected by that lock, so a
checkpoint might be delayed if it happens to land in the middle of a
slru IO operation.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Adam Brightwell
Дата:
Сообщение: Re: Role Attribute Bitmask Catalog Representation
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: [Windows,PATCH] Use faster, higher precision timer API