Jan Wieck wrote:
>
> > >
> > > At this time, a logfile switch is done (only if the
> > > actual database is really logged) and the sequence number
> > > of the new logfile plus the current datetime remembered.
> > > The behaviour of pg_dump's backend changes. It will see a
> > > snapshot of this time (implemented in tqual code) in any
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > Note, that I'm implementing multi-version concurrency control
> > (MVCC) for 6.5: pg_dump will have to run all queries
> > in one transaction in SERIALIZED mode to get snapshot of
> > transaction' begin time...
>
> Sounds good and would make things easier. I'll keep my hands
> off from the tqual code and wait for that.
>
> But what about sequence values while in SERIALIZED
> transaction mode. Sequences get overwritten in place! And for
> a dump/restore/recover it is important, that the sequences
> get restored ALL at once in the state they where.
It's time to re-implement sequences! When they were implemented
~ 1.5 year ago there was no GRANT/REVOKE on VIEWs and so
I had to create table for each sequence.
There should be one system table - pg_sequence. One record
for each sequence will be inserted into this table and
one VIEW will be created:
CREATE VIEW _seqname_ AS
SELECT * FROM pg_sequence WHERE sequence_name = '_seqname_';
GRANT/REVOKE on sequnece' VIEW will control rights to read sequence
using SELECT and rights to change sequence using nextval/setval.
Having _one_ sequences table there will be easy to lock
all sequences at once and read all values.
> >
> > Vacuum will not be delete records in which any active
> > backend is interested - don't worry.
>
> That's the vacuum part, but I still need to delay DROP
> TABLE/VIEW/SEQUENCE until the backup is complete.
Yes. And ALTER too.
Vadim