Re: BUG #15144: *** glibc detected *** postgres: postgres smsconsole [local] SELECT: double free or corruption (!pre
От | Vitaly V. Voronov |
---|---|
Тема | Re: BUG #15144: *** glibc detected *** postgres: postgres smsconsole [local] SELECT: double free or corruption (!pre |
Дата | |
Msg-id | 2139451523901937@web24o.yandex.ru обсуждение исходный текст |
Ответ на | Re: BUG #15144: *** glibc detected *** postgres: postgres smsconsole[local] SELECT: double free or corruption (!pre (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: BUG #15144: *** glibc detected *** postgres: postgres smsconsole[local] SELECT: double free or corruption (!pre
|
Список | pgsql-bugs |
Hello, Peter. Pgpool used only from App side at another server. Zabbix running its queries directly at database server. 16.04.2018, 21:03, "Peter Geoghegan" <pg@bowt.ie>: > On Mon, Apr 16, 2018 at 10:48 AM, Alvaro Herrera > <alvherre@alvh.no-ip.org> wrote: >> and tuplestore_end does this: >> if (state->myfile) >> BufFileClose(state->myfile); >> without setting anything in state to NULL; so we're relying on the >> caller fs->tstore to null to avoid repeated tuplestore_end calls. I >> can't see any way for this to misbehave, but maybe the funcstate appears >> more than once in the PerFuncState array, and we clean it correctly the >> first time around and then invoke the tuplestore_end() the second time >> to the memory that was previously freed? I think this makes no sense >> unless we share FunctionScanPerFuncState elements -- do we? > > I have no reason to think that we do. Offhand, I find it more likely > that some executor slot that imagines that it owns the tuple frees the > tuple once, which is followed by a call to tuplestore_end() that frees > the same tuple a second time (a double-free). As I mentioned, we've > seen several bugs of that general variety in both tuplestore and > tuplesort in the past. Some of these have been very subtle. > > Note that pgpool is involved here. I don't know much about pgpool, and > maybe that's totally irrelevant. > > -- > Peter Geoghegan
В списке pgsql-bugs по дате отправления: