On Fri, Aug 3, 2012 at 6:59 AM, Julian wrote:
> Hi,
> If you want guaranteed "consecutive" sequential numbering you have to
> implement your own solution. I was brought to task by a number of people
> about this (accountants). So its not a good idea to use a sequence for
> things like invoice, re
Hi,
If you want guaranteed "consecutive" sequential numbering you have to
implement your own solution. I was brought to task by a number of people
about this (accountants). So its not a good idea to use a sequence for
things like invoice, receipt and other such accounting objects (not only
mo
Am 02.08.2012 17:15, schrieb Andrew Hastie:
> Hi Frank,
>
> I believe this is by design. See the bottom of the documentation on
> sequences where it states ;-
>
> "*Important:* To avoid blocking concurrent transactions that obtain
> numbers from the same sequence, a |nextval| operation is never r
Hi,
Thanks very much for the detailed answer. I totally missed the issue
with concurrent transactions.
Am 03.08.2012 02:00, schrieb Craig Ringer:
> It's interesting that you read the documentation and still got bitten by
> this. I'll have to think about writing a patch to add some
> cross-refere
On 08/03/2012 12:07 PM, Chris Angelico wrote:
On Fri, Aug 3, 2012 at 10:00 AM, Craig Ringer wrote:
-- PostgreSQL specific hack you can use to make
-- really sure only one row ever exists
CREATE UNIQUE INDEX there_can_be_only_one
ON invoice_number( (1) );
This will guarantee that there's only o
On 08/02/2012 11:08 PM, Frank Lanitz wrote:
Hi folks,
I did a test with transactions and wondered about an behavior I didn't
expected. At http://pastebin.geany.org/bYQNo/raw/ I posted a complete
backlog for.
To make it short: I created a table with a serial and started a
transactions. After thi
On Fri, Aug 3, 2012 at 1:08 AM, Frank Lanitz wrote:
> My understanding of all was that it includes sequences. Obviously, I'm
> wrong... but how to do it right?
Sequences are fast and lock-free, but don't guarantee absence of gaps.
Quite a few things can unexpectedly advance a sequence (including
Hi Frank,
I believe this is by design. See the bottom of the documentation on
sequences where it states ;-
"*Important:* To avoid blocking concurrent transactions that obtain
numbers from the same sequence, a |nextval| operation is never rolled
back; that is, once a value has been fetched it
Hi folks,
I did a test with transactions and wondered about an behavior I didn't
expected. At http://pastebin.geany.org/bYQNo/raw/ I posted a complete
backlog for.
To make it short: I created a table with a serial and started a
transactions. After this I was inserting values into the table but di
