Re: Problem with PITR recovery

From: Klaus Naumann
Subject: Re: Problem with PITR recovery
Date: ,
Msg-id: 4266049A.9080407@distinctmind.de
(view: Whole thread, Raw)
In response to: Re: Problem with PITR recovery  (Simon Riggs)
Responses: Re: Problem with PITR recovery  (Andrew Rawnsley)
Re: Problem with PITR recovery  (Simon Riggs)
List: pgsql-hackers

Tree view

Re: Re: Problem with PITR recovery  (<>, )
 Re: Problem with PITR recovery  (Simon Riggs, )
  Re: Problem with PITR recovery  (Tom Lane, )
   Re: Problem with PITR recovery  (Simon Riggs, )
    Re: Problem with PITR recovery  (Oleg Bartunov, )
    Re: Problem with PITR recovery  (Klaus Naumann, )
     Re: Problem with PITR recovery  (Andrew Rawnsley, )
     Re: Problem with PITR recovery  (Simon Riggs, )
   Re: Problem with PITR recovery  (Bruce Momjian, )
    Re: Problem with PITR recovery  (Simon Riggs, )
     Re: Problem with PITR recovery  (Bruce Momjian, )
      Re: Problem with PITR recovery  (Tom Lane, )
      Re: Problem with PITR recovery  (Alvaro Herrera, )
       Re: Problem with PITR recovery  (Bruce Momjian, )
  Re: Problem with PITR recovery  (Simon Riggs, )
   Re: Problem with PITR recovery  (Tom Lane, )
    Re: Problem with PITR recovery  (Simon Riggs, )
   Re: Problem with PITR recovery  (Tom Lane, )
    Re: Problem with PITR recovery  (Simon Riggs, )
    Re: Problem with PITR recovery  (Bruce Momjian, )
     Re: Problem with PITR recovery  (Tom Lane, )
      Re: Problem with PITR recovery  (Bruce Momjian, )
       Re: Problem with PITR recovery  (Tom Lane, )
       Re: Problem with PITR recovery  ("Michael Paesold", )
        Re: Problem with PITR recovery  (Bruce Momjian, )
         Re: Problem with PITR recovery  (Simon Riggs, )

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:

From: Pavel Stehule
Date:
Subject: Re: Foreign keys on array elements
From: Andreas Pflug
Date:
Subject: Re: [GENERAL] Idea for the statistics collector