On Tue, Jul 28, 2015 at 2:38 PM, Tom Lane wrote:
> Kevin Grittner writes:
> > Tom Lane wrote:
> >> Kevin Grittner writes:
> >>> I think a LOG entry when an autovacuum process is actually canceled
> >>> has value
Jeff Janes writes:
> On Tue, Jul 28, 2015 at 2:38 PM, Tom Lane wrote:
>> Rather than remove the "sending signal" elog entirely, I reduced it to
>> DEBUG1; that will avoid log chatter for normal cases but the info can
>> still be obtained at need.
> This
Kevin Grittner kgri...@ymail.com writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com writes:
I think a LOG entry when an autovacuum process is actually canceled
has value just in case it is happening on a particular table so
frequently that the table starts to bloat.
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com writes:
I think a LOG entry when an autovacuum process is actually canceled
has value just in case it is happening on a particular table so
frequently that the table starts to bloat. I see no reason to log
anything if there
chipmunk failed last night
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=chipmunkdt=2015-07-26%2007%3A36%3A32
like so:
== pgsql.build/src/test/regress/regression.diffs
===
***
Hi,
On 2015-07-26 10:56:05 -0400, Tom Lane wrote:
CREATE INDEX tenk2_unique1 ON tenk2 USING btree(unique1 int4_ops);
+ WARNING: could not send signal to process 30123: No such process
What's evidently happened here is that our session tried to boot an
autovacuum process off a table lock,
Andrew Dunstan and...@dunslane.net writes:
On 07/26/2015 11:00 AM, Andres Freund wrote:
On 2015-07-26 10:56:05 -0400, Tom Lane wrote:
I'm inclined to reduce the WARNING to LOG
Hm, that doesn't seem like a very nice solution, given that LOG is even
more likely to end up in the server log.
Tom Lane t...@sss.pgh.pa.us wrote:
+ WARNING: could not send signal to process 30123: No such process
What's evidently happened here is that our session tried to boot an
autovacuum process off a table lock, only that process was gone by the
time we issued the kill() call.
I'm inclined to