BUG #10748: xmax is not resetting properly with FOR UPDATE
| От | pinker@onet.eu |
|---|---|
| Тема | BUG #10748: xmax is not resetting properly with FOR UPDATE |
| Дата | |
| Msg-id | 20140624142926.2618.16610@wrigleys.postgresql.org обсуждение исходный текст |
| Ответы |
Re: BUG #10748: xmax is not resetting properly with FOR UPDATE
|
| Список | pgsql-bugs |
The following bug has been logged on the website: Bug reference: 10748 Logged by: Alicja Kucharczyk Email address: pinker@onet.eu PostgreSQL version: 9.3.4 Operating system: RedHat Description: The problem is described here: http://stackoverflow.com/questions/24382158/strange-cleanup-behaviour-with-for-update The main problem is that xmax values stays set with xid of transaction that has already committed. The documentation says: "The identity (transaction ID) of the deleting transaction, or zero for an undeleted row version. It is possible for this column to be nonzero in a visible row version. That usually indicates that the deleting transaction hasn't committed yet, or that an attempted deletion was rolled back." I have used this feature for a queue to avoid locking, but it doesn't work together with FOR UPDATE clause. best regards, A.Kucharczyk
В списке pgsql-bugs по дате отправления: