Re: pg_basebackup vs. Windows and tablespaces - Mailing list pgsql-hackers

From Robert Haas
Subject Re: pg_basebackup vs. Windows and tablespaces
Date
Msg-id CA+TgmoZe00ei7nMmrs6CGopWR879zsLLuVzxiH55MbjK-POHFg@mail.gmail.com
Whole thread Raw
In response to Re: pg_basebackup vs. Windows and tablespaces  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: pg_basebackup vs. Windows and tablespaces  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Nov 14, 2014 at 2:55 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Fri, Nov 14, 2014 at 9:11 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Thu, Nov 13, 2014 at 10:37 PM, Amit Kapila <amit.kapila16@gmail.com>
>> wrote:
>> >>
>> >
>> > I have mentioned that this can be usable for Linux users as well on that
>> > thread, however I think we might want to provide it with an option for
>> > linux users.  In general, I think it is good to have this patch for
>> > Windows
>> > users and later if we find that Linux users can also get the benefit
>> > with
>> > this functionality, we can expose the same with an additional option.
>>
>> Why make it an option instead of just always doing it this way?
>>
> To avoid extra work during archive recovery if it is not required.  I
> understand that this might not create any measurable difference, but
> still there is addition I/O involved (read from file) which can be avoided.

Yeah, but it's trivial.  We're not going create enough tablespaces on
one cluster for the cost of dropping a few extra symlinks in place to
matter.

> OTOH, if that is okay, then I think we can avoid few #ifdef WIN32 that
> this patch introduces and can have consistency for this operation on
> both linux and Windows.

Having one code path for everything seems appealing to me, but what do
others think?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Segmentation fault in pg_dumpall from master down to 9.1 and other bug introduced by RLS
Next
From: Robert Haas
Date:
Subject: Re: Add CREATE support to event triggers