On Fri, Apr 3, 2015 at 11:59 PM, Alvaro Herrera
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 patch in the
>
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 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)
>
--- 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
toast., which can be used to control the behavior of the
table's secondary TOAST table, if any
(se
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 re
Michael Paquier wrote:
> On Mon, Mar 23, 2015 at 11:07 PM, Tom Lane wrote:
> > Alvaro Herrera 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 SIGHU
On Mon, Mar 23, 2015 at 11:07 PM, Tom Lane wrote:
> Alvaro Herrera 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
Jeff Janes writes:
> On Mon, Mar 23, 2015 at 7:07 AM, Tom Lane 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 sleep?
That sounds risky from here.
On Mon, Mar 23, 2015 at 7:07 AM, Tom Lane wrote:
> Alvaro Herrera 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
Alvaro Herrera 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, checking for SIG
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 w
On Mon, Mar 23, 2015 at 1:54 PM, Fujii Masao wrote:
> On Thu, Mar 19, 2015 at 1:43 PM, Michael Paquier
> wrote:
>> On Thu, Mar 19, 2015 at 12:40 PM, Michael Paquier
>> wrote:
>>> On Thu, Mar 19, 2015 at 12:23 PM, Fujii Masao wrote:
Are you planning to update the patch so that it's based on
On Thu, Mar 19, 2015 at 1:43 PM, Michael Paquier
wrote:
> On Thu, Mar 19, 2015 at 12:40 PM, Michael Paquier
> wrote:
>> On Thu, Mar 19, 2015 at 12:23 PM, Fujii Masao wrote:
>>> Are you planning to update the patch so that it's based on the commit
>>> 0d83138?
>>
>> Yes... Very soon.
>
> And her
On Thu, Mar 19, 2015 at 12:23 PM, Fujii Masao 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:
http://www.postgresql.
On Fri, Mar 6, 2015 at 1:07 PM, Michael Paquier
wrote:
> On Fri, Mar 6, 2015 at 12:44 PM, Fujii Masao wrote:
>> On Thu, Mar 5, 2015 at 9:49 PM, Michael Paquier
>> wrote:
>>> On Thu, Mar 5, 2015 at 7:10 PM, Fujii Masao wrote:
With the patch, VACUUM ANALYZE VERBOSE doesn't emit any verbose me
On Thu, Mar 5, 2015 at 9:49 PM, Michael Paquier
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 combination of VacuumStmt wit
On Thu, Feb 19, 2015 at 3:32 PM, Michael Paquier
wrote:
> On Thu, Feb 19, 2015 at 2:13 PM, Naoya Anzai
> 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
> in gram.y, similarly to VACOPT_FREEZE.
>
>> Ac
On Thu, Feb 19, 2015 at 2:13 PM, Naoya Anzai
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
in gram.y, similarly to VACOPT_FREEZE.
> According to the last mail I have posted, the difference of
> manual-va
Hi, Michael
I thought about VACOPT_VERBOSE again.
As a result, I think you should not delete VACOPT_VERBOSE.
According to the last mail I have posted, the difference of
manual-vacuum log and auto-vacuum log exists clearly.
So, at least you should not touch the mechanism of VACOPT_VERBOSE
until
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;
C
On Fri, Feb 13, 2015 at 10:16 AM, Naoya Anzai
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 we executes "VA
>> 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?
On Thu, Feb 12, 2015 at 5:44 PM, Naoya Anzai
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,
> and there is a pract
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
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
On Fri, Feb 6, 2015 at 4:50 AM, Naoya Anzai
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:tested, fa
> 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 ha
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 Suppo
On Sat, Dec 20, 2014 at 9:17 AM, Michael Paquier
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 relation. Looking at autovac
On Thu, Dec 18, 2014 at 11:15 PM, Alvaro Herrera
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 that I had 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 b
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 d
32 matches
Mail list logo
