Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
От | Tomas Vondra |
---|---|
Тема | Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation) |
Дата | |
Msg-id | 467b6450-8274-ad2f-ce2e-188fa439a52c@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation) (Peter Geoghegan <pg@bowt.ie>) |
Список | pgsql-hackers |
On 02/06/2018 10:39 PM, Peter Geoghegan wrote: > On Tue, Feb 6, 2018 at 1:30 PM, Tomas Vondra > <tomas.vondra@2ndquadrant.com> wrote: >> I have little idea what -Og exactly means. It seems to be focused on >> debugging experience, and so still does some of the optimizations. > > As I understand it, -Og allows any optimization that does not hamper > walking through code with a debugger. > >> Which >> I think would explain why skink was not detecting some of the failures >> for a long time. > > I think that skink didn't detect failures until now because the code > wasn't exercised until parallel CREATE INDEX was added, simply because > the function LogicalTapeFreeze() was never reached (though that's not > the only reason, it is the most obvious one). > Maybe. What I had in mind was a different thread from November, discussing some non-deterministic valgrind failures: https://www.postgresql.org/message-id/flat/20171125200014.qbewtip5oydqsklt%40alap3.anarazel.de#20171125200014.qbewtip5oydqsklt@alap3.anarazel.de But you're right that may be irrelevant here. As I said, it was mostly just a random comment about valgrind. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: