From: | pinker(at)onet(dot)eu |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | BUG #10748: xmax is not resetting properly with FOR UPDATE |
Date: | 2014-06-24 14:29:26 |
Message-ID: | 20140624142926.2618.16610@wrigleys.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
The following bug has been logged on the website:
Bug reference: 10748
Logged by: Alicja Kucharczyk
Email address: pinker(at)onet(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | pinker | 2014-06-24 14:30:56 | BUG #10750: xmax is not resetting properly with FOR UPDATE |
Previous Message | Andrew Dunstan | 2014-06-24 14:08:15 | Re: [HACKERS] BUG #10728: json_to_recordset with nested json objects NULLs columns |