pgsql: Default monitoring roles - errata
Default monitoring roles - errata 25fff40798fc4ac11a241bfd9ab0c45c085e2212 introduced default monitoring roles. Apply these corrections: * Allow access to pg_stat_get_wal_senders() by role pg_read_all_stats * Correct comment in pg_stat_get_wal_receiver() to show it is no longer superuser-only. Author: Feike Steenbergen Reviewed-by: Michael Paquier Apply to HEAD, then later backpatch to 10 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6668a54eb8ef639a3182ae9e37e4e67982c44292 Modified Files -- src/backend/replication/walreceiver.c | 3 ++- src/backend/replication/walsender.c | 8 +--- 2 files changed, 7 insertions(+), 4 deletions(-)
pgsql: Add TIMELINE to backup_label file
Add TIMELINE to backup_label file Allows new test to confirm timelines match Author: Michael Paquier Reviewed-by: David Steele Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6271fceb8a4f07dafe9d67dcf7e849b319bb2647 Modified Files -- src/backend/access/transam/xlog.c | 50 --- src/test/perl/PostgresNode.pm | 1 + 2 files changed, 48 insertions(+), 3 deletions(-)
Re: pgsql: Improve error handling in RemovePgTempFiles().
On Tue, Dec 5, 2017 at 11:59 AM, Tom Lane wrote: > Improve error handling in RemovePgTempFiles(). > > [...] I also > removed the previous practice of silently ignoring ENOENT failures during > directory opens --- there are some corner cases where that could happen > given a previous database crash, but that seems like a bad excuse for > ignoring a condition that isn't expected in most cases. A LOG message > during postmaster start seems OK in such situations, and better than > no output at all. Was it intentional that a newly created cluster produces a LOG error on startup until you eventually do something to cause base/pgsql_tmp to exist? Same for each tablespace you create. 2018-01-07 16:34:20.352 NZDT [77400] LOG: could not open directory "base/pgsql_tmp": No such file or directory 2018-01-07 16:34:20.354 NZDT [77400] LOG: could not open directory "pg_tblspc/16384/PG_11_201712251/pgsql_tmp": No such file or directory Perhaps RemovePgTempFiles() could check if each one exists before calling RemovePgTempFilesInDir(), like in the attached? Alternatively we could make RemovePgTempFilesInDir() return early if temp_dir == NULL (going against your commit message above), or I suppose we could arrange for temporary directories always to exist in base and each tablespace. -- Thomas Munro http://www.enterprisedb.com quieten-startup.patch Description: Binary data
Re: pgsql: Improve error handling in RemovePgTempFiles().
Thomas Munro writes: > On Tue, Dec 5, 2017 at 11:59 AM, Tom Lane wrote: >> Improve error handling in RemovePgTempFiles(). > Was it intentional that a newly created cluster produces a LOG error > on startup until you eventually do something to cause base/pgsql_tmp > to exist? Same for each tablespace you create. > 2018-01-07 16:34:20.352 NZDT [77400] LOG: could not open directory > "base/pgsql_tmp": No such file or directory Ooops, nope. > Perhaps RemovePgTempFiles() could check if each one exists before > calling RemovePgTempFilesInDir(), like in the attached? Alternatively > we could make RemovePgTempFilesInDir() return early if temp_dir == > NULL (going against your commit message above), or I suppose we could > arrange for temporary directories always to exist in base and each > tablespace. Seems like the first of those alternatives is the best, but it's pretty late here and my brain is fried. Will think about this mañana. regards, tom lane
