RE: [HACKERS] shmem limits and redolog

From: "Jackson, DeJuan" <djackson(at)cpsgroup(dot)com>
To: jwieck(at)debis(dot)com
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: RE: [HACKERS] shmem limits and redolog
Date: 1998-11-13 22:33:20
Message-ID: F10BB1FAF801D111829B0060971D839F50263B@cpsmail
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > > 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

Browse pgsql-hackers by date

  From Date Subject
Next Message Edmund Mergl 1998-11-13 22:43:28 Re: [HACKERS] Re: [BUGS] bug in postgresql-v6.4 on FreeBSD
Previous Message The Hermit Hacker 1998-11-13 21:45:43 Re: [HACKERS] More CORBA and PostgreSQL