Re: [PATCHES] [HACKERS] TRUNCATE TABLE with IDENTITY

2008-07-01 Thread Bruce Momjian
Alvaro Herrera wrote: Tom Lane wrote: 2. I had first dismissed Neil's idea of transactional sequence updates as impossible, but on second look it could be done. Suppose RESTART IDENTITY does this for each sequence; * obtain AccessExclusiveLock; * assign a new relfilenode;

Re: [PATCHES] [HACKERS] TRUNCATE TABLE with IDENTITY

2008-06-08 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: 2. I had first dismissed Neil's idea of transactional sequence updates as impossible, but on second look it could be done. Suppose RESTART IDENTITY does this for each sequence; * obtain AccessExclusiveLock; * assign a new

Re: [PATCHES] [HACKERS] TRUNCATE TABLE with IDENTITY

2008-06-07 Thread Alvaro Herrera
Tom Lane wrote: 2. I had first dismissed Neil's idea of transactional sequence updates as impossible, but on second look it could be done. Suppose RESTART IDENTITY does this for each sequence; * obtain AccessExclusiveLock; * assign a new relfilenode; * insert a sequence

Re: [PATCHES] [HACKERS] TRUNCATE TABLE with IDENTITY

2008-05-17 Thread Simon Riggs
On Fri, 2008-05-16 at 21:50 -0400, Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: Ugh. The fact that the RESTART IDENTITY part of TRUNCATE is non-transactional is a pretty unsightly wort. Actually, I agree. Shall we just revert that feature? The ALTER SEQUENCE part of this patch

Re: [PATCHES] [HACKERS] TRUNCATE TABLE with IDENTITY

2008-05-17 Thread Tom Lane
Simon Riggs [EMAIL PROTECTED] writes: On Fri, 2008-05-16 at 21:50 -0400, Tom Lane wrote: Actually, I agree. Shall we just revert that feature? Perhaps, but we should also take into account that TRUNCATE is not and never will be MVCC compliant, so its not something you'd expect to run except

Re: [PATCHES] [HACKERS] TRUNCATE TABLE with IDENTITY

2008-05-17 Thread Simon Riggs
On Sat, 2008-05-17 at 12:04 -0400, Tom Lane wrote: So what I think we should do is leave the patch there, revise the warning per Neil's complaint, and add a TODO item to reimplement RESTART IDENTITY transactionally. Sounds good. -- Simon Riggs www.2ndQuadrant.com PostgreSQL

Re: [PATCHES] [HACKERS] TRUNCATE TABLE with IDENTITY

2008-05-16 Thread Tom Lane
Zoltan Boszormenyi [EMAIL PROTECTED] writes: Attached patch implements the extension found in the current SQL200n draft, implementing stored start value and supporting ALTER SEQUENCE seq RESTART; Updated patch implements TRUNCATE ... RESTART IDENTITY which restarts all owned sequences for the

Re: [PATCHES] [HACKERS] TRUNCATE TABLE with IDENTITY

2008-05-16 Thread Tom Lane
I wrote: One interesting point here is that the patch as submitted allowed ALTER SEQUENCE MINVALUE/MAXVALUE to be used to set a sequence range that the original START value was outside of. This would result in a failure at ALTER SEQUENCE RESTART. Since, as stated above, we really don't want

Re: [PATCHES] [HACKERS] TRUNCATE TABLE with IDENTITY

2008-05-16 Thread Neil Conway
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

Re: [PATCHES] [HACKERS] TRUNCATE TABLE with IDENTITY

2008-05-16 Thread Tom Lane
Neil Conway [EMAIL PROTECTED] writes: Ugh. The fact that the RESTART IDENTITY part of TRUNCATE is non-transactional is a pretty unsightly wort. Actually, I agree. Shall we just revert that feature? The ALTER SEQUENCE part of this patch is clean and useful, but I'm less than enamored of the