[RFC] GSoC Work on readonly queries done so far

Hi

This is a description of the GSoC work I've so for on readonly
support for PITR slaves. I'm looking for any kind of comments
on this - I want to make sure that I work in a direction that
the community approves.

Work done so far:
-----------------
.) Added a new GUC operational_mode, which can be set to either   readwrite or readonly. If it is set to readwrite (the
default),  postgres behaves as usual. All the following changes are only   in effect if operational_mode is set to
readonly.
.) Created a macro ASSUME_OPMODE_READWRITE that does elog(ERROR)   if postgre is not in readwrite mode. This macro
protectsthe   following functions to make sure that no writes occur in   readonly mode.     SimpleLruWritePage,
SLruPhysicalWritePage    EndPrepare, FinishPreparedTransaction     XLogInsert, XLogWrite, ShutdownXLog
CreateCheckpoint    MarkBufferDirty. .) All transactions are set to readonly mode (An implicit    SET TRANSACTION
READONLY),and are not allowed to do    SET TRANSACTION READWRITE. .) Don't start autovacuum and bgwriter. Instead of
bgwriter,bgreplay    is started, and it takes over that role that bgwriter play in the    shutdown process. .)
Transactionsare assigned a dummy xid ReadOnlyTransactionId, that    is considered to be "later" than any other xid. .)
Aglobal ReadOnlySnapshot is maintained in shared memory. This is    copied into backend local memory by
GetReadonlySnapshotData(which    replaces GetSnapshotData in readonly mode).  .) Crash recovery is not performed in
readonlymode - instead, postgres     PANICs, and tells the DBA to restart in readwrite mode. Archive     recovery of
course*will* be allowed, but I'm not that far yet.
 

Open Problems:
--------------  .) Protecting MarkBufferDirty with ASSUME_OPMODE_READWRITE is troublesome,     because callers usually
callMarkBufferDirty from within a critical     section, and thus elog(ERRROR) is turned into elog(PANIC). This e.g.
happenswith my patch if you call nextval() in readonly mode.     Does anyone see a better solution then adding checks
into    all callers that are not otherwise protected from being called     in readonly mode?  .) Since the slaves needs
totrack an Snapshot in shared memory, it cannot     resize that snapshot to accomodate however many concurrent
transactions    might have been running on the master. My current plan is to detect if     that global snapshot
overflows,and to lock out readonly queries on the     slave (and therefore remove the need of keeping the snapshot
current)    until the number of active xids on the master has dropped below     max_connections on the slave. A warning
willbe written to the postgres     log that suggest that the DBA increases the max_connections value on     the slave.
 

Please tell me what you think about this approach, and especially if you
see any problems that I overlooked.

greetings, Florian Pflug