Re: Re: [COMMITTERS] pgsql: Tune GetSnapshotData() during Hot Standby by avoiding loop
От | Simon Riggs |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Tune GetSnapshotData() during Hot Standby by avoiding loop |
Дата | |
Msg-id | 1271687489.8305.18879.camel@ebony обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql: Tune GetSnapshotData() during Hot Standby by avoiding loop (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: [COMMITTERS] pgsql: Tune GetSnapshotData() during
Hot Standby by avoiding loop
|
Список | 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 по дате отправления: