It is also recommended when creating new standby control files, when
Oracle can't
automatically expand the data file capacity on a standby like it does
with
a live database. Nothing like seeing the 'Didn't restore XXXX from
sufficiently old
backup' message when Oracle is confused (which seems to be most of the
time)
about what transactions have been applied where.
This, of course, doesn't matter for postgresql. Thank the gods....
On Apr 20, 2005, at 3:28 AM, Klaus Naumann wrote:
> 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.
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>
>
____________________________
Andrew Rawnsley
Chief Technology Officer
Investor Analytics, LLC
(740) 587-0114
http://www.investoranalytics.com