Thread: AW: Proposed WAL changes

> Could GUC parameters be changed permanently e.g. by SET command ?
> 
> For example,
> 1) start postmaster
> 2) set archdir to '....'
> 3) shutdown postmaster

I thought the intended way to change a GUC parameter permanently was to 
edit data/postgresql.conf . No ?

Andreas

> > > What I've thought is to implement a new command to
> > > change archdir under WAL's control.
> > > If it's different from Vadim's plan I don't object.
> > 
> > Actually, I have no concrete plans for archdir yet - this
> > one is for WAL based BAR we should discuss in future.
> > So, I don't see why to remove archdir from pg_control now.
> 
> Maybe we can get BAR in 7.1.X so maybe we should have the 
> option to add it.

So, it's better to leave archdir in pg_control now - if we'll
decide that GUC is better place then we'll just ignore archdir
in pg_control. But if it will be better to have it in pg_control
then we'll not be able to add it there.

Vadim

"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
> So, it's better to leave archdir in pg_control now - if we'll
> decide that GUC is better place then we'll just ignore archdir
> in pg_control. But if it will be better to have it in pg_control
> then we'll not be able to add it there.

But what possible reason is there for keeping it in pg_control?
AFAICS that would just mean that we'd need special code for setting it,
instead of making use of all of Peter's hard work on GUC.

We should be moving away from special-case parameter mechanisms, not
inventing new ones without darn good reasons for them.
        regards, tom lane

Tom Lane wrote:
> 
> "Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
> > So, it's better to leave archdir in pg_control now - if we'll
> > decide that GUC is better place then we'll just ignore archdir
> > in pg_control. But if it will be better to have it in pg_control
> > then we'll not be able to add it there.
> 
> But what possible reason is there for keeping it in pg_control?
> AFAICS that would just mean that we'd need special code for setting it,
> instead of making use of all of Peter's hard work on GUC.
>

I don't think it's appropriate to edit archdir by hand.

Regards,
Hiroshi Inoue

Hiroshi Inoue <Inoue@tpf.co.jp> writes:
>> But what possible reason is there for keeping it in pg_control?
>> AFAICS that would just mean that we'd need special code for setting it,
>> instead of making use of all of Peter's hard work on GUC.

> I don't think it's appropriate to edit archdir by hand.

Why not?  How is this a critical parameter (more critical than, say,
fsync enable)?  I see no reason to forbid the administrator from
changing it ... indeed, I think an admin who found out he couldn't
change it on-the-fly would be justifiably unhappy.  ("What do you
MEAN I can't change archdir?  I'm about to run out of space in
/usr/logs/foobar!!!")

I agree that we don't want random users changing the value via SET and
then issuing a CHECKPOINT (which would use whatever they'd SET :-().
But that's easily managed by setting an appropriate protection level
on the GUC variable.  Looks like SIGHUP level would be appropriate.
        regards, tom lane

Tom Lane wrote:
> 
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> >> But what possible reason is there for keeping it in pg_control?
> >> AFAICS that would just mean that we'd need special code for setting it,
> >> instead of making use of all of Peter's hard work on GUC.
> 
> > I don't think it's appropriate to edit archdir by hand.
> 
> Why not?  How is this a critical parameter (more critical than, say,
> fsync enable)? 

I don't think 'fsync enable' is a critical parameter.
It's a dangerous parameter and it's not appropriate
as a GUC paramter either. Does it have any meaning
other than testing ? IMHO recovery system doesn't
allow any optimism and archdir is also a part of
recovery system though I'm not sure how critical
the parameter would be.

Regards,
Hiroshi Inoue

Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> Tom Lane wrote:
>> Why not?  How is this a critical parameter (more critical than, say,
>> fsync enable)? 

> I don't think 'fsync enable' is a critical parameter.
> It's a dangerous parameter and it's not appropriate
> as a GUC paramter either.

That's also PGC_SIGHUP (recently fixed by me, it was set at a lower level
before).

> Does it have any meaning other than testing ? IMHO recovery system
> doesn't allow any optimism and archdir is also a part of recovery
> system though I'm not sure how critical the parameter would be.

I still don't see your point.  The admin *can* change these parameters
if he wishes.  Why should we make it more difficult to do so than is
reasonably necessary?  There is certainly no technical reason why we
should (say) force an initdb to change archdir.
        regards, tom lane

Tom Lane wrote:
> 
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > Tom Lane wrote:
> >> Why not?  How is this a critical parameter (more critical than, say,
> >> fsync enable)?
> 
> > Does it have any meaning other than testing ? IMHO recovery system
> > doesn't allow any optimism and archdir is also a part of recovery
> > system though I'm not sure how critical the parameter would be.
> 
> I still don't see your point.  The admin *can* change these parameters
> if he wishes.  Why should we make it more difficult to do so than is
> reasonably necessary?  There is certainly no technical reason why we
> should (say) force an initdb to change archdir.
> 

I've never objected to change archdir on the fly.
Though GUC is profitable for general purpose it
could(must)n't be almighty. As for recovery 
we must rely on DBA as less as possible. 

Hiroshi Inoue