Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> 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 al
Hiroshi Inoue <[EMAIL PROTECTED]> 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
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> 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 a
Hiroshi Inoue <[EMAIL PROTECTED]> 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
Tom Lane wrote:
>
> "Mikheev, Vadim" <[EMAIL PROTECTED]> 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 a
"Mikheev, Vadim" <[EMAIL PROTECTED]> 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 possi
> > > 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
"Vadim Mikheev" <[EMAIL PROTECTED]> writes:
> So, I don't see why to remove archdir from pg_control now.
I didn't like the space consumption. I think it's important that the
pg_control data fit in less than 512 bytes so that it doesn't cross
physical sectors on the disk. This reduces the odds o
> > > I thought the intended way to change a GUC parameter permanently was to
> > > edit data/postgresql.conf . No ?
> > >
> >
> > 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 h
> > I thought the intended way to change a GUC parameter permanently was to
> > edit data/postgresql.conf . No ?
> >
>
> 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 pla
Zeugswetter Andreas SB wrote:
>
> > 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/postgr
> 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
> >> Remove archdir from pg_control; it ought to be a GUC
> >> parameter, not a special case (not that it's implemented
> yet anyway).
>
> > Is archdir really a GUC parameter ?
>
> Why shouldn't it be? I see nothing wrong with changing it on-the-fly.
Yes, I think this is a good change, like
13 matches
Mail list logo
