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

Re: [RFC] GSoC Work on readonly queries done so far

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
Cc: Postgresql-Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [RFC] GSoC Work on readonly queries done so far
Date: 2007-06-06 16:54:59
Message-ID: 1181148899.7660.135.camel@dogma.v10.wvs (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, 2007-06-06 at 16:11 +0200, Florian G. Pflug wrote:
>    .) 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.

If we did lock the slave while waiting for transactions to complete on
the master, we'd need to document some stronger warnings against idle
transactions so that administrators could notice and correct the

Are you referring to the size of the xip array being a problem? Would it
help to tie the size of the xip array to max_connections? I understand
that max_connections might be greater on the master, but maybe something

	Jeff Davis

In response to


pgsql-hackers by date

Next:From: Florian G. PflugDate: 2007-06-06 17:18:45
Subject: Re: [RFC] GSoC Work on readonly queries done so far
Previous:From: Tom LaneDate: 2007-06-06 16:47:13
Subject: Re: elog.c logic bug?

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