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

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #