Re: SIREAD lock versus ACCESS EXCLUSIVE lock

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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