Thomas Munro wrote: > Thanks. As mentioned elsewhere in the thread, I discovered that the > same problem exists for page boundaries, with a different error > message. I've tried the attached repro scripts on 9.3.0, 9.3.5, 9.4.1 > and master with the same results: > > FATAL: could not access status of transaction 2048 > DETAIL: Could not read from file "pg_multixact/offsets/0000" at > offset 8192: Undefined error: 0. > > FATAL: could not access status of transaction 131072 > DETAIL: Could not open file "pg_multixact/offsets/0002": No such file > or directory. So I checked this bug against current master, because it's claimed to be closed. The first script doesn't emit a message at all; the second script does emit a message: LOG: could not truncate directory "pg_multixact/offsets": apparent wraparound If you start and stop again, there's no more noise in the logs. That's pretty innocuous -- great. But then I modified your script to do two segments instead of one. Then after the second cycle is done, start the server and stop it again. The end result is a bit surprising: you end up with no files in pg_multixact/offsets at all! I applied Andres' patch to WAL-log truncations and rerun the test, and the files do not automatically disappear anymore. So after that patch we might be fine, although I'd like to actually understand the failure mode here to see whether it's actually fixed. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment:
checkpoint-segment-boundary.sh
Description: Bourne shell script
-- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
