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? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
