Re: [HACKERS] SIGSEGV in BRIN autosummarize
От | Alvaro Herrera |
---|---|
Тема | Re: [HACKERS] SIGSEGV in BRIN autosummarize |
Дата | |
Msg-id | 20171017105916.3rvmznxnuphn3uph@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: [HACKERS] SIGSEGV in BRIN autosummarize (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: [HACKERS] SIGSEGV in BRIN autosummarize
Re: [HACKERS] SIGSEGV in BRIN autosummarize Re: [HACKERS] SIGSEGV in BRIN autosummarize |
Список | pgsql-hackers |
Justin Pryzby wrote: > #1 0x00000000006a52e9 in perform_work_item (workitem=0x7f8ad1f94824) at autovacuum.c:2676 > cur_datname = 0x298c740 "no 1 :vartype 1184 :vartypmod -1 :varcollid 0 :varlevelsup 0 :varnoold 1 :varoattno 1:location 146} {CONST :consttype 1184 :consttypmod -1 :constcollid 0 :constlen 8 :constbyval true :constisnull fal"... > cur_nspname = 0x298c728 "s ({VAR :varno 1 :varattno 1 :vartype 1184 :vartypmod -1 :varcollid 0 :varlevelsup 0 :varnoold1 :varoattno 1 :location 146} {CONST :consttype 1184 :consttypmod -1 :constcollid 0 :constlen 8 :constbyv"... > cur_relname = 0x298cd68 "cdrs_eric_msc_sms_2017_10_14_startofcharge_idx" > __func__ = "perform_work_item" cur_datname here seems corrupted -- it points halfway into cur_nspname, which is also a corrupt value. And I think that's because we're not checking that the namespace OID is a valid value before calling get_namespace_name on it. And I'm betting that these values are all not what we expect, because we're not checking that we're in the correct database before trying to execute the work item. I don't quite understand how this results in an invalid string rather than just a NULL, as I would have expected. Anyway, can give this patch a try? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: