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
