Re: Calling PrepareTempTablespaces in BufFileCreateTemp - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Calling PrepareTempTablespaces in BufFileCreateTemp
Date
Msg-id 31235.1555974448@sss.pgh.pa.us
Whole thread Raw
In response to Re: Calling PrepareTempTablespaces in BufFileCreateTemp  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Calling PrepareTempTablespaces in BufFileCreateTemp
List pgsql-hackers
Peter Geoghegan <pg@bowt.ie> writes:
> On Mon, Apr 22, 2019 at 3:12 PM Melanie Plageman
> <melanieplageman@gmail.com> wrote:
>> PrepareTempTablespaces is called by most callers of BufFileCreateTemp, so I was
>> wondering if there is a reason not to call it inside BufFileCreateTemp.

> The best answer I can think of is that a BufFileCreateTemp() caller
> might not want to do catalog access. Perhaps the contortions within
> assign_temp_tablespaces() are something that callers ought to opt in
> to explicitly.

It's kind of hard to see a reason to call it outside a transaction,
and even if we did, there are provisions for it not to go boom.

> That doesn't seem like a particularly good or complete answer, though.
> Perhaps it should simply be called within BufFileCreateTemp(). The
> BufFile/fd.c layering is confusing in a number of ways IMV.

I don't actually see why BufFileCreateTemp should do it; if
we're to add a call, seems like OpenTemporaryFile is the place,
as that's what is really concerned with the temp tablespace(s).

I'm in favor of doing this, I think, as it sure looks to me like
gistInitBuildBuffers() is calling BufFileCreateTemp without any
closely preceding PrepareTempTablespaces.  So we already have an
instance of Melanie's bug in core.  It'd be difficult to notice
because of the silent-fallback-to-default-tablespace behavior.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: finding changed blocks using WAL scanning
Next
From: Tom Lane
Date:
Subject: Re: pg_dump is broken for partition tablespaces