Re: Keeping separate WAL segments for each database

2010/6/30 Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
> Excerpts from Devrim GÜNDÜZ's message of mié jun 30 14:54:06 -0400 2010:
>
>> One of the things that interested me was parallel recovery feature. They
>> said that they are keeping separate xlogs for each database, which
>> speeds ups recovery in case of a crash. It also would increase
>> performance, since we could write xlogs to separate disks.
>
> I'm not sure about this. You'd need to have one extra WAL stream, for
> shared catalogs; and what would you do to a transaction that touches
> both shared catalogs and also local objects?  You'd have to split the
> WAL entries in those two WAL streams.
>
> I think you could try to solve this by having yet another WAL stream for
> transaction commit, and have the database-specific streams reference
> that one.  Operations touching shared catalogs would act as barriers:
> all other databases' WAL streams would have to be synchronized to that
> one.  This would still allow you to have some concurrency because,
> presumably, operations on shared catalogs are rare.

I think one per database and one extra one for the shared catalogs
would be enough. Most transactions would either touch either just the
database, or just the shared catalogs, so you'd write the commit
record in whichever stream was appropriate. If you had a transaction
that touched both, you'd write the commit record in both places, and
include in each stream a reference to the other stream. On replay,
when you reach a commit record that references the another stream, you
pause until the reference stream also reaches the matching commit
record. If you reach the end of that WAL stream without finding the
commit record, then, in archive recovery, you just keep waiting for
more of the stream to arrive; and, in crash recovery, you write a
matching commit record at the end of WAL.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company