RE: [HACKERS] shmem limits and redolog

> > >     What do the others say?
> > >
> > In my opinion a redo log is more than worth the overhead.  If it is
> > possible to keep those databases that aren't using the log from
> creating
> > the shmem and semaphores until logging is turned on for them, I'd
> say
> > you'd eliminated all of the possible arguments.
> >    -DEJ
> 
>     The semaphore set I would like to stay at least. Because it's
>     a way to make pg_dump capable of  totally  consistent  online
>     backups.
> 
>     Let's say pg_dump first issues an
> 
>         ALTER DATABASE BEGIN BACKUP;
> 
>     This will return when the last write lock on the database got
>     released.  It now dumps schema. During that phase, any  query
>     from  another  backend  will suspend as soon as it requests a
>     write lock. After finishing schema dump  (including  sequence
>     states  -  that's the reason for the exclusive backup phase),
>     pg_dump does an
> 
>         ALTER DATABASE ONLINE BACKUP;
> 
>     At this time, a logfile switch is done and pg_dump's  backend
>     changes  it's  behavior so all subsequent queries will return
>     the data valid at the moment of the  ONLINE  BACKUP  command.
>     Now all other backend's can freely modify the database and do
>     whatever they  want  and  the  suspended  backends  continue.
>     pg_dump will not see their changes.
> 
>     When pg_dump finishes, it does an
> 
>         ALTER DATABASE END BACKUP;
> 
>     This  stores information about the last successful backup and
>     the first logfile sequence required to recover from this dump
>     -  the sequence of the logfile began at ONLINE BACKUP. And it
>     turns back the special behaviour of pg_dump's backend.   Last
>     action of pg_dump is to add this info to the dump.
> 
>     Wouldn't  that  all  be  really  nice?  Having a productional
>     database online, taking a full backup while the  database  is
>     beeing  updated  plus  having  a  transaction  log that could
>     recover a crash using that backup.
> 
>     The final redolog I'm planning will have  more  capabilities.
>     Point-in-time   recovery   and  online  recovery  of  another
>     database (on another system?)  to have a second  database  in
>     sync  and beeing able to switchover in a crash situation, not
>     requiring downtime for recovery.
> 
>     It's still a long way to there - I just made the first steps.
> 
> 
> Jan
> 
Jan, you make me dreams come true.  Keep the semaphores, how big are
they anyway?-DEJ