Re: [HACKERS] redolog - for discussion

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