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(at)debis(dot)com (Jan Wieck) #