Re: max_standby_delay considered harmful

From: Andres Freund <andres(at)anarazel(dot)de>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Florian Pflug <fgp(at)phlo(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us>, Greg Smith <greg(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>
Subject: Re: max_standby_delay considered harmful
Date: 2010-05-10 12:11:56
Message-ID: 201005101411.57216.andres@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Monday 10 May 2010 14:00:45 Heikki Linnakangas wrote:
> Florian Pflug wrote:
> > On May 10, 2010, at 11:43 , Heikki Linnakangas wrote:
> >> If you're not going to apply any more WAL records before shutdown, you
> >> could also just release all the AccessExclusiveLocks held by the startup
> >> process. Whatever the transaction was doing with the locked relation, if
> >> we're not going to replay any more WAL records before shutdown, we will
> >> not see the transaction committing or doing anything else with the
> >> relation, so we should be safe. Whatever state the data on disk is in,
> >> it must be valid, or we would have a problem with crash recovery
> >> recovering up to this WAL record and then starting up too.
> >
> > Sounds plausible. But wouldn't this imply that HS could *always* postpone
> > the acquisition of an AccessExclusiveLocks until right before the
> > corresponding commit record is replayed? If fail to see a case where
> > this would fail, yet recovery in case of an intermediate crash would be
> > correct.
>
> I guess it could in some situations, but for example the
> AccessExclusiveLock taken at the end of lazy vacuum to truncate the
> relation must be held during the truncation, or concurrent readers will
> get upset.
Actually all the locks that do not need to be taken on the slave would not
need to be an ACCESS EXCLUSIVE but a EXCLUSIVE on the master, right? That
should be "fixed" on the master, not hacked up on the slave and is by far out
of scope of 9.0.
Thats an area where I definitely would like to improve pg in the future...

Andres

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Tharp 2010-05-10 14:48:01 Re: no universally correct setting for fsync
Previous Message Heikki Linnakangas 2010-05-10 12:00:45 Re: max_standby_delay considered harmful