Thread: apparent wraparound
I see other posts on this log message before, but not clear to me how/if they apply to me. Opinions appreciated. I am on 8.1.3 on Linux. I have a log entry like this: 2006-11-08 12:38:34 PST [3739]: [3-1] LOG: could not truncate directory "pg_multixact/members": apparent wraparound Nothing troubling in the log before or after that. No other entries in the log for [3739]. The system is on autovacuum which seems to have run a little before and a little after this entry: 2006-11-08 12:37:52 PST [18388]: [1-1] LOG: autovacuum: processing database... ... 2006-11-08 12:38:55 PST [18406]: [1-1] LOG: autovacuum: processing database... The pg_multixact/members directory has files that are progressively newer: prddb0:postgres:~ ll data/pg_multixact/members/ -rw------- 1 postgres postgres 32768 Nov 10 15:08 0010 prddb0:postgres:~ ll data/pg_multixact/members/ -rw------- 1 postgres postgres 32768 Nov 10 15:13 0010 ... Anything I should be concerned about? What does this message mean? George
"George Pavlov" <gpavlov@mynewplace.com> writes:
> I am on 8.1.3 on Linux. I have a
> log entry like this:
> 2006-11-08 12:38:34 PST [3739]: [3-1] LOG: could not truncate directory
> "pg_multixact/members": apparent wraparound
During crash recovery? If so, probably nothing to worry about, per this
8.1.5 bug fix:
2006-07-19 20:46 tgl
* src/backend/access/transam/multixact.c (REL8_1_STABLE): Don't try
to truncate multixact SLRU files in checkpoints done during xlog
recovery. In the first place, it doesn't work because slru's
latest_page_number isn't set up yet (this is why we've been hearing
reports of strange "apparent wraparound" log messages during crash
recovery, but only from people who'd managed to advance their
next-mxact counters some considerable distance from 0). In the
second place, it seems a bit unwise to be throwing away data during
crash recovery anwyway. This latter consideration convinces me to
just disable truncation during recovery, rather than computing
latest_page_number and pushing ahead.
regards, tom lane
> During crash recovery? no crashes, just normal DB operation...
"George Pavlov" <gpavlov@mynewplace.com> writes:
>> During crash recovery?
> no crashes, just normal DB operation...
Hmm ... what is in pg_multixact/members/ again? And what do you get
from pg_controldata?
regards, tom lane
On Fri, 2006-11-10 at 15:21 -0800, George Pavlov wrote: > I see other posts on this log message before, but not clear to me how/if > they apply to me. Opinions appreciated. I am on 8.1.3 on Linux. I have a > log entry like this: > > 2006-11-08 12:38:34 PST [3739]: [3-1] LOG: could not truncate directory > "pg_multixact/members": apparent wraparound There is a thread here on it: http://archives.postgresql.org/pgsql-general/2006-03/msg00932.php -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
> "George Pavlov" <gpavlov@mynewplace.com> writes: > >> During crash recovery? > > no crashes, just normal DB operation... > > Hmm ... what is in pg_multixact/members/ again? Now there is only a file named 0010 the date on which changes about every 4-5 minutes or so. I only noticed the log even with a day+ delay so no idea what was there at the time of the log event. The DB has not been restarted since that log event though. Basically nothing abnormal in the DB operation that I know of around the "apparent wraparound" log entry and nothing since then... -rw------- 1 postgres postgres 32768 Nov 10 16:48 0010 > And what do you get from pg_controldata? Again this is as of right now, not when the log event happened: pg_control version number: 812 Catalog version number: 200510211 Database system identifier: 4904666118449586173 Database cluster state: in production pg_control last modified: Fri 10 Nov 2006 04:48:34 PM PST Current log file ID: 127 Next log file segment: 58 Latest checkpoint location: 7F/39B8A6F8 Prior checkpoint location: 7F/39142790 Latest checkpoint's REDO location: 7F/39B8A6F8 Latest checkpoint's UNDO location: 0/0 Latest checkpoint's TimeLineID: 1 Latest checkpoint's NextXID: 168755857 Latest checkpoint's NextOID: 25532444 Latest checkpoint's NextMultiXactId: 422733 Latest checkpoint's NextMultiOffset: 1056452 Time of latest checkpoint: Fri 10 Nov 2006 04:48:34 PM PST Maximum data alignment: 8 Database block size: 8192 Blocks per segment of large relation: 131072 Bytes per WAL segment: 16777216 Maximum length of identifiers: 64 Maximum columns in an index: 32 Date/time type storage: floating-point numbers Maximum length of locale name: 128 LC_COLLATE: en_US.UTF-8 LC_CTYPE: en_US.UTF-8
"George Pavlov" <gpavlov@mynewplace.com> writes:
>> "George Pavlov" <gpavlov@mynewplace.com> writes:
>>>>> 2006-11-08 12:38:34 PST [3739]: [3-1] LOG: could not truncate directory
>>>>> "pg_multixact/members": apparent wraparound
>>>> During crash recovery?
>>> no crashes, just normal DB operation...
>>
>> Hmm ... what is in pg_multixact/members/ again?
> Now there is only a file named 0010 the date on which changes about
> every 4-5 minutes or so.
AFAICS this must indicate that TruncateMultiXact() computed a bogus
oldestOffset, but it's hard to see how that would happen in the middle
of an unexceptional run. Alvaro, any ideas? Could there be a race
condition involved in filling in the "members" entries?
regards, tom lane