From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Melanie Plageman <melanieplageman(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Calling PrepareTempTablespaces in BufFileCreateTemp |
Date: | 2019-04-22 23:07:28 |
Message-ID: | 31235.1555974448@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> On Mon, Apr 22, 2019 at 3:12 PM Melanie Plageman
> <melanieplageman(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-04-22 23:11:54 | Re: pg_dump is broken for partition tablespaces |
Previous Message | Tomas Vondra | 2019-04-22 23:07:18 | Re: finding changed blocks using WAL scanning |