From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Andres Freund <andres(at)anarazel(dot)de>, Phil Florent <philflorent(at)hotmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgstat_report_activity() and parallel CREATE INDEX (was: Parallel index creation & pg_stat_activity) |
Date: | 2020-10-25 14:52:50 |
Message-ID: | 439665.1603637570@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Noah Misch <noah(at)leadboat(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Euler Taveira | 2020-10-25 16:09:27 | Re: deferred primary key and logical replication |
Previous Message | Julien Rouhaud | 2020-10-25 11:32:29 | Supporting = operator in gin/gist_trgm_ops |