Tom Lane wrote: > Michael Paquier <michael.paqu...@gmail.com> writes: >> Based on an idea of Heikki Linnakangas, here is a patch in order to improve >> 2PC >> by sending the state files of prepared transactions to shared memory instead >> of disk. > > I don't understand how this can possibly work. The entire point of > 2PC is that the state file is guaranteed to be on disk so it will > survive a crash. What good is it if it's in shared memory?
The state files are not fsync'd when they're written, but a copy is written to WAL so that it can be replayed on crash. With this patch, it's still written to WAL, but the write to a file on disk is skipped, and it's stored in shared memory instead. > Quite aside from that, the fixed size of shared memory makes this seem > pretty impractical. Most state files are small. If one doesn't fit in the area reserved for this, it's written to disk as usual. It's just an optimization. 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. But it looks like they're still causing the most overhead, even with a battery-backed-up cache. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
