Skip site navigation (1) Skip section navigation (2)

[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: (view raw, whole thread or download thread 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


pgsql-hackers by date

Next:From: Gregory StarkDate: 2007-06-06 14:14:14
Subject: Re: Controlling Load Distributed Checkpoints
Previous:From: Heikki LinnakangasDate: 2007-06-06 13:19:12
Subject: Controlling Load Distributed Checkpoints

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group