From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Leonardo Francalanci <m_lists(at)yahoo(dot)it> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: switch UNLOGGED to LOGGED |
Date: | 2011-04-11 17:29:30 |
Message-ID: | 20110411172930.GA15891@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
nm
From | Date | Subject | |
---|---|---|---|
Next Message | Jesper Krogh | 2011-04-11 18:18:07 | Locking when concurrent updated of foreign references |
Previous Message | Tom Lane | 2011-04-11 16:35:02 | Re: Transforming IN (...) to ORs, volatility |