From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: page is uninitialized --- fixing |
Date: | 2009-06-10 13:36:47 |
Message-ID: | 1244641007.4407.20.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2009-06-10 13:43:43 | Re: pgindent run coming |
Previous Message | Merlin Moncure | 2009-06-10 13:15:57 | Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX |