[RFC] GSoC Work on readonly queries done so far

From: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
To: Postgresql-Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: [RFC] GSoC Work on readonly queries done so far
Date: 2007-06-06 14:11:13
Message-ID: 4666C081.6050307@phlo.org
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers


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


Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2007-06-06 14:14:14 Re: Controlling Load Distributed Checkpoints
Previous Message Heikki Linnakangas 2007-06-06 13:19:12 Controlling Load Distributed Checkpoints