Thread: Sequence Cleanup

Sequence Cleanup

From
Rod Taylor
Date:
Below is a short list of TODOs on sequences I wish to tackle over the
next week.


CREATE SEQUENCE:
- Addition of NO MAXVALUE and NO MINVALUE options, which use the system
implementation settings -- for SQL2002 compliance, and makes ALTER
SEQUENCE slightly easier.

ALTER SEQUENCE:
- Supports RESTART WITH, + options from Create Statement (including NO
MAXVALUE, NO MINVALUE).


Modify init_params to deal with seq->options only.  This allows
AlterSequence to use it as well.


Ok, this is where it gets confusing.  Right now setval() is implemented
in such a manner that it cannot be rolled back (see SETVAL NOTE below),
but I'd like ALTER SEQUENCE to be transaction safe.   Can I assume that
a standard simple_heap_update() is valid against the sequence, so long
as I set xmin = FrozenTransactionId and create 2 XLog records similarly
to DefineSequence?

Now, do I need to do anything to clear the cache of other backends, or
simply let them play themselves out. I'm leaning towards the latter, as
nextval() appears to read in the min / max value from the sequence
buffer.


A transaction safe alter sequence, implemented in the standard method,
will result in two tuples.  Doing this many times could make sequences
quite slow.  It looks like read_info() depends on a single value value
in the sequence table.  Do I need to do something more complex like a
relfileswap, generating a fresh tuple for it -- all parts of
DefineSequence() except the DefineRelation() step?


Anyway, I'll fiddle with the above two approaches, but would appreciate
input where appropriate.


-- SETVAL NOTE --
a=# select nextval('test');nextval
---------      2
(1 row)

a=# begin;
BEGIN
a=# select setval('test', 50);setval
--------    50
(1 row)

a=# select nextval('test');nextval
---------     51
(1 row)

a=# rollback;
ROLLBACK
a=# select nextval('test');nextval
---------     52
(1 row)





--
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc

Re: Sequence Cleanup

From
Hannu Krosing
Date:
Rod Taylor kirjutas T, 10.12.2002 kell 01:49:
> Below is a short list of TODOs on sequences I wish to tackle over the
> next week.
...
> Ok, this is where it gets confusing.  Right now setval() is implemented
> in such a manner that it cannot be rolled back (see SETVAL NOTE below),
> but I'd like ALTER SEQUENCE to be transaction safe.

All *val('seqname') functions are transaction-unsafe, i.e. live outside
transactions. 

Why would you want alter transaction to be transaction safe ? 


-- 
Hannu Krosing <hannu@tm.ee>


Re: Sequence Cleanup

From
Tom Lane
Date:
Rod Taylor <rbt@rbt.ca> writes:
> I'd like ALTER SEQUENCE to be transaction safe.

I think that's inherently impossible without breaking the existing
behavior of setval/nextval, which is something we will not accept.
ALTER SEQUENCE would be better thought of as a form of setval with
even more parameters, but not fundamentally different semantics.

> Can I assume that
> a standard simple_heap_update() is valid against the sequence,

You can be certain that it is not.  There can be only one tuple in a
sequence table.
        regards, tom lane