From: | Erik Jones <erik(at)myemma(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: XMIN semantic at peril ? |
Date: | 2007-10-11 16:47:37 |
Message-ID: | 5643FFF1-53DC-4F22-9870-4FC55FB11A7D@myemma.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Oct 11, 2007, at 11:03 AM, Tom Lane wrote:
> Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net> writes:
>> On Thu, Oct 11, 2007 at 10:44:17AM -0400, Tom Lane wrote:
>>> One question I'd have though is whether "freezing" of old tuples is
>>> likely to confuse your app.
>
>> Well, what we do is this:
>
>> - read row including XMIN
>> - do some UI stuff without open transactions
>> - update row with "... where pk = ... and XMIN = old_xmin_from_read"
>
>> If in the meantime another writer changed the data we
>> originally read we would detect that by xmin having changed
>> hence no row to be updated. So, yes, there is a *tiny*
>> failure condition:
>
> Hmm. I think the failure condition is not what you are thinking: in
> your example, you'd correctly conclude that some other transaction
> modified the row. The problem case is
>
> - read (a rather old) row including XMIN
> - VACUUM comes along and decides to set XMIN = FrozenTransactionId
> - update row with "... where pk = ... and XMIN = old_xmin_from_read"
> - update fails, when there is no need to fail
>
> As long as the failure is "soft", ie, you recover reasonably, this
> shouldn't be a big problem. But it's certainly not a scenario you
> should dismiss as not credible because of timescales.
If the query is always based on a primary key + XMIN, and since
vacuum is the only thing that sets FrozenTransactionId, would it be
unsane to change the update to
- update row with "... where pk=... and XMIN IN (old_xmin_from_read,
FrozenTransactionId)
?
Erik Jones
Software Developer | Emma®
erik(at)myemma(dot)com
800.595.4401 or 615.292.5888
615.292.0777 (fax)
Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2007-10-11 17:18:58 | Re: preferred way to use PG_GETARG_BYTEA_P in SPI |
Previous Message | Benjamin Arai | 2007-10-11 16:12:20 | Re: [PERFORM] Slow TSearch2 performance for table with 1 million documents. |