Re: page is uninitialized --- fixing

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

In response to

Browse pgsql-hackers by date

  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