Re: Concurrent INSERT statements with RETURNING clause resetting SERIAL sequence - Mailing list pgsql-general

From Sebastien Flaesch
Subject Re: Concurrent INSERT statements with RETURNING clause resetting SERIAL sequence
Date
Msg-id DBAP191MB12892D84093ECBB2CCF8D111B08E9@DBAP191MB1289.EURP191.PROD.OUTLOOK.COM
Whole thread Raw
In response to Re: Concurrent INSERT statements with RETURNING clause resetting SERIAL sequence  (Thomas Kellerer <shammat@gmx.net>)
Responses Re: Concurrent INSERT statements with RETURNING clause resetting SERIAL sequence  (Karsten Hilbert <Karsten.Hilbert@gmx.net>)
List pgsql-general
Thomas, we already have a similar solution.
The idea is to use the native PostgreSQL SERIAL type.
Seb

From: Thomas Kellerer <shammat@gmx.net>
Sent: Wednesday, July 20, 2022 8:56 AM
To: pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
Subject: Re: Concurrent INSERT statements with RETURNING clause resetting SERIAL sequence
 
EXTERNAL: Do not click links or open attachments if you do not recognize the sender.

Sebastien Flaesch schrieb am 19.07.2022 um 18:50:
> Tom,
>
>     /If that's the behavior you want, you can build it out of standard SQL facilities (e.g. update a one-row table).
>     /
>
> Can you elaborate please?
>
> Do you mean the code should use an UPDATE on a one-row table to acquire a lock?

I assume something like this:

https://urldefense.com/v3/__https://blog.sql-workbench.eu/post/gapless-sequence/__;!!I_DbfM1H!F7_2cNahve0cmwPMP6QBBwwpyP6UAum4ukFj71_21ebcxTKXZFtU0_3O6l1lfG5jYiKjO7wEzRt_E1GbJ9Q$




pgsql-general by date:

Previous
From: Ron
Date:
Subject: Re: Batch process
Next
From: Karthik K L V
Date:
Subject: operator does not exist: text = bytea