From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Christoph Ziegenberg <ziegenberg(at)web(dot)de> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #15967: Sequence generation using NEXTVAL() fails on 64bit systems |
Date: | 2019-08-21 13:39:12 |
Message-ID: | CAHyXU0yt1RzjhYrJ2M1Y4EPkRo8ZaWOer4SOuM1UveHUFsLb-A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, Aug 21, 2019 at 8:27 AM Christoph Ziegenberg <ziegenberg(at)web(dot)de> wrote:
>
> Good news: We finally found the error.
>
> It was a trigger on one table that updated the sequence using setval()... Of course this cannot work and I don't know why this was added (perhaps for a migration script?).
>
> This use of setval() via the trigger was missing in the Postgres statement log (perhaps because it was a PERFORM statement?), so we didn't find it earlier.
>
> Sorry and thanks for your help to all.
No worries, glad you found the issue. I mean, nextval() is probably
the most commonly trafficked function in the database and is dead
reliable for millions of users, so there had to be another
explanation, right? :-). setval() is an extremely dangerous function
outside of cases related to restoring data; it modifies state outside
of transactional guarantees. if you saw it in code not guarded by
some kind of lock you ought to be suspicious.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-08-21 13:44:34 | Re: BUG #15954: Unable to alter partitioned table to set logged |
Previous Message | Christoph Ziegenberg | 2019-08-21 13:27:15 | Re: BUG #15967: Sequence generation using NEXTVAL() fails on 64bit systems |