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
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
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 se
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 T
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
>
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 t
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
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
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
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
10 matches
Mail list logo
