Re: pgstat_report_activity() and parallel CREATE INDEX (was: Parallel index creation & pg_stat_activity)
От | Tom Lane |
---|---|
Тема | Re: pgstat_report_activity() and parallel CREATE INDEX (was: Parallel index creation & pg_stat_activity) |
Дата | |
Msg-id | 439665.1603637570@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgstat_report_activity() and parallel CREATE INDEX (was: Parallel index creation & pg_stat_activity) (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: pgstat_report_activity() and parallel CREATE INDEX (was: Parallel index creation & pg_stat_activity)
|
Список | pgsql-hackers |
Noah Misch <noah@leadboat.com> writes: > On Sat, Oct 17, 2020 at 08:39:35AM -0700, Peter Geoghegan wrote: >> I also prefer 2. > Thanks. Here is the pair of patches I plan to use. The second is equivalent > to v0; I just added a log message. The change in worker_spi_main seems a little weird/lazy. I'd be inclined to set and clear debug_query_string each time through the loop, so that those operations are adjacent to the other status-reporting operations, as they are in initialize_worker_spi. I don't really like modifying a StringInfo while debug_query_string is pointing at it, either. Yeah, you'll *probably* get away with that because the buffer is unlikely to move, but since the whole exercise can only benefit crash-debugging scenarios, it'd be better to be more paranoid. One idea is to set debug_query_string immediately before each SPI_execute and clear it just afterwards, rather than trying to associate it with pgstat_report_activity calls. regards, tom lane
В списке pgsql-hackers по дате отправления: