Re: Proposal for Implenting read-only queries during wal replay (SoC 2007)

Heikki Linnakangas wrote:
> Florian G. Pflug wrote:
>> I plan to submit a proposal for implementing support for
>> read-only queries during wal replay as a "Google Summer of Code 2007"
>> project.
>>
>> I've been browsing the postgres source-code for the last few days,
>> and came up with the following plan for a implementation.
>>
>> I'd be very interested in any feedback on the propsoal - especially
>> of the "you overlooked this an that, it can never work that way" kind ;-)
> 
> I had the same thought roughly two years ago:
> 
> http://archives.postgresql.org/pgsql-hackers/2005-11/msg01043.php
> 
> People weren't very interested in having a read-only mode. I think it 
> would be a nice feature if it's not too complicated.

I think "main" feature would be supporting read-only queries on PITR
slaves. But creating a read-only mode seemed to me (and to you too, it
seems ;-) ) like a good first step towards that goal.

After reading tom's reply to your original proposal, I agree that
supporting a write-protected datadir is not a true subset of
supporting read-only queries on PITR slaves. But I still think
that tackling the read-only datadir support is a good first step -
not the least because it'll help me to get familiar with the
relevent parts of the backend.

I've been thinking about your "trick" of writing "readonly" into
the postmaster.pid file to switch postgres into read-only mode.
On the one hand, it's really neat - if solves the problem of not
being able to create a pid file in the datadir in ro mode, while
on the other hand making sure that there *is* a pid file. But
if I went that way, it would mean there would be *three* configfiles
you have to get right for a working PITR slave with read-only query
support - postgresql.conf, recovery.conf, and postmaster.pid.

So I think I'll rather go with a postgresql.conf setting. I'd
allow three values "hard", "soft" and "off".
"hard" would prevent all writes to the datadir, while
"soft" would be the setting of choice for a PITR slave.

In the "soft" case, postgres would still write a postmaster.pid,
and so be protected against other running postmasters.
In the "hard" case, there would be no such protection - but since
there would be no writes anyway, you don't risk data corruption
in case another postmaster was running - the worst the would happen
is that the read-only postmaster crashes.

greetings, Florian Pflug