On 03.06.2011 23:44, Kevin Grittner wrote:
Heikki Linnakangas<heikki.linnakan...@enterprisedb.com> wrote:
I think you'll need to just memorize the lock deletion command in
a backend-local list, and perform the deletion in a post-commit
function.
Hmm. As mentioned earlier in the thread, cleaning these up doesn't
actually have any benefit beyond freeing space in the predicate
locking collections. I'm not sure that benefit is enough to justify
this much new mechanism. Maybe I should just leave them alone and
let them get cleaned up in due course with the rest of the locks.
Any opinions on that?
Is there a chance of false positives if oid wraparound happens and a new
table gets the same oid as the old one? It's also possible for a heap to
get the OID of an old index or vice versa, will that confuse things?
--
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
