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+Tgmoa6A1EYWxXHw8wV=ccsOoZQy3+1OQ9sBGRyx1fyXCvs+Q@mail.gmail.com
Whole thread Raw
In response to Re: pg_basebackup vs. Windows and tablespaces  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_basebackup vs. Windows and tablespaces  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Fri, Nov 14, 2014 at 1:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Generally I'd be in favor of avoiding platform-dependent code where
> possible, but that doesn't represent a YES vote for this particular
> patch.  It looks pretty messy in a quick look, even granting that the
> #ifdef WIN32's would all go away.

Hmm, OK.  I have not read the patch.  Hopefully that's something that
could be fixed.

> A larger question here is about forward/backward compatibility of the
> basebackup files.  Changing the representation of symlinks like this
> would break that.  Maybe we don't care, not sure (is there already a
> catversion check for these things?).  Changing the file format for only
> some platforms seems like definitely a bad idea though.

What are the practical consequences of changing the file format?  I
think that an old backup containing symlinks could be made to work on
a new server that knows how to create them, and we should probably
design it that way, but a physical backup isn't compatible across
major versions anyway, so it doesn't have the same kinds of
repercussions as changing something like the pg_dump file format.

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



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: PostgreSQL doesn't stop propley when --slot option is specified with pg_receivexlog.
Next
From: Alvaro Herrera
Date:
Subject: Re: pg_basebackup vs. Windows and tablespaces