Re: [HACKERS] TRUNCATE TABLE with IDENTITY
Neil Conway <neilc@samurai.com>
From: Neil Conway <neilc@samurai.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Zoltan Boszormenyi <zb@cybertec.at>, List pgsql-patches <pgsql-patches@postgresql.org>, Decibel! <decibel@decibel.org>, Simon Riggs <simon@2ndquadrant.com>, Steve Crawford <scrawford@pinpointresearch.com>, pgsql-hackers@postgresql.org
Date: 2008-05-17T01:35:52Z
Lists: pgsql-hackers
On Fri, 2008-05-16 at 19:41 -0400, Tom Lane wrote: > Applied with corrections. Most notably, since ALTER SEQUENCE RESTART > is nontransactional like most other ALTER SEQUENCE operations, I > rearranged things to try to ensure that foreseeable failures like > deadlock and lack of permissions would be detected before TRUNCATE > starts to issue any RESTART commands. Ugh. The fact that the RESTART IDENTITY part of TRUNCATE is non-transactional is a pretty unsightly wort. I would also quarrel with your addition to the docs that suggests this is only an issue "in practice" if TRUNCATE RESTART IDENTITY is used in a transaction block: unpredictable failures (such as OOM or query cancellation) can certainly occur in practice, and would be very disruptive (e.g. if the sequence values are stored into a column with a UNIQUE constraint, it would break all inserting transactions until the DBA intervenes). I wonder if it would be possible to make the sequence operations performed by TRUNCATE transactional: while the TRUNCATE remains uncommitted, it should be okay to block concurrent access to the sequence. -Neil