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.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers