Skip site navigation (1) Skip section navigation (2)

Re: WAL logs multiplexing?

From: Ian Harding <harding(dot)ian(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: WAL logs multiplexing?
Date: 2005-12-28 16:38:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
On 12/28/05, Dmitry Panov <dmitry(at)tsu(dot)tula(dot)ru> wrote:
> On Wed, 2005-12-28 at 11:05 -0500, Tom Lane wrote:
> > Dmitry Panov <dmitry(at)tsu(dot)tula(dot)ru> writes:
> > > Yes, but if the server has crashed earlier the script won't be called
> > > and if the filesystem can't be recovered the changes will be lost. My
> > > point is the server should write into both (or more) files at the same
> > > time.
> >
> > As for that, I agree with the other person: a RAID array does that just
> > fine, and with much higher performance than we could muster.
> >
> Please see my reply to the other person. The other place can be on an
> NFS mounted directory. This is what the Oracle guys do and they know
> what they are doing (despite the latest release is total crap).

RAID is great for a single box, but this option lets you have
up-to-the-second PITR capability on a different box, perhaps at
another site.  My boss just asked me to set something like this up and
the only way to do it at the moment is a replication setup which seems
overkill for an offline backup.

If this functionality existed, could it obviate the requirement for an
archive_command in the simple cases where you just wanted the logs
moved someplace safe (i.e. no intermediate compression or whatever)?

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2005-12-28 16:41:25
Subject: Re: plperl vs LC_COLLATE (was Re: Possible savepoint bug)
Previous:From: Dmitry PanovDate: 2005-12-28 16:10:01
Subject: Re: WAL logs multiplexing?

pgsql-general by date

Next:From: Michael FuhrDate: 2005-12-28 16:44:03
Subject: Re: FW: deleted records
Previous:From: Dmitry PanovDate: 2005-12-28 16:10:01
Subject: Re: WAL logs multiplexing?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group