On 04/01/2014 08:39 PM, Heikki Linnakangas wrote:
On 03/07/2014 05:36 AM, Tom Lane wrote:
=?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= <fabriziome...@gmail.com> writes:
Do you think is difficult to implement "ALTER TABLE ... SET UNLOGGED" too?
Thinking in a scope of one GSoC, of course.
I think it's basically the same thing. You might hope to optimize it;
but you have to create (rather than remove) an init fork, and there's
no way to do that in exact sync with the commit.
You just have to include that information with the commit WAL record, no?
No-one's replied yet, but perhaps the worry is that after you've written
the commit record, you have to go ahead with removing/creating the init
fork, and that is seen as too risky. If a creat() or unlink() call
fails, that will have to be a PANIC, and crash recovery will likewise
have to PANIC if the forks still cannot be removed/created.
My first thought is that that seems ok. It's unlikely that an unlink()
of a small file in the data directory would fail. Creation could be done
with a temporary name first and renamed into place, to avoid running out
of disk space in the critical section.
If that's not acceptable, one idea off the top of my head is to somehow
stamp the init forks when making an unlogged table logged, with the XID
of the transcation. Crash recovery could then check the clog to see if
the transaction committed, and ignore any init fork files belonging to
committed transactions. (Same in reverse when making a logged table
unlogged).
Currently, we reset unlogged relations before replaying the WAL. That
would have to be delayed until end of WAL replay, because otherwise we
don't know if the transaction committed or not. Although if we go with
the stamping approach, we could still reset unstamped files at the
beginning of recovery.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
