Re: pg_tablespace_location() failure with allow_in_place_tablespaces

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Subject: Re: pg_tablespace_location() failure with allow_in_place_tablespaces
Date: 2022-07-23 02:58:30
Message-ID: Yttj1iOTrw7zW2J+@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)paquier(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-07-23 03:07:25 Re: Reducing logs produced by TAP tests running pg_regress on crash
Previous Message David G. Johnston 2022-07-23 01:28:41 Interpretation of docs for \copy ... from stdin inaccurate when using -c