Re: logical decoding - GetOldestXmin
Andres Freund <andres@2ndquadrant.com>
From: Andres Freund <andres@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, Peter Geoghegan <peter@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2012-12-16T14:55:41Z
Lists: 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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Background worker processes
- da07a1e85651 9.3.0 cited
-
Rearrange storage of data in xl_running_xacts.
- 5c11725867ac 9.3.0 cited
-
Basic binary heap implementation.
- 7a2fe9bd0371 9.3.0 cited
-
Embedded list interface
- a66ee69add6e 9.3.0 cited
-
Refactor xlog.c to create src/backend/postmaster/startup.c
- 9aceb6ab3c20 9.2.0 cited