A checkpoint process may have to be ongoing when the snapshot creation
(filesystem freeze) occurs, for this situation to arise. (Reduce the
checkpoint segments and interval to test.)
-----Original Message-----
From: Murthy Kambhampaty
Sent: Friday, April 04, 2003 10:09
To: 'Tom Lane'; Matt Clark
Cc: Murthy Kambhampaty; 'Peter Eisentraut'; pgsql-admin@postgresql.org
Subject: RE: [ADMIN] LVM snapshots
Tom Lane [mailto:tgl@sss.pgh.pa.us] writes:
>>> NOTICE: Rel <table name>: Uninitialized page 54300 - fixing
>
>There is a known mechanism for this to occur on certain key system
catalogs,
>see http://fts.postgresql.org/db/mw/msg.html?mid=1357214
>
>We've seen some reports suggesting it can happen on user tables too, but
>I don't know what the mechanism is or whether there's any risk of data
>loss. If you can make this happen reproducibly (or at least with decent
>probability) on tables other than pg_class, pg_type, pg_attribute, pg_proc,
>then I'd be real interested to see a test case.
>
>
The tables on which this happened were the ones called tbl2 and tbl3 in my
example: i.e., tables into which data were being added with "insert into
tbl[1,2] from select * from tbl1 where ..." running in parallel subshells.
If somebody wants to try to replicate this:
1. Create a table with several hundred thousand records
2. Start an "insert into tbl2 from select ..." (multiple ones in parallel
maximize your chance of hitting this)
3. Freeze the filesystem, create a snapshot, unfreeze the filesystem, mount
the snapshot and copy $PGDATA somewhere else
4. Start a postmaster on the copy of the database cluster; run VACUUM
ANALYZE on tlb2
you should see a series of
NOTICE: Rel tbl2: Uninitialized page 'nnnnn' - fixing
messages
I might have a chance to play with this late next but right now I'm swamped.
Cheers,
Murthy
