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
 .) All transactions are set to readonly mode (An implicit
    SET TRANSACTION READONLY), and are not allowed to do
 .) 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

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to