From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Rework the way multixact truncations work |
Date: | 2015-12-09 16:20:51 |
Message-ID: | 20151209162051.GK28762@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2015-12-09 11:18:39 -0500, Robert Haas wrote:
> If I correctly understand the scenario that you are describing, that
> does happen - not for the same MXID, but for different ones. At least
> the last time I checked, and I'm not sure if we've fixed this, it
> could happen because the SLRU page that contains the multixact wasn't
> flushed out of the SLRU buffers yet.
That should be fixed, with the brute force solution of flushing buffers
before searching for files on disk.
> But apart from that, it could
> happen any time there's a gap in the sequence of files, and that sure
> doesn't seem like a can't-happen situation. We know that, on 9.3,
> there's definitely a sequence of events that leads to a 0000 file
> followed by a gap followed by the series of files that are still live.
> Given the number of other bugs we've fixed in this area, I would not
> like to bet on that being the only scenario where this crops up. It
> *shouldn't* happen, and as far as we know, if you start and end on a
> version newer than 4f627f8 and aa29c1c, it won't. Older branches,
> though, I wouldn't like to bet on.
Ok, fair enough.
andres
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-12-09 16:32:55 | Re: Foreign join pushdown vs EvalPlanQual |
Previous Message | Robert Haas | 2015-12-09 16:18:39 | Re: Rework the way multixact truncations work |