Re: PATCH: Exclude additional directories in pg_basebackup
От | David Steele |
---|---|
Тема | Re: PATCH: Exclude additional directories in pg_basebackup |
Дата | |
Msg-id | 5a99eeec-a116-82f2-9dc5-2ba3a0de9372@pgmasters.net обсуждение исходный текст |
Ответ на | Re: PATCH: Exclude additional directories in pg_basebackup (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: PATCH: Exclude additional directories in pg_basebackup
Re: PATCH: Exclude additional directories in pg_basebackup |
Список | 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@pgmasters.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@pgmasters.net
В списке pgsql-hackers по дате отправления: