Re: PATCH: Exclude additional directories in pg_basebackup

From: David Steele <david(at)pgmasters(dot)net>
To: pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Subject: Re: PATCH: Exclude additional directories in pg_basebackup
Date: 2016-08-17 18:50:23
Message-ID: 5a99eeec-a116-82f2-9dc5-2ba3a0de9372@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Robert,

On 8/17/16 11:27 AM, Robert Haas wrote:
> On Mon, Aug 15, 2016 at 3:39 PM, David Steele <david(at)pgmasters(dot)net> wrote:
>> Recently a hacker proposed a patch to add pg_dynshmem to the list of
>> directories whose contents are excluded in pg_basebackup. I wasn't able
>> to find the original email despite several attempts.
>>
>> That patch got me thinking about what else could be excluded and after
>> some investigation I found the following: pg_notify, pg_serial,
>> pg_snapshots, pg_subtrans. These directories are all cleaned, zeroed,
>> or rebuilt on server start.
>
> Eh ... I doubt very much that it's safe to blow away the entire
> contents of an SLRU between shutdown and startup, even if the data is
> technically transient data that won't be needed again after the system
> is reset.

I've done pretty extensive testing in pgBackRest and haven't seen issues
in any supported version (plus I audited each init() function for every
version back to where it was introduced). The patch also passes all the
pg_basebackup TAP tests in master.

If you are correct it may indicate a problem anyway. Consider a standby
backup where the files in these directories may be incredibly stale
since they are not replicated. Once restored to a master should we
trust anything in these files?

pg_serial, pg_notify, pg_subtrans are not even fsync'd
(SlruCtl->do_fsync = false). It's hard to imagine there's anything of
value in there or that it can be trusted if there is.

The files in pg_snapshot and pg_dynshmem are simply deleted on startup
so that seems safe enough.

--
-David
david(at)pgmasters(dot)net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-08-17 18:52:41 Re: Curing plpgsql's memory leaks for statement-lifespan values
Previous Message Greg Stark 2016-08-17 18:32:37 Re: Are these supported??