Joe Conway schrieb:
I am the only developer, DBA etc.. for a small project. Today (yesterday was
everything was perfect) many of the sequence numbers fell behind what is the
actual PK value. For example the invoice PK sequence current value = 1056
but the table PK was 1071. Nobody (other t
On 7/7/2010 5:41 PM, John wrote:
> On Wednesday 07 July 2010 03:14:40 pm Justin Graf wrote:
>
>> I would be looking at the log files for the Inserts into that table as a
>> means to track down what is the cause. If there are no log files or
>> don't have enough detail, crank up the logging lev
Quoth jo...@jfcomputer.com (John):
> On Wednesday 07 July 2010 03:14:40 pm Justin Graf wrote:
> > I would be looking at the log files for the Inserts into that table as a
> > means to track down what is the cause. If there are no log files or
> > don't have enough detail, crank up the logging leve
On Wed, Jul 7, 2010 at 9:59 PM, John wrote:
> I am the only developer, DBA etc.. for a small project. Today (yesterday
> was
> everything was perfect) many of the sequence numbers fell behind what is
> the
> actual PK value. For example the invoice PK sequence current value = 1056
> but the ta
On Wednesday 07 July 2010 03:14:40 pm Justin Graf wrote:
> I would be looking at the log files for the Inserts into that table as a
> means to track down what is the cause. If there are no log files or
> don't have enough detail, crank up the logging level and wait for it to
> happen again???
Th
On 7/7/2010 3:42 PM, Ross J. Reedstrom wrote:
>
> Justin, you're missing that John reported that the sequences are
> _behind_ the table. This only happens for me if I've been doing
> bulk data loads. Then I use:
>
> select setval(sequence_name,max(serial_id_column)) from table_with_serial_id;
>
> Y
On 07/07/2010 12:59 PM, John wrote:
> I am the only developer, DBA etc.. for a small project. Today (yesterday was
> everything was perfect) many of the sequence numbers fell behind what is the
> actual PK value. For example the invoice PK sequence current value = 1056
> but the table PK was
On Wed, Jul 07, 2010 at 04:25:13PM -0500, Justin Graf wrote:
> Are you using PG's sequence/auto increment???
>
> If so.
> Once PG fires off the nextval() for the sequence that number is
> considered used and gone even if the transaction that called nextval()
> is rolled back
>
> Depending on h
Yes I'm using auto_increment (serial data type). No function, method inserts
PK's anywhere in my code. I'm thinking/guessing it had something to do with
vacumn or the backup. I have been using Postgres for a number of years now
and I never seen this in the past. So I'm really at a loss as ho
Are you using PG's sequence/auto increment???
If so.
Once PG fires off the nextval() for the sequence that number is
considered used and gone even if the transaction that called nextval()
is rolled back
Depending on how the app is written nextval() might be called, but allow
the User to cance
I am the only developer, DBA etc.. for a small project. Today (yesterday was
everything was perfect) many of the sequence numbers fell behind what is the
actual PK value. For example the invoice PK sequence current value = 1056
but the table PK was 1071. Nobody (other than myself) knows how
11 matches
Mail list logo
