Re: Concurrent INSERT statements with RETURNING clause resetting SERIAL sequence

From: Sebastien Flaesch <sebastien(dot)flaesch(at)4js(dot)com>
To: Thomas Kellerer <shammat(at)gmx(dot)net>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Concurrent INSERT statements with RETURNING clause resetting SERIAL sequence
Date: 2022-07-20 09:15:29
Message-ID: DBAP191MB12892D84093ECBB2CCF8D111B08E9@DBAP191MB1289.EURP191.PROD.OUTLOOK.COM
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Thomas, we already have a similar solution.
The idea is to use the native PostgreSQL SERIAL type.
Seb
________________________________
From: Thomas Kellerer <shammat(at)gmx(dot)net>
Sent: Wednesday, July 20, 2022 8:56 AM
To: pgsql-general(at)lists(dot)postgresql(dot)org <pgsql-general(at)lists(dot)postgresql(dot)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$

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Karthik K L V 2022-07-20 09:32:13 operator does not exist: text = bytea
Previous Message Ron 2022-07-20 08:28:54 Re: Batch process