Re: logical decoding - GetOldestXmin

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: logical decoding - GetOldestXmin
Дата
Msg-id 20121216145541.GF4683@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: logical decoding - GetOldestXmin  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
On 2012-12-15 01:19:26 +0100, Andres Freund wrote:
> On 2012-12-14 14:01:30 -0500, Robert Haas wrote:
> > On Fri, Dec 14, 2012 at 6:46 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> > > Just moving that tidbit inside the lock seems to be the pragmatic
> > > choice. GetOldestXmin is called
> > >
> > > * once per checkpoint
> > > * one per index build
> > > * once in analyze
> > > * twice per vacuum
> > > * once for HS feedback messages
> > >
> > > Nothing of that occurs frequently enough that 5 instructions will make a
> > > difference. I would be happy to go an alternative path, but right now I
> > > don't see any nice one. A "already_locked" parameter to GetOldestXmin
> > > seems to be a cure worse than the disease.
> >
> > I'm not sure that would be so bad, but I guess I question the need to
> > do it this way at all.  Most of the time, if you need to advertise
> > your global xmin, you use GetSnapshotData(), not GetOldestXmin(), and
> > I guess I'm not seeing why that wouldn't also work here.  Am I dumb?
>
> I wondered upthread whether that would be better:
>
> On 2012-12-13 21:03:44 +0100, Andres Freund wrote:
> > Another alternative to this would be to get a snapshot with
> > GetSnapshotData(), copy the xmin to the logical slot, then call
> > ProcArrayEndTransaction(). But that doesn't really seem to be nicer to
> > me.
>
> Not sure why I considered it ugly anymore, but it actually has a
> noticeable disadvantage. GetOldestXmin is nicer is than GetSnapshotData
> as the latter set a fairly new xid as xmin whereas GetOldestXmin returns
> the actual current xmin horizon. Thats preferrable because it allows us
> to start up more quickly. snapbuild.c can only start building a snapshot
> once it has seen a xl_running_xact with oldestRunningXid >=
> own_xmin. Otherwise we cannot be sure that no relevant catalog tuples
> have been removed.

Hm. One way that could work with fewer changes is to exploit the fact
that a) it seems to be possible to acquire a shared lwlock twice in the
same backend and b) both GetOldestXmin & GetSnapshotData acquire only a
shared lwlock.

Are we willing to guarantee that recursive acquiration of shared lwlocks
continues to work?

Greetings,

Andres Freund

--Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Set visibility map bit after HOT prune
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Assert for frontend programs?