On Fri, Apr 3, 2015 at 5:57 AM, Alvaro Herrera wrote:
You added this in the worker loop processing each table:
/*
* Check for config changes before processing each collected
table.
*/
if (got_SIGHUP)
{
Michael Paquier wrote:
On Fri, Apr 3, 2015 at 3:26 PM, Michael Paquier wrote:
[...]
Fine for me.
And here are the correct patches. Sorry for that.
Thanks, pushed. I added one extra comment to the SIGHUP patch in the
place where you previously had the exit.
--
Álvaro Herrera
On Fri, Apr 3, 2015 at 11:59 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Michael Paquier wrote:
On Fri, Apr 3, 2015 at 3:26 PM, Michael Paquier wrote:
[...]
Fine for me.
And here are the correct patches. Sorry for that.
Thanks, pushed. I added one extra comment to the SIGHUP
Michael Paquier wrote:
So, attached are two patches:
- 0001 enables SIGHUP tracking in do_autovacuum(), which is checked
before processing one table. I reused avl_sighup_handler for the
worker, renaming it av_sighup_handler..
- 0002 is the patch to add log_autovacuum_min_duration as a
--- a/doc/src/sgml/ref/create_table.sgml
+++ b/doc/src/sgml/ref/create_table.sgml
@@ -881,9 +881,11 @@ CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } |
UNLOGGED ] TABLE [ IF NOT EXI
literaltoast./literal, which can be used to control the behavior of the
table's secondary
Michael Paquier wrote:
In AutoVacWorkerMain, I am reading the following:
* Currently, we don't pay attention to postgresql.conf changes that
* happen during a single daemon iteration, so we can ignore SIGHUP.
*/
pqsignal(SIGHUP, SIG_IGN);
So a worker
On Mon, Mar 23, 2015 at 7:07 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Michael Paquier wrote:
So a worker does not see changes in postgresql.conf once it is run and
processes a database, no? The launcher does run ProcessConfigFile()
when
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Michael Paquier wrote:
So a worker does not see changes in postgresql.conf once it is run and
processes a database, no? The launcher does run ProcessConfigFile()
when SIGHUP shows up though.
Maybe this is something that we should change.
Yeah,
Jeff Janes jeff.ja...@gmail.com writes:
On Mon, Mar 23, 2015 at 7:07 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah, checking for SIGHUP in the worker outer loop (ie once per table)
seems like a reasonable thing.
Could it be done more often? Maybe every time it is about to do a
cost_delay
On Mon, Mar 23, 2015 at 11:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Michael Paquier wrote:
So a worker does not see changes in postgresql.conf once it is run and
processes a database, no? The launcher does run ProcessConfigFile()
when SIGHUP
On Thu, Mar 19, 2015 at 1:43 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Thu, Mar 19, 2015 at 12:40 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Thu, Mar 19, 2015 at 12:23 PM, Fujii Masao masao.fu...@gmail.com wrote:
Are you planning to update the patch so that it's
On Mon, Mar 23, 2015 at 1:54 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Mar 19, 2015 at 1:43 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Thu, Mar 19, 2015 at 12:40 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Thu, Mar 19, 2015 at 12:23 PM, Fujii Masao
On Fri, Mar 6, 2015 at 1:07 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Fri, Mar 6, 2015 at 12:44 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Mar 5, 2015 at 9:49 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Thu, Mar 5, 2015 at 7:10 PM, Fujii Masao wrote:
With
On Thu, Mar 19, 2015 at 12:23 PM, Fujii Masao masao.fu...@gmail.com wrote:
Are you planning to update the patch so that it's based on the commit 0d83138?
Yes... Very soon.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Thu, Feb 19, 2015 at 3:32 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Thu, Feb 19, 2015 at 2:13 PM, Naoya Anzai
anzai-na...@mxu.nes.nec.co.jp wrote:
As a result, I think you should not delete VACOPT_VERBOSE.
In v8 it is not deleted. It is still declared, and its use is isolated
On Thu, Mar 5, 2015 at 9:49 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Thu, Mar 5, 2015 at 7:10 PM, Fujii Masao wrote:
With the patch, VACUUM ANALYZE VERBOSE doesn't emit any verbose message.
Why did you remove that functionality?
Oops. Sorry about that. In gram.y, the
Hi, Michael
I found that definition of VERBOSE and log_autovacuum is not
pretty match. For example, VERBOSE can output logs of
scanning indices and scanning detail of analyze, but
log_autovacuum can't output them.
Please see following sequences.
1. execute these queries.
DROP TABLE t1;
On Thu, Feb 12, 2015 at 5:44 PM, Naoya Anzai anzai-na...@mxu.nes.nec.co.jp
wrote:
Hi, Michael-san
An updated patch is attached,
I'm sorry for confusing you.
I think you don't have to implement this code to disable this
feature with using value -2.Because this use case is a rare case,
You mean that ...
Log_autovacuum_min_duration assumes a role of VACOPT_VERBOSE.
Even if this parameter never use currently for manual vacuum,
log_autovacuum_min_duration should be set zero(anytime output)
when we executes VACUUM(or ANALYZE) VERBOSE.
Is my understanding correct? If so,it
Hi, Michael-san
An updated patch is attached,
I'm sorry for confusing you.
I think you don't have to implement this code to disable this
feature with using value -2.Because this use case is a rare case,
and there is a practical workaround using huge value like 2e9.
(You suggested 2e9 to me,
On Fri, Feb 13, 2015 at 10:16 AM, Naoya Anzai
anzai-na...@mxu.nes.nec.co.jp wrote:
You mean that ...
Log_autovacuum_min_duration assumes a role of VACOPT_VERBOSE.
Even if this parameter never use currently for manual vacuum,
log_autovacuum_min_duration should be set zero(anytime output)
when
Thanks for your reply.
Feature test
(snip)
I thought about using a
special value like -2 to define the behavior you are mentioning here,
aka with -2 disable custom value and GUC parameter but I don't think
it is worth adding as that's an ugly 3 line of code of this
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: tested, failed
Documentation:tested, failed
Hi,
I'm Naoya Anzai.
I've been working as a PostgreSQL
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: tested, failed
Documentation:tested, failed
I'm sorry, I just sent it by mistake.
All of them have
On Fri, Feb 6, 2015 at 4:50 AM, Naoya Anzai
anzai-na...@mxu.nes.nec.co.jp wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: tested, failed
Documentation:
On Sat, Dec 20, 2014 at 9:17 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
But now, here are some things to consider if we use directly the
reloptions available with RelationData:
- If the parameters toast.autovacuum_* are not set, toast relations
inherit values from their parent
On Thu, Dec 18, 2014 at 11:15 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Michael Paquier wrote:
Hi all,
Today I spent a bit of time looking at the activity of autovacuum for
one table particularly bloated. log_autovacuum_min_duration was
enabled and set to a high value but even with
Hi all,
Today I spent a bit of time looking at the activity of autovacuum for
one table particularly bloated. log_autovacuum_min_duration was
enabled and set to a high value but even with that I had to deal with
some spam from the jobs of other tables. It would be cool to have the
possibility to
Michael Paquier wrote:
Hi all,
Today I spent a bit of time looking at the activity of autovacuum for
one table particularly bloated. log_autovacuum_min_duration was
enabled and set to a high value but even with that I had to deal with
some spam from the jobs of other tables. It would be
29 matches
Mail list logo
