Re: pg_tablespace_location() failure with allow_in_place_tablespaces - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_tablespace_location() failure with allow_in_place_tablespaces
Date
Msg-id Yttj1iOTrw7zW2J+@paquier.xyz
Whole thread Raw
In response to Re: pg_tablespace_location() failure with allow_in_place_tablespaces  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On Fri, Jul 22, 2022 at 05:50:58PM +1200, Thomas Munro wrote:
> On Thu, Mar 31, 2022 at 5:01 PM Michael Paquier <michael@paquier.xyz> wrote:
>> Yeah, I saw that in-place tablespaces were part of the main tarball in
>> base backups as we rely on the existence of a link to decide if the
>> contents of a path should be separated in a different tarball or not.
>> This does not strike me as a huge problem in itself, TBH, as the
>> improvement would be limited to make sure that the base backups could
>> be correctly restored with multiple tablespaces.  And you can get
>> pretty much the same amount of coverage to make sure that the backup
>> contents are correct without fully restoring them.
>
> Are they in the main tar file, or are they just missing?

So, coming back to this thread..  Sorry for the late reply.

Something is still broken here with in-place tablespaces on HEAD.
When taking a base backup in plain format, in-place tablespaces are
correctly in the stream.  However, when using the tar format, these
are not streamed.  c6f2f01 has cleaned the WARNING "could not read
symbolic link", still we have the following, when having an in-place
tablespace on a primary:
- For a base backup in plain format, the in-place tablespace path is
included in the base backup.
- For a base backup in tar format, the in-place tablespace path is not
included in the base backup.  It is not in base.tar, and there is no
additional tar file.  c6f2f01 does not change this result.

So they are missing, to answer your question.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Interpretation of docs for \copy ... from stdin inaccurate when using -c
Next
From: Michael Paquier
Date:
Subject: Re: Reducing logs produced by TAP tests running pg_regress on crash