Re: pgsql: Allow concurrent-safe open() and fopen() in frontend codefor Wi

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: pgsql: Allow concurrent-safe open() and fopen() in frontend codefor Wi
Дата
Msg-id 20180919235820.GA1338@paquier.xyz
обсуждение исходный текст
Ответ на Re: pgsql: Allow concurrent-safe open() and fopen() in frontend code for Wi  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pgsql: Allow concurrent-safe open() and fopen() in frontendcode for Wi  (Laurenz Albe <laurenz.albe@cybertec.at>)
Список pgsql-hackers
On Wed, Sep 19, 2018 at 11:55:01AM -0400, Tom Lane wrote:
> I'm OK with this approach.  I wonder though what happens if you take
> away the "#ifdef FRONTEND" and just enforce that one or the other mode
> is selected always.  That would seem like a sensible solution rather
> than a wart to me ...

Thanks, I have pushed the solution from Laurenz to maintain pure
compatibility.  The origin of the failures reported by pg_dump actually
comes from a mismatch with pg_hba.conf in the way users and/or databases
are parsed.  I am glad that we have tests for the full range of ASCII
characters in TAP so as it is easy to detect regressions at early
stages.  We could try to manipulate more setmode calls like the one in
miscinit.c so as authentication gets the right call.  I am not sure of
other side effects though...
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: SIGDANGER and oomd
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: heap_sync seems rather oblivious to partitioned tables(wal_level=minimal)