Re: page is uninitialized --- fixing
От | Simon Riggs |
---|---|
Тема | Re: page is uninitialized --- fixing |
Дата | |
Msg-id | 1244641007.4407.20.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: page is uninitialized --- fixing (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, 2009-06-09 at 17:28 -0400, Tom Lane wrote: > Is there any particular reason to suppose that the empty pages appeared > during a crash recovery? > > Have you read through md.c? I seem to recall there are some slightly > squirrelly choices made there about segment-extension behavior. Maybe > it could've done the wrong thing here during normal operation. The only way I can see this happening is 1. backup: pg_start_backup() 2. user1: creates temp table 3. user2: Vacuum causes partial truncation of table 4. backup: copies table's files 5. backup: pg_stop_backup() When we replay this, we do so with a base backup that starts recovering at XLogRecPtr of start_backup(), but using a file copied at a later XLogRecPtr. I don't see any way thru md.c that would allow reading a block beyond the end of the currently existing file (except in recovery). I'm fairly certain that this didn't happen because the table in question was pg_attribute and the main problem was that it had not been vacuumed for a very long time. Which leaves me perplexed. An erroneous value from file seek would lead to this though, so perhaps that is the easiest explanation: damage to file metadata in memory. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: