On Thu, 2009-10-22 at 09:41 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Thu, 2009-10-22 at 07:55 +0300, Heikki Linnakangas wrote:
> >> Making some effort to transfer locks instead of acquiring+releasing
> >> would eliminate the need for having extra lock space available when
> >> s
Simon Riggs wrote:
> On Thu, 2009-10-22 at 07:55 +0300, Heikki Linnakangas wrote:
>> Making some effort to transfer locks instead of acquiring+releasing
>> would eliminate the need for having extra lock space available when
>> switching from hot standby mode to normal operation.
>
> This isn't ver
On Thu, 2009-10-22 at 07:55 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Wed, 2009-10-21 at 23:02 +0300, Heikki Linnakangas wrote:
> >> Hmm, dunno about that, but there is one problem with the "grant to dummy
> >> proc, then release in startup process" approach. What if there isn't
Simon Riggs wrote:
> On Wed, 2009-10-21 at 23:02 +0300, Heikki Linnakangas wrote:
>> Hmm, dunno about that, but there is one problem with the "grant to dummy
>> proc, then release in startup process" approach. What if there isn't
>> enough shared memory available to re-acquire the lock for the dumm
On Wed, 2009-10-21 at 23:02 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Wed, 2009-10-21 at 19:37 +0300, Heikki Linnakangas wrote:
> >
> >> So, I'm quite eager to just revert all those lock_twophase_recover()
> >> changes, and always rely on the "grant lock to dummy proc, then
> >>
Simon Riggs wrote:
> On Wed, 2009-10-21 at 19:37 +0300, Heikki Linnakangas wrote:
>
>> So, I'm quite eager to just revert all those lock_twophase_recover()
>> changes, and always rely on the "grant lock to dummy proc, then
>> release
>> it in startup process" method. If we don't want to rely on th
On Wed, 2009-10-21 at 19:37 +0300, Heikki Linnakangas wrote:
> So, I'm quite eager to just revert all those lock_twophase_recover()
> changes, and always rely on the "grant lock to dummy proc, then
> release
> it in startup process" method. If we don't want to rely on that,
> PostPrepare_Locks is
The Hot Standby patch changes lock_twophase_recover() so that when we're
starting up from Hot Standby mode to normal operation, as opposed to
crash recovery, we assume that all AccessExcusiveLocks are already held
by the startup process and instead of acquiring them anew they are
transferred from t
