On Fri, Jun 24, 2011 at 12:27 PM, Kevin Grittner <kevin.gritt...@wicourts.gov> wrote: > Robert Haas <robertmh...@gmail.com> wrote: >> While taking a look at the existing documentation for pg_locks I >> came across the following paragraph: >> >> <para> >> When the <structname>pg_locks</structname> view is accessed, >> the internal lock manager data structures are momentarily >> locked, and a copy is made for the view to display. This >> ensures that the view produces a consistent set of results, >> while not blocking normal lock manager operations longer than >> necessary. Nonetheless there could be some impact on database >> performance if this view is frequently accessed. >> </para> >> >> AFAICS, this is no longer quite true. The view of the data from >> the main lock manager will be self-consistent, and the view of the >> data from the predicate lock manager will be self-consistent, but >> they need not be consistent with each other. I don't think that's >> a problem we need to fix, but we probably ought to make the >> documentation match the behavior. > > It remains true that the heavyweight locking structures are > momentarily locked to capture a consistent view of those, and it is > also true that the predicate locking structures are momentarily > locked to get a consistent view of that data. Both are not covered > by some over-arching lock, but...
...but they could be, if we were so inclined. We could acquire all of the lock manager partition locks, all of the predicate lock manager partition locks, and the lock on SerializableXactHashLock - then dump all the lock state from both tables - then release all the locks. What we actually do is acquire all of the lock manager locks, snapshot the state, release those locks, then get the predicate lock manager locks and SerializableXactHashLock, snapshot the state over there, release those locks, and then dump everything out. Since we don't do that, it's possible that "select * from pg_locks" could see a state that never really existed. For example, it's possible that, after doing GetLockStatusData() but before doing GetPredicateLockStatusData(), some backend might commit a transaction, releasing a heavyweight lock, begin a new transaction, and acquire a predicate lock. Now, the backend looking at the lock table is going to see both of those locks held at the same time even though in reality that never happened. The existing documentation for pg_locks indicates that such anomalies are possible because it's based on the (heretofore correct) idea that we're going to grab every single relevant lwlock at the same time before taking a snapshot of the system state. What I think we should do is replace the existing paragraph with something along these lines: The <structname>pg_locks<structname> view displays data from both the regular lock manager and the predicate lock manager, which are separate systems. When this view is accessed, the internal data structures of each lock manager are momentarily locked, and copies are made for the view to display. Each lock manager will therefore produce a consistent set of results, but as we do not lock both lock managers simultaneously, it is possible for locks to be taken or released after we interrogate the regular lock manager and before we interrogate the predicate lock manager. Each lock manager is only locked for the minimum possible time so as to reduce the performance impact of querying this view, but there could nevertheless be some impact on database performance if it is frequently accessed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers