Re: Calling PrepareTempTablespaces in BufFileCreateTemp
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Ashwin Agrawal <aagrawal@pivotal.io>, Peter Geoghegan <pg@bowt.ie>, Melanie Plageman <melanieplageman@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2019-04-26T06:53:30Z
Lists: pgsql-hackers
Attachments
- assert-that-temp-tablespaces-are-prepared-v2.patch (text/x-diff) patch v2
On Thu, Apr 25, 2019 at 12:45:03PM -0400, Tom Lane wrote: > I still remain concerned that invoking catalog lookups from fd.c is a darn > bad idea, even if we have a fallback for it to work (for some value of > "work") in non-transactional states. It's not really hard to envision > that kind of thing leading to infinite recursion. I think it's safe > right now, because catalog fetches shouldn't lead to any temp-file > access, but that's sort of a rickety assumption isn't it? Introducing catalog lookups into fd.c which is not a layer designed for that is a choice that I find strange, and I fear that it may bite in the future. I think that the choice proposed upthread to add an assertion on TempTablespacesAreSet() when calling a function working on temporary data is just but fine, and that we should just make sure that the gist code calls PrepareTempTablespaces() correctly. So [1] is a proposal I find much more acceptable than the other one. I think that one piece is missing from the patch. Wouldn't it be better to add an assertion at the beginning of OpenTemporaryFile() to make sure that PrepareTempTablespaces() has been called when interXact is true? We could just go with that: Assert(!interXact || TempTablespacesAreSet()); And this gives me the attached. [1]: https://postgr.es/m/11777.1556133426@sss.pgh.pa.us -- Michael
Commits
-
Make BufFileCreateTemp() ensure that temp tablespaces are set up.
- 93f03dad824f 12.0 landed