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
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
Zoltan Boszormenyi írta:
Zoltan Boszormenyi írta:
Decibel! írta:
On Apr 3, 2008, at 12:52 AM, Zoltan Boszormenyi wrote:
Where is the info in the sequence to provide restarting with
the _original_ start value?
There isn't any. If you want the sequence to start at some magic
value, adjust the
Zoltan Boszormenyi írta:
Decibel! írta:
On Apr 3, 2008, at 12:52 AM, Zoltan Boszormenyi wrote:
Where is the info in the sequence to provide restarting with
the _original_ start value?
There isn't any. If you want the sequence to start at some magic
value, adjust the minimum value.
There's
11 matches
Mail list logo
