Обсуждение: Is it possible that session lock is not released
Hi,
I just found that ShutdownPostgres() only releases USER_LOCKMETHOD locks, so why not
release DEFAULT_LOCKMETHOD locks? Check if this is possible:
We are doing a CREATE INDEX CONCURRENTLY, and codes runs to
LockRelationIdForSession(&heaprelid, ShareUpdateExclusiveLock);
PopActiveSnapshot();
CommitTransactionCommand();
Now transaction goes to default state, then this backend is killed or some FATAL error happens,
AbortOutOfAnyTransaction() in ShutdownPostgres() will do nothing since transaction is in default
state, and session lock on heaprelid is still held after ShutdownPostgres(), so subsequent operations
could be blocked by this session lock.
Thanks.
I just found that ShutdownPostgres() only releases USER_LOCKMETHOD locks, so why not
release DEFAULT_LOCKMETHOD locks? Check if this is possible:
We are doing a CREATE INDEX CONCURRENTLY, and codes runs to
LockRelationIdForSession(&heaprelid, ShareUpdateExclusiveLock);
PopActiveSnapshot();
CommitTransactionCommand();
Now transaction goes to default state, then this backend is killed or some FATAL error happens,
AbortOutOfAnyTransaction() in ShutdownPostgres() will do nothing since transaction is in default
state, and session lock on heaprelid is still held after ShutdownPostgres(), so subsequent operations
could be blocked by this session lock.
Thanks.
T <kurt023@hotmail.com> writes:
> Now transaction goes to default state, then this backend is killed or some FATAL error happens,
> AbortOutOfAnyTransaction() in ShutdownPostgres() will do nothing since transaction is in default
> state, and session lock on heaprelid is still held after ShutdownPostgres(), so subsequent operations
> could be blocked by this session lock.
This would only be an issue if we were to accept interrupts between the
CommitTransactionCommand() and StartTransactionCommand() steps ... which
we don't. I'll admit it's a tad on the fragile side but I don't see a
bug.
regards, tom lane