From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | hannu(at)2ndQuadrant(dot)com, Josh Berkus <josh(at)agliodbs(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Why we lost Uber as a user |
Date: | 2016-08-01 14:00:21 |
Message-ID: | 3706.1470060021@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Hannu Krosing (hkrosing(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2016-08-01 14:07:19 | Re: No longer possible to query catalogs for index capabilities? |
Previous Message | Stephen Frost | 2016-08-01 13:29:31 | Re: Why we lost Uber as a user |