Re: [9.3 bug] disk space in pg_xlog increases during archive recovery - Mailing list pgsql-hackers

From MauMau
Subject Re: [9.3 bug] disk space in pg_xlog increases during archive recovery
Date
Msg-id 3AB3A05BACF5430F83802BA56BE05AD3@maumau
Whole thread Raw
In response to Re: [9.3 bug] disk space in pg_xlog increases during archive recovery  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: [9.3 bug] disk space in pg_xlog increases during archive recovery
List pgsql-hackers
From: "Fujii Masao" <masao.fujii@gmail.com>
> !     if (source == XLOG_FROM_ARCHIVE && StandbyModeRequested)
>
> Even when standby_mode is not enabled, we can use cascade replication and
> it needs the accumulated WAL files. So I think that
> AllowCascadeReplication()
> should be added into this condition.
>
> !       snprintf(recoveryPath, MAXPGPATH, XLOGDIR "/RECOVERYXLOG");
> !       XLogFilePath(xlogpath, ThisTimeLineID, endLogSegNo);
> !
> !       if (restoredFromArchive)
>
> Don't we need to check !StandbyModeRequested and
> !AllowCascadeReplication()
> here?

Oh, you are correct.  Okay, done.


> !               /*
> !                * If the latest segment is not archival, but there's
> still a
> !                * RECOVERYXLOG laying about, get rid of it.
> !                */
> !               unlink(recoveryPath);   /* ignore any error */
>
> The similar line exists in the lower side of exitArchiveRecovery(), so
> ISTM that
> you can refactor that.

That's already done in the previous patch: deletion of RECOVERYXLOG was
moved into else clause, as in:

-  /*
-   * Since there might be a partial WAL segment named RECOVERYXLOG, get rid
-   * of it.
-   */
-  snprintf(recoveryPath, MAXPGPATH, XLOGDIR "/RECOVERYXLOG");
-  unlink(recoveryPath);  /* ignore any error */
-



Regards
MauMau

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: preserving forensic information when we freeze
Next
From: Andres Freund
Date:
Subject: Re: preserving forensic information when we freeze