On 26.11.2010 20:17, Robert Haas wrote:
On Fri, Nov 26, 2010 at 10:53 AM, Heikki Linnakangas
<heikki.linnakan...@enterprisedb.com> wrote:
If you have operation A in the master that currently acquires an
AccessExclusiveLock on a table, do you think it's safe for another
transaction to peek at the table at the same time?
Beep, time out. The notion of "at the same time" is extremely fuzzy
here. The operations on the master and slave are not simultaneous, or
anything close to it.
In this context, "at the same time" means "at the same point in WAL".
As a concrete example, VACUUM acquires an AccessExclusiveLock when it wants
to truncate the relation. A sequential scan running against the table in the
standby will get upset, if the startup process replays a truncation record
on the table without warning.
This case is similar. xl_smgr_truncate has only a relfilenode number,
not a relation OID, so there's no way for the startup process to
generate a conflicting lock request itself. But if the standby
backends locked the relfilenode, or if the xl_smgr_truncate WAL record
included the relation OID, it would be simple.
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?
WAL-logging AccessExclusiveLocks is a bit ugly, but it beats having to
infer that information from other records hands down.
--
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
