snapshot leak and core dump with serializable transactions
От | Pavan Deolasee |
---|---|
Тема | snapshot leak and core dump with serializable transactions |
Дата | |
Msg-id | 2e78013d0812030420ia173efas6a9ede2128b26908@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: snapshot leak and core dump with serializable
transactions
Re: snapshot leak and core dump with serializable transactions |
Список | pgsql-hackers |
The following test flashes snapshot leak warning and subsequently dumps core. Though this looks very similar to other bug report, this is a different issue.
postgres=# BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE ;
BEGIN
postgres=# SAVEPOINT A;
SAVEPOINT
postgres=# SELECT count(*) from pg_class;
count
-------
227
(1 row)
postgres=# RELEASE SAVEPOINT A;
WARNING: Snapshot reference leak: Snapshot 0x9e3e4d4 still referenced
RELEASE
postgres=# SELECT count(*) from pg_class;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
!>
1. Since "SAVEPOINT A" is the first statement in the transaction, a subtransaction is started and CurrentResourceOwner is set to the resource owner of the subtransaction. Later when serializable snapshot is taken, its recorded in the subtransaction resource owner. Obviously, when the subtransaction commits, it complains about the snapshot leak because the serializable snapshot is not yet unregiste red.
So I tried to ensure that the serializable snapshot is always recorded in the TopTransactionResourceOwner. It solved the above issue, but there is still a core dump when the top transaction is committed. That leads to the second issue.
2. In CommitTransaction(), I think we should call AtEOXact_Snapshot *before* releasing the resource owners. Otherwise, ResourceOwnerReleaseInternal complains about snapshot leak and then forcefully unregisters the snapshot. Later when AtEOXact_Snapshot is called, it again tries to unregister the serializable snapshot and assertion fails.
The attached patch fixes these issues.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
Вложения
В списке pgsql-hackers по дате отправления: