[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 protects the
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.
.) Transactions are assigned a dummy xid ReadOnlyTransactionId, that
is considered to be "later" than any other xid.
.) A global 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 readonly mode - 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 call MarkBufferDirty from within a critical
section, and thus elog(ERRROR) is turned into elog(PANIC). This e.g.
happens with 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 to track 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 will be 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