On Mon, Apr 11, 2011 at 10:29 AM, Noah Misch <noah@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