Re: Calling PrepareTempTablespaces in BufFileCreateTemp
От | Peter Geoghegan |
---|---|
Тема | Re: Calling PrepareTempTablespaces in BufFileCreateTemp |
Дата | |
Msg-id | CAH2-WznA=s0j0Cv4WOnECM7uWqgtWHoXTMZZ0CMF7A54GuWwBA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Calling PrepareTempTablespaces in BufFileCreateTemp (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Calling PrepareTempTablespaces in BufFileCreateTemp
Re: Calling PrepareTempTablespaces in BufFileCreateTemp |
Список | pgsql-hackers |
On Wed, Apr 24, 2019 at 12:17 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > After a bit more thought it seemed like another answer would be to > make all three of those functions assert that the caller did the > right thing, as per attached. This addresses the layering-violation > complaint, but might be more of a pain in the rear for developers. In what sense is it not already a layering violation to call PrepareTempTablespaces() as often as we do? PrepareTempTablespaces() parses and validates the GUC variable and passes it to fd.c, but to me that seems almost the same as calling the fd.c function SetTempTablespaces() directly. PrepareTempTablespaces() allocates memory that it won't free itself within TopTransactionContext. I'm not seeing why the context that the PrepareTempTablespaces() catalog access occurs in actually matters. Like you, I find it hard to prefer one of the approaches over the other, though I don't really know how to assess this layering business. I'm glad that either approach will prevent oversights, though. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: