Re: support for hyper-long transactions ...

From: Hans-Juergen Schoenig <postgres(at)cybertec(dot)at>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: support for hyper-long transactions ...
Date: 2007-10-16 13:04:18
Message-ID: 9C7EDE46-ADCD-4974-A89B-ED927AEE2917@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-10-16 14:05:27 Re: pgsql: Add sample text search dictionary templates and parsers, to
Previous Message Zoltan Boszormenyi 2007-10-16 12:53:32 Re: support for hyper-long transactions ...