Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables
Вложения
В списке pgsql-bugs по дате отправления:
| От | Michael Paquier |
|---|---|
| Тема | Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables |
| Дата | |
| Msg-id | 20180906215836.GP2726@paquier.xyz обсуждение |
| Ответ на | BUG #15367: Crash in pg_fe_scram_free when using foreign tables (PG Bug reporting form <noreply@postgresql.org>) |
| Ответы |
Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables
|
| Список | pgsql-bugs |
On Thu, Sep 06, 2018 at 08:35:39PM +0000, PG Bug reporting form wrote: > If necessary I can build a debug version of PostgreSQL and try using that in > production so I can get a better backtrace if it crashes again. However, > considering that the crash is rare in my environment, it's unlikely I will > be able to produce a better backtrace for the error quickly. That would be nice. From what I can see this would be a race condition, which is not obvious by looking at the code. Testing with a two-node deployment where the first node has a foreign table which connects to a second node, using SCRAM authentication, holding the physical table, then doing many foreign scans across many clients don't show any problem. Did libpq complain at some point in the session where the crash happened about any error? -- Michael
В списке pgsql-bugs по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера