On 01.12.2010 20:51, Heikki Linnakangas wrote:
> Another approach would be to revisit the way the running-xacts snapshot
> is taken. Currently, we first take a snapshot, and then WAL-log it.
> There is a small window between the steps where backends can begin/end
> transactions, and recovery has to deal with that. When this was
> designed, there was long discussion on whether we should instead grab
> WALInsertLock and ProcArrayLock at the same time, to ensure that the
> running-xacts snapshot represents an up-to-date situation at the point
> in WAL where it's inserted.
>
> We didn't want to do that because both locks can be heavily contended.
> But maybe we should after all. It would make the recovery code simpler.
>
> If we want to get fancy, we wouldn't necessarily need to hold both locks
> for the whole duration. We could first grab ProcArrayLock and construct
> the snapshot. Then grab WALInsertLock and release ProcArrayLock, and
> finally write the WAL record and release WALInsertLock. But that would
> require small changes to XLogInsert.
I took a look at that approach. We don't actually need to hold
ProcArrayLock while the WAL-record is written, we need to hold
XidGenLock. I believe that's less severe than holding the ProcArrayLock
as there's already precedence for writing a WAL record while holding
that: we do that when we advance to a new clog page and write a
zero-clog-page record.
So this is what we should do IMHO.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com