Prev: [HACKERS] Move tablespace
Next: pgsql: Tune GetSnapshotData() duringHot Standby by avoiding loop
From: Robert Haas on 19 Apr 2010 07:55
On Mon, Apr 19, 2010 at 5:05 AM, Simon Riggs <simon(a)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?

....Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 19 Apr 2010 10:24
Robert Haas <robertmhaas(a)gmail.com> writes:
> On Mon, Apr 19, 2010 at 5:05 AM, Simon Riggs <simon(a)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 ...

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 19 Apr 2010 10:55
Simon Riggs <simon(a)2ndQuadrant.com> writes:
> On Mon, 2010-04-19 at 17:44 +0300, Heikki Linnakangas wrote:
>>> 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
>>
>> 4. Check RecoveryInProgress() once outside of lock, and scan the
>> ProcArray anyway, just in case. That's what we did before this patch.
>> Document that takenDuringRecovery == true means that the snapshot was
>> most likely taken during recovery, but there is some race conditions
>> where takenDuringRecovery is true even though the snapshot was taken
>> just after recovery finished. AFAICS all of the other current uses of
>> takenDuringRecovery work fine with that.

> Checking RecoveryInProgress() is much cheaper than scanning the whole
> ProcArray, so (4) is definitely worse than 1-3.

If the lock we're talking about is an LWLock, #3 is okay. If it's a
spinlock, not so much.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: [HACKERS] Move tablespace
Next: pgsql: Tune GetSnapshotData() duringHot Standby by avoiding loop