From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Silly API for do_pg_start_backup() |
Date: | 2017-12-04 18:58:07 |
Message-ID: | 28752.1512413887@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Why is it that do_pg_start_backup() expects its callers to pass in
an open DIR pointer for the pg_tblspc directory, rather than doing
the AllocateDir call for itself? This complicates the callers, provides
no flexibility (since do_pg_start_backup() is hardwired to know that
pg_tblspc is what it was passed), and it doesn't seem to me to offer any
robustness either. There are a couple of comments suggesting that
somebody thought that opening the directory early might be good, but
there's no defense of why, and I can't see that holding the directory open
across a checkpoint request is adding robustness; if anything more the
reverse, since it's a kernel resource we don't need during that phase.
Barring objection I'll remove the tblspcdir parameter and have
do_pg_start_backup() open and close the directory immediately
around the loop where it's read, like every other case in the
backend.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-12-04 19:00:13 | Re: Errands around AllocateDir() |
Previous Message | Robert Haas | 2017-12-04 17:49:08 | Re: [HACKERS] postgres_fdw super user checks |