Re: Summary and Plan for Hot Standby

On Wed, 2009-11-18 at 14:51 +0200, Heikki Linnakangas wrote:
> Tatsuo Ishii wrote:
> >>> Please correct me if I'm wrong. Parse will result in obtaining
> >>> RowExclusiveLock on the target table if it is parsing
> >>> INSERT/UPDATE/DELETE. If so, is this ok in the standby?
> >> Any attempt to take RowExclusiveLock will fail.
> >>
> >> Any attempt to execute INSERT/UPDATE/DELETE will fail.
> >>
> >> This behaviour should be identical to read only transaction mode. If it
> >> is not documented as an exception, please report as a bug.
> >
> > Is it?
> >
> > It seems read only transaction mode is perfectly happy with
> > RowExclusiveLock:
>
> Hmm, that's a good point. I can't immediately see that that would cause
> any trouble, but it gives me an uncomfortable feeling about the locking.
> Which locks exactly need to be replayed in standby, and why? Which locks
> can read-only transactions acquire?
>
> The doc says:
> + In recovery, transactions will not be permitted to take any table lock
> + higher than AccessShareLock. In addition, transactions may never assign
> + a TransactionId and may never write WAL.
> + Any LOCK TABLE command that runs on the standby and requests a specific
> + lock type other than AccessShareLock will be rejected.
>
> which seems wrong, given Tatsuo-sans example. Is that paragraph only
> referring to LOCK TABLE, and not other means of acquiring locks? Either
> way, it needs to be clarified or fixed.
>
> access/transam/README says:
> +Further details on locking mechanics in recovery are given in comments
> +with the Lock rmgr code.
>
> but there's no explanation there either *why* the locking works as it
> is. In LockAcquire(), we forbid taking locks higher than AccessShareLock
> during recovery mode, but only for LOCKTAG_OBJECT locks. Why?

Recovery does *not* take the same locks as the original statements on
the master took. For example, the WAL record for an INSERT just makes
its changes without acquiring locks. This is OK as long as we only allow
read-only users to acquire AccessShareLocks. If we allowed higher locks
we might need to do deadlock detection, which would add more complexity.

The above restrictions are limited to LOCKTAG_OBJECT so that advisory
locks work as advertised. So advisory locks can take both shared and
exclusive locks. This never conflicts with recovery because advisory
locks are not WAL logged.

--
Simon Riggs www.2ndQuadrant.com