Re: support for hyper-long transactions ... - Mailing list pgsql-hackers

From Hans-Juergen Schoenig
Subject Re: support for hyper-long transactions ...
Date
Msg-id 9C7EDE46-ADCD-4974-A89B-ED927AEE2917@cybertec.at
Whole thread Raw
In response to Re: support for hyper-long transactions ...  (Heikki Linnakangas <heikki@enterprisedb.com>)
List pgsql-hackers

AFAICS, maximum number of command ids is actually 2^32-1, or over 4
billion. Are you sure you bumped into that limit and not something else?
What's the error message you're getting?

What version of Postgres is this? PG 8.3 will have another related limit
on the number of combocids you can have.


it is clearly caused by the CommandCounter - it is indicated by the error message. i don't have the message on my notebook here but this is exactly what is going on if we run out of statements.

i would not see atomic as a problem here as we can support it for 64 bit boxes only.
i would vote for some autoconf flag which is off by default to make sure that other applications don't waste space here.

to answer the question you had before:
it is an application going through some enormous amount of raw data and trying to do some filtering, analysis and preaggregation (which is not an issue here). the thing is that filtering and analysis are quite complex and have to be done on a per entry level (a lot of conditional lookups, if statements, custom aggregated, status changed and so on). if you are forced to do this fancy logic for 1xx mio records you can easily run out of commands.

many thanks,

hans



--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26, 2700 Wiener Neustadt
Tel: +43/1/205 10 35 / 340
www.postgresql.at, www.cybertec.at


pgsql-hackers by date:

Previous
From: Zoltan Boszormenyi
Date:
Subject: Re: support for hyper-long transactions ...
Next
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Add sample text search dictionary templates and parsers, to