Tom Lane <t...@sss.pgh.pa.us> wrote: > "Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: >> 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. Something similar to the PendingRelDelete >>> stuff in storage.c. In fact, hooking into smgrDoPendingDeletes >>> would work, but that seems like a modularity violation. > >> Thanks. That's helpful. Will look at that code and do something >> similar. > > Keep in mind that it's too late to throw any sort of error > post-commit. Any code you add there will need to have negligible > probability of failure. Thanks for the heads-up. I think we're OK in that regard, though. We have two commit-time functions in SSI: PreCommit_CheckForSerializationFailure(void) which is the "last chance for failure" before actual commit, and
ReleasePredicateLocks(const bool isCommit) which is for resource cleanup after rollback or commit is effective. We pretty much can't fail on the latter except for Assert statements, and this new logic would be the same. It's hard to fail when freeing resources unless something is quite seriously hosed already. This is where I was planning to put the freeing of the locks, based on queuing up the request at the time the DROP TABLE statement is encountered. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
