Re: [PATCH] 2PC state files on shared memory

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Aug 8, 2009 at 9:31 AM, Heikki
> Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> I'm a bit disappointed by the performance gains. I would've expected
>> more, given a decent battery-backed-up cache to buffer the WAL fsyncs.

> It doesn't seem that surprising to me that a write to shared memory
> and a write to an un-fsync'd file would be about the same speed.

I just had a second thought about this. The idea is to avoid writing
the separate 2PC state file until/unless it has to be checkpointed.
(And, per the comments for CheckPointTwoPhase, that is an uncommon
case --- especially now with our time-extended checkpoints.)

What if PREPARE simply didn't write the 2PC file at all, except into WAL?
Then, make CheckPointTwoPhase write the 2PC file for any still-live
GXACT, by means of reaching into the WAL and pulling the data out.
All it would need for that is the LSN of the WAL record, which I think
the GXACT has already. (It might have the end location rather than
the start, but in any case we could store both.) Similarly, COMMIT
PREPARED could be taught to pull the data from WAL instead of a 2PC
file, in the typical case where the file didn't exist yet. I think
there might be some synchronization issues against checkpoints --- you
couldn't recycle WAL until you were sure there was no COMMIT PREPARED
pulling from it. But it seems possibly workable, and there's no tuning
knob needed.

regards, tom lane