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; > > You do need to trackdown how this might have happened, though. Any > clever code doing it's own 'serial' incrementing? > > Ross >
Yes i did miss read his statement, oops =-O The highest PK value in the table is 1071 but the next sequence is 1056. That's interesting and could be a big problem Quoteing JonF ------------------------------------------------ I'm thinking/guessing it had something to do with vacumn or the backup. The backup is a windows product "exec" and I'm using a special plug-in from exec for the Linux backup. But I still can't see this actually happening. -------------------------------------------------- BakupExec HMMM. Are you doing a file level backup, meaning backing up PGDATA folder or are you doing pg_dump?? I don't think its a backup issue, unless you have done a restore. Which this would say there are more problems else where Are there invoices that use up numbers 1056 to 1071 in that table??? Does the app allow for resetting Sequence in a admin interface??? Many apps have such features and someone could have accidentally rest the value??? 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??? All legitimate Magwerks Corporation quotations are sent in a .PDF file attachment with a unique ID number generated by our proprietary quotation system. Quotations received via any other form of communication will not be honored. CONFIDENTIALITY NOTICE: This e-mail, including attachments, may contain legally privileged, confidential or other information proprietary to Magwerks Corporation and is intended solely for the use of the individual to whom it addresses. If the reader of this e-mail is not the intended recipient or authorized agent, the reader is hereby notified that any unauthorized viewing, dissemination, distribution or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and destroy all occurrences of this e-mail immediately. Thank you.
<<attachment: justin.vcf>>
-- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql