Re: Re: [COMMITTERS] pgsql: Tune GetSnapshotData() during Hot Standby by avoiding loop - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Re: [COMMITTERS] pgsql: Tune GetSnapshotData() during Hot Standby by avoiding loop
Date
Msg-id 1271687489.8305.18879.camel@ebony
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Tune GetSnapshotData() during Hot Standby by avoiding loop  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: [COMMITTERS] pgsql: Tune GetSnapshotData() during Hot Standby by avoiding loop  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
On Mon, 2010-04-19 at 10:24 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Mon, Apr 19, 2010 at 5:05 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> >> It doesn't seem to be something we should place highly on the list of
> >> events we need protection from, does it?
> 
> > Since when do we not protect against race-conditions just because
> > they're low likelihood?
> 
> Murphy's law says that the probability of any race condition happening
> in the field is orders of magnitude higher than you think.  This has
> been proven true many times ...

Choices are

1. Check RecoveryInProgress() once outside of lock, plus wild rumour of
Murphy

2. Check RecoveryInProgress() before and after holding lock

3. Check RecoveryInProgress() while holding lock

All of which perform better than

4. Revert patch

-- Simon Riggs           www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: shared_buffers documentation
Next
From: Heikki Linnakangas
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Tune GetSnapshotData() during Hot Standby by avoiding loop