Re: How to safely compare transaction id?

From: alphax <alphax(at)vip(dot)163(dot)com>
To: pg-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: How to safely compare transaction id?
Date: 2008-01-14 06:08:54
Message-ID: 478AFC76.4010201@vip.163.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tom Lane wrote:
> alphax <alphax(at)vip(dot)163(dot)com> writes:
>> So, it seems the system column "cmin" is the logical "current version"
>> of that record, isn't it?
>
> No. Have you read
> http://www.postgresql.org/docs/8.2/static/ddl-system-columns.html
>
Yes, I do. But I don't understand the actual meaning.

Trevor Talbot wrote:
> On 1/11/08, alphax <alphax(at)vip(dot)163(dot)com> wrote:
>
>> I want to determines a given record which visible to current transaction
>> whether or not be updated after some time point, that time point is
>> indicated by aother transaction id started and committed in past time.
>
> I'm not sure I understand, but maybe this thread will help?
> http://archives.postgresql.org/pgsql-general/2007-10/msg00503.php
>
Thanks, I had readed that message thread. Actually, my application is
similar to
> "XMIN changes when a (writing) transaction commits successfully".
> We don't care *how* it changes, just *that* it does so.

If I do:
type
TCompareResult = (PRECEDING, SAME, SUCCEEDING);
1) T1 BEGIN T1;
2) T1 READ table.xmin INTO :xmin_value
3) T1 COMMIT T1;
4) Other application(NOT Include VACUUM) do something
5) T2 BEGIN SERIALIZABLE T2;
6) T2 READ table.xmin INTO :xmin_value2
7) T2 TCompareResult compareResult := WRAPAROUND_SAFE_TID_COMPARE
(xmin_value, xmin_value2)
8) Other transaction(INCLUDE VACUUM) do some thing
9) T2 READ table.xmin INTO :xmin_value3
10)T2 COMMIT T2;

I must ensure:
A. In the time point 7), If compareResult is SAME, the record in table
is not changed by other committed transaction. if compareResult is
PRECEDING, the record is changed. This is meaning of "current version
(value) of record" I said.

B. In the time point 9), xmin_value3 must equal to previous readed
xmin_value2. I have qualms about this because the document say:|
"xmax |is the identity (transaction ID) of the deleting transaction, or
zero for an undeleted row version." I dont known in which condiation my
transaction can see a deleted record. Can someone tell me?

I must known which system column(xmin I assume here) can indicate the
changing of a logical row, If there is not such a column, I need to
create an user column to do this job. I have take notice of the Tome
Lane and others say in the thread "XMIN semantic at peril", my
understand is xmin is what I want, is it right?

But if the VACUUM is participate in time point 4) like below case, the
record change detection would be failed. It is a big problem in my
application.
4.1)...(long time)
4.2) other transaction do some thing with table(change xmin by there
transaction id) and commit.
4.X)...(long time)
4.X+1) VACUUM replace table.xmin to |FrozenXID.

Thanks for your help!

|

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Michael Meskes 2008-01-14 09:48:02 Re: ECPG problem with 8.3
Previous Message Alex Turner 2008-01-14 05:54:17 Re: query performance