Skip site navigation (1) Skip section navigation (2)

Re: Converting postgresql.conf parameters to kilobytes

From: Shridhar Daithankar <shridhar(at)frodo(dot)hserus(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Converting postgresql.conf parameters to kilobytes
Date: 2004-06-01 12:31:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tuesday 01 June 2004 14:12, Shridhar Daithankar wrote:
> Actually I need to find out few more things about it. It is not as simple
> as adding a assign_hook. When I tried to initdb with changes, it demanded
> 64MB of shared buffers which I (now) think that somewhere NBuffers are used
> before postgresql.conf is parsed. So 8192*8000=64MB. But this is just
> guesswork. Haven't looked in it there.

Found  it. Following is the code that is causing problem.

				if (conf->assign_hook)
					if (!(*conf->assign_hook) (newval, changeVal, source))
								 errmsg("invalid value for parameter \"%s\": %d",
										name, newval)));
						return false;

				if (changeVal || makeDefault)
					if (changeVal)
						*conf->variable = newval;
						conf->gen.source = source;

So even if assign_hook is executed, the value of variable is overwritten in 
next step which nullifies any factoring/change in value done in assign hook.

I find this as a convention at many other place at guc.c. Call assign_hook and 
the overwrite the value. So is assign_hook called only to validate the value?  
How do I modify the value of the variable without getting specific?

I tried 

if (changeVal && !(conf->assign_hook))

and it worked. However that is just for int variables. I am not sure if that 
is a design decision. What should I do?


In response to


pgsql-hackers by date

Next:From: Manfred KoizarDate: 2004-06-01 12:37:37
Subject: Re: SELECT * FROM <table> LIMIT 1; is really slow
Previous:From: Shridhar DaithankarDate: 2004-06-01 08:42:39
Subject: Re: Converting postgresql.conf parameters to kilobytes

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group