Re: Problem with PITR recovery - Mailing list pgsql-hackers

From Klaus Naumann
Subject Re: Problem with PITR recovery
Date
Msg-id 4266049A.9080407@distinctmind.de
Whole thread Raw
In response to Re: Problem with PITR recovery  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Problem with PITR recovery  (Andrew Rawnsley <ronz@ravensfield.com>)
Re: Problem with PITR recovery  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
Hi Simon,

> Actually, me too. Never saw the need for the Oracle command myself.

It actually has. If you want to move your redo logs to a new disk, you
create a new redo log file and then issue a ALTER SYSTEM SWITCH LOGFILE;
to switch to the new logfile. Then you can remove the "old" one
(speaking just of one file for simplification).
Waiting on that event could take ages.

Strictly speaking, this doesn't concern postgresql (yet). But if, at the
future, we support user defined (= changing these parameters while the
db is running) redo log locations, sizes and count, we need a function
to switch the logfile manually. Which I think the pg_stop_backup()
hack is not suitable for.


pgsql-hackers by date:

Previous
From: Mario Weilguni
Date:
Subject: Re: ORDER BY different locales for 8.0
Next
From: Pavel Stehule
Date:
Subject: Re: Foreign keys on array elements