Re: LVM snapshots
От | Murthy Kambhampaty |
---|---|
Тема | Re: LVM snapshots |
Дата | |
Msg-id | 2D92FEBFD3BE1346A6C397223A8DD3FC0921CC@THOR.goeci.com обсуждение исходный текст |
Ответ на | LVM snapshots ("Matt Clark" <matt@ymogen.net>) |
Ответы |
Re: LVM snapshots
|
Список | pgsql-admin |
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
В списке pgsql-admin по дате отправления: