Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Nov 26, 2010 at 2:06 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> If you go down that path, you're going to spend a lot of time thinking
>> through every single case that uses an AccessExclusiveLock, ensuring that
>> the standby has enough information, and tinkering with the replay code to
>> acquire locks at the right moment. And gain what, exactly?
> Well, fewer useless locks on the standby, for one thing, in all
> likelihood, and less WAL traffic.
I think it's not only useless from a performance standpoint, but
probably actually dangerous, to not take AccessExclusiveLock on the
standby when it's taken on the master. If you try to delay taking the
lock, then locks will be taken in a different order on master and
standby, which is quite likely to lead to deadlock situations.
Speaking of which, is there any code in there to ensure that a deadlock
in the standby is resolved by killing HS queries and not the replay
process? Because deadlocks are certainly going to be possible no matter
what.
> All somebody has to do is introduce a
> mechanism that drops or rewrites a relation file without an access
> exclusive lock, and this whole approach snaps right off
... as would queries on the master, so that's not ever happening.
regards, tom lane