On Mon, Apr 11, 2011 at 10:29 AM, Noah Misch <n...@leadboat.com> wrote:
> On Mon, Apr 11, 2011 at 11:41:18AM +0100, Leonardo Francalanci wrote:
>> > > But re-reading  it, I don't understand: what's the difference in creating
>> > > a new  "regular" table and crashing before emitting the abort record,
>> > > and  converting an unlogged table to logged and crashing before
>> > > emitting the  abort record? How do the standby servers handle a
>> > > "CREATE TABLE"  followed by a ROLLBACK if the master crashes
>> > > before writing the abort  record? I thought that too would "leave a
>> > > stray file around on a  standby".
>> >
>> > I've been thinking about the same thing.  And AFAICS, your  analysis is
>> > correct, though there may be some angle to it I'm not  seeing.
>> Anyone else? I would like to know if what I'm trying to do is, in fact,
>> possible... otherwise starting with thewal_level=minimal case first
>> will be wasted effort in case the other cases can't be integrated
>> somehow...
> If the master crashes while a transaction that used CREATE TABLE is 
> unfinished,
> both the master and the standby will indefinitely retain identical, stray (not
> referenced by pg_class) files.  The catalogs do reference the relfilenode of
> each unlogged relation; currently, that relfilenode never exists on a standby
> while that standby is accepting connections.  By the time the startup process
> releases the AccessExclusiveLock acquired by the proposed UNLOGGED -> normal
> conversion process, that relfilenode needs to be either fully copied or 
> unlinked
> all over again.  (Alternately, find some other way to make sure queries don't
> read the half-copied file.)  In effect, the problem is that the relfilenode is
> *not* stray, so its final state does need to be well-defined.

Oh, right.

Maybe we should just put in a rule that a server in Hot Standby mode
won't ever try to read from an unlogged table (right now we count on
the fact that there will be nothing to read).  If we crash before
copying the whole file, it won't matter, because the catalogs won't
have been updated, so we'll refuse to look at it anyway.  And we have
to reinitialize on entering normal running anyway, so we can clean it
up then.

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to