From: | Zoltan Boszormenyi <zb(at)cybertec(dot)at> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Cc: | Hans-Juergen Schoenig <postgres(at)cybertec(dot)at>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: support for hyper-long transactions ... |
Date: | 2007-10-16 12:53:32 |
Message-ID: | 4714B44C.1080106@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas írta:
> Hans-Juergen Schoenig wrote:
>
>> at the moment i am working on an application which is supposed to run
>> extremely large transactions (a lot of server side stored procedure
>> stuff which can hardly be split into small transactions for visibility
>> reasons).
>> so, from time to time it happens that i exceed my CommandCounter (>
>> 2.000.000.000 statements inside the same transaction).
>>
>
> Interesting. What kind of a stored procedure is that?
>
> One optimization that might be possible is to not increment it for
> statements that do on-disk changes.
>
>
>> my idea is: how about adding a configure option to compile postgres with
>> a 64 bit command counter. this would allow larger transactions for
>> special purpose applications while it would not have an impact on normal
>> applications.
>>
>
> One objection to expanding TransactionId to 64-bits has been that we
> depend on assignment of TransactionId to be atomic. That might not be an
> issue with CommandIds; I don't think we store commandids in shared
> memory structures. It still doesn't feel like a good idea to me, though.
>
Isn't 64-bit assignment atomic on 64-bit machines?
With a little autoconf magic, the conditional can be
disabled for 32-bit platforms. So that's not a real obstacle
for going to 64-bit TransactionIds.
--
----------------------------------
Zoltán Böszörményi
Cybertec Geschwinde & Schönig GmbH
http://www.postgresql.at/
From | Date | Subject | |
---|---|---|---|
Next Message | Hans-Juergen Schoenig | 2007-10-16 13:04:18 | Re: support for hyper-long transactions ... |
Previous Message | Heikki Linnakangas | 2007-10-16 12:45:31 | Re: support for hyper-long transactions ... |