Re: tablespace_map code cleanup - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: tablespace_map code cleanup
Date
Msg-id 20200514.114319.1756916152856647629.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: tablespace_map code cleanup  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: tablespace_map code cleanup  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
At Wed, 13 May 2020 15:10:30 -0400, Robert Haas <robertmhaas@gmail.com> wrote in 
> On Tue, May 12, 2020 at 10:26 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > I was trying to say that tablespace listing will happen under
> > PROGRESS_BASEBACKUP_PHASE_WAIT_CHECKPOINT phase which could be a
> > problem if it is a costly operation but as you said it is pretty cheap
> > so I think we don't need to bother about that.
> >
> > Apart from the above point which I think we don't need to bother, both
> > your patches look good to me.
> 
> OK, good. Let's see if anyone else feels differently about this issue
> or wants to raise anything else. If not, I'll plan to commit these
> patches after we branch. Thanks for the review.

Table space listing needs only one or few 512k pages, which should be
on OS file cache, which cannot take long time unless the system is
facing a severe trouble. (I believe that is the same on Windows.)

I'm fine that WAIT_CHECKPOINT contains the time to enumerate
tablespace directories.


0001 looks good to me.  The progress information gets

About 0002,

+                bool    sendtblspclinks = true;

The boolean seems to me useless since it is always the inverse of
opt->sendtblspcmapfile when it is used.

Everything looks fine to me except the above.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: PG 13 release notes, first draft
Next
From: Andy Fan
Date:
Subject: Re: [PATCH] Keeps tracking the uniqueness with UniqueKey