Re: Why we lost Uber as a user
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: hannu@2ndQuadrant.com, Josh Berkus <josh@agliodbs.com>,
"Joshua D. Drake" <jd@commandprompt.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2016-08-01T14:00:21Z
Lists: pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes: > * Hannu Krosing (hkrosing@gmail.com) wrote: >> Is there any theoretical obstacle which would make it impossible to >> teach VACUUM not to hold back the whole vacuum horizon, but just >> to leave a single transaction alone in case of a long-running >> REPEATABLE READ transaction ? > I've looked into this a couple of times and I believe it's possible to > calculate what records have to remain available for the long-running > transaction, but it's far from trivial. I think it'd become a lot easier if we went over to representing snapshots as LSN positions (and, concomitantly, had an inexpensive way to translate XIDs to their commit LSNs). That would mean that (1) a backend's snapshot state could be fully exposed in PGPROC, at least up to some small number of active snapshots; (2) it'd be fairly cheap for VACUUM to detect that a dead tuple's XMIN and XMAX are either both before or both after each live snapshot. Someone (Heikki, I think) has been working on this but I've not seen any patch yet. regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Advance backend's advertised xmin more aggressively.
- 94028691609f 9.5.0 cited
-
Improve snapshot manager by keeping explicit track of snapshots.
- 5da9da71c44f 8.4.0 cited