Thread: vacuum_defer_cleanup_age

vacuum_defer_cleanup_age

From
Fujii Masao
Date:
Hi,

vacuum_defer_cleanup_age is categorized as "Statement Behavior"
parameter in the document. On the other hand, it's categorized
as "Hot Standby" one in postgresql.conf. Why do we need to do so?

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


Re: vacuum_defer_cleanup_age

From
Heikki Linnakangas
Date:
On 11/06/10 05:36, Fujii Masao wrote:
> vacuum_defer_cleanup_age is categorized as "Statement Behavior"
> parameter in the document. On the other hand, it's categorized
> as "Hot Standby" one in postgresql.conf. Why do we need to do so?

Yeah, there's clearly a mismatch. I think "Hot Standby" is the right 
place, altough you could argue that it should be together with 
vacuum_freeze_min_age and vacuum_freeze_table_age too.

We seem to be missing an entry for "Write-Ahead Log / Hot Standby" in 
the config_group_names list in guc.c. hot_standby GUC marked to beling 
in WAL_SETTINGS in guc.c.

What's the policy with that, should all the sections in the sample 
config file and docs have a corresponding enum in config_group_names? I 
guess they should, but many of them seem to be missing. There's no 
separate entry in config_group_names for "Write-Ahead Log / Archiving", 
"Resource Usage / Cost-Based Vacuum Delay" and "Resource Usage / 
Asynchronous Behavior" either, for example.

Should I add entries in the enum for all the missing ones?

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


Re: vacuum_defer_cleanup_age

From
Fujii Masao
Date:
On Fri, Jun 11, 2010 at 7:25 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> Yeah, there's clearly a mismatch. I think "Hot Standby" is the right place,
> altough you could argue that it should be together with
> vacuum_freeze_min_age and vacuum_freeze_table_age too.
>
> We seem to be missing an entry for "Write-Ahead Log / Hot Standby" in the
> config_group_names list in guc.c. hot_standby GUC marked to beling in
> WAL_SETTINGS in guc.c.
>
> What's the policy with that, should all the sections in the sample config
> file and docs have a corresponding enum in config_group_names? I guess they
> should, but many of them seem to be missing. There's no separate entry in
> config_group_names for "Write-Ahead Log / Archiving", "Resource Usage /
> Cost-Based Vacuum Delay" and "Resource Usage / Asynchronous Behavior"
> either, for example.
>
> Should I add entries in the enum for all the missing ones?

+1. This seems sensible.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


GUC category cleanup (was: vacuum_defer_cleanup_age)

From
Takahiro Itagaki
Date:
Fujii Masao <masao.fujii@gmail.com> wrote:

> On Fri, Jun 11, 2010 at 7:25 PM, Heikki Linnakangas
> > What's the policy with that, should all the sections in the sample config
> > file and docs have a corresponding enum in config_group_names?
>
> +1. This seems sensible.

Here is a patch to do that. I used terms in the documentation for category
names. Also, some uncategorized variables moved into detailed groups.

Added categories:
  Resource Usage / Cost-Based Vacuum Delay
  Resource Usage / Background Writer
  Resource Usage / Asynchronous Behavior
  Write-Ahead Log / Archiving
  Write-Ahead Log / Standby Servers

Renamed in the configuration file:
  Replication ==> Streaming Replication
  Hot Standby ==> Standby Servers

Regards,
---
Takahiro Itagaki
NTT Open Source Software Center


Attachment

Re: GUC category cleanup

From
Heikki Linnakangas
Date:
On 15/06/10 08:09, Takahiro Itagaki wrote:
>
> Fujii Masao<masao.fujii@gmail.com>  wrote:
>
>> On Fri, Jun 11, 2010 at 7:25 PM, Heikki Linnakangas
>>> What's the policy with that, should all the sections in the sample config
>>> file and docs have a corresponding enum in config_group_names?
>>
>> +1. This seems sensible.
>
> Here is a patch to do that. I used terms in the documentation for category
> names. Also, some uncategorized variables moved into detailed groups.

Thanks, looks good to me.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com