RE: Logging for sequences - Mailing list pgsql-hackers

From Mikheev, Vadim
Subject RE: Logging for sequences
Date
Msg-id 8F4C99C66D04D4118F580090272A7A234D31D2@sectorbase1.sectorbase.com
Whole thread Raw
In response to Logging for sequences  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
List pgsql-hackers
> Vadim, Philip changed that part of pg_dump on my advice.  The idea was
> to try to do the right thing for sequences when loading schema only or
> data only.  Analogously to loading data into a pre-existing table, we
> felt that a data dump ought to be able to restore the current state of
> an already-existing sequence object.  Hence it should use setval().

Tables have many records but sequences single one.
So, I don't see what would be wrong if we would drop/recreate sequences
in data-only mode - result would be the same as with setval: required
state of sequence. Ok, ok - sequence' OID would be different.

...

> My inclination is to leave pg_dump as it stands, and change 
> do_setval's error check.  We could rip out the check entirely, or we
> could modify the code so that a setval() is allowed for a sequence
> with cache > 1 only if it's the new three-parameter form of setval().
> That would allow pg_dump to do its thing without changing the behavior
> for existing applications.  Also, we can certainly make setval() flush
> any cached nextval assignments that the current backend is holding, even
> though we have no easy way to clean out cached values in other backends.
> 
> Comments?

I don't object any approach.

Vadim


pgsql-hackers by date:

Previous
From: ncm@zembu.com (Nathan Myers)
Date:
Subject: CRCs (was: beta testing version)
Next
From: Tom Lane
Date:
Subject: COPY BINARY file format proposal