On August 19, 2014 10:24:20 PM CEST, Jeff Janes jeff.ja...@gmail.com wrote:
On Tue, Jul 15, 2014 at 3:58 PM, Jeff Janes jeff.ja...@gmail.com
wrote:
On Fri, Jun 27, 2014 at 11:51 AM, Alvaro Herrera
alvhe...@2ndquadrant.com
wrote:
Jeff Janes wrote:
This problem was initially fairly easy to reproduce, but since I
started adding instrumentation specifically to catch it, it has
become
devilishly hard to reproduce.
I think my next step will be to also log each of the values which
goes
into the complex if (...) expression that decides on the deletion.
Could you please to reproduce it after updating to latest? I pushed
fixes that should close these issues. Maybe you want to remove the
instrumentation you added, to make failures more likely.
There are still some problems in 9.4, but I haven't been able to
diagnose
them and wanted to do more research on it. The announcement of
upcoming
back-branches for 9.3 spurred me to try it there, and I have problems
with
9.3 (12c5bbdcbaa292b2a4b09d298786) as well. The move of truncation
to the
checkpoint seems to have made the problem easier to reproduce. On an
8
core machine, this test fell over after about 20 minutes, which is
much
faster than it usually reproduces.
This the error I get:
2084 UPDATE 2014-07-15 15:26:20.608 PDT:ERROR: could not access
status of
transaction 85837221
2084 UPDATE 2014-07-15 15:26:20.608 PDT:DETAIL: Could not open file
pg_multixact/members/14031: No such file or directory.
2084 UPDATE 2014-07-15 15:26:20.608 PDT:CONTEXT: SQL statement
SELECT 1
FROM ONLY public.foo_parent x WHERE id OPERATOR(pg_catalog.=)
$1 FOR
KEY SHARE OF x
The testing harness is attached as 3 patches that must be made to the
test
server, and 2 scripts. The script do.sh sets up the database (using
fixed
paths, so be careful) and then invokes count.pl in a loop to do the
actual work.
Sorry, after a long time when I couldn't do much testing on this, I've
now
been able to get back to it.
It looks like what is happening is that checkPoint.nextMultiOffset
wraps
around from 2^32 to 0, even if 0 is still being used. At that point it
starts deleting member files that are still needed.
Is there some interlock which is supposed to prevent from
checkPoint.nextMultiOffset rom lapping iself? I haven't been able to
find
it. It seems like the interlock applies only to MultiXid, not the
Offset.
There is none (and there never has been one either). I've complained about it a
couple of times but nobody, me included, had time and energy to fix that :(
Andres
---
Please excuse brevity and formatting - I am writing this on my mobile phone.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
