Re: pgsql: Fix another instance of unsafe coding for shm_toc_lookup failure
От | Tom Lane |
---|---|
Тема | Re: pgsql: Fix another instance of unsafe coding for shm_toc_lookup failure |
Дата | |
Msg-id | 9324.1517623729@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql: Fix another instance of unsafe coding for shm_toc_lookup failure (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: pgsql: Fix another instance of unsafe coding for shm_toc_lookup failure
|
Список | pgsql-committers |
Thomas Munro <thomas.munro@enterprisedb.com> writes: > On Sat, Feb 3, 2018 at 12:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Fix another instance of unsafe coding for shm_toc_lookup failure. > my mistake was actually to put noError = true there when noError = > false was called for. Ah. > However, it's not surprising that you drew the > opposite conclusion (ie that it might in fact not be in the TOC), > since the shm space is really only necessary for EXPLAIN ANALYZE. > Perhaps I should make it skip setting up this shm stuff if > !node->ss.ps.instrument, just like the equivalent Sort node code. I > will look into that on Monday. OK. Please send in a patch to either do that or switch this call to use noError = false. Or possibly both: shouldn't there be some other signal path that tells the worker whether instrumentation is needed? I'll leave it alone pending your investigation. regards, tom lane
В списке pgsql-committers по дате отправления: