> I don't insist the name and the default of the GUC parameter.
> I'm afraid wal_fullpage_optimization = on (default) makes
> some confusion because the default behavior becomes a bit
> different on WAL itself.
Seems my wal_fullpage_optimization is not a good name if it caused
misinterpretation already :-(
> >> Amount of WAL after 60min. run of DBT-2 benchmark
> >> wal_add_optimization_info = off (default) 3.13GB
> > how about wal_fullpage_optimization = on (default)
The meaning of wal_fullpage_optimization = on (default)
would be the same as your wal_add_optimization_info = off (default).
(Reversed name, reversed meaning of the boolean value)
It would be there to *turn off* the (default) WAL full_page
For your pg_compresslog it would need to be set to off.
"add_optimization_info" sounded like added info about/for some
which it is not. We turn off an optimization with the flag for the
of an easier pg_compresslog implementation.
As already said I would decouple this setting from the part that sets
the "removeable full page" flag in WAL, and making the recovery able to
skip dummy records. This I would do unconditionally.
In response to
pgsql-hackers by date
|Next:||From: Andrew Dunstan||Date: 2007-04-23 16:19:20|
|Subject: Re: pgAdmin Query column width|
|Previous:||From: Dave Page||Date: 2007-04-23 12:44:07|
|Subject: Re: [Fwd: PGBuildfarm member narwhal Branch HEAD Status
changed from OK to InstallCheck failure]|
pgsql-patches by date
|Next:||From: Dorochevsky,Michel||Date: 2007-04-23 17:28:22|
|Subject: Re: BUG #3245: PANIC: failed to re-find shared loc k o b ject |
|Previous:||From: Neil Conway||Date: 2007-04-23 15:16:09|
|Subject: Re: fix LOCK_DEBUG|