Re: Proposal for Allow postgresql.conf values to be changed via SQL [review] - Mailing list pgsql-hackers

From Amit kapila
Subject Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Date
Msg-id 6C0B27F7206C9E4CA54AE035729E9C383BEA71C9@szxeml509-mbx
Whole thread Raw
In response to Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]  (Boszormenyi Zoltan <zb@cybertec.at>)
Responses Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
List pgsql-hackers
On Friday, January 04, 2013 10:57 PM Boszormenyi Zoltan wrote:
> Hi,

> I am reviewing your patch.

Thank you very much.

> Since you are using a constant string, it would be a little faster
> to use "sizeof(string)-1" as it can be computed at compile-time
> and not run the strlen() all the time this code is reached.

I have reffered the code just above for PG_TEMP_FILE_PREFIX in same function sendDir().
I have that not only that place, but there other places where strlen is used for PG_TEMP_FILE_PREFIX.
I think in this path, such optimization might not help much.
However if you think we should take care of this, then I can find other places where similar change can be done
to make it consistent?

> In create_conf_lock_file():


> Can't we add a new LWLock and use it as a critical section instead
> of waiting for 10 seconds? It would be quite surprising to wait
> 10 seconds  when accidentally executing two SET PERSISTENT
> statements in parallel.

Yes, you are right adding a new LWLock will avoid the use of sleep.
However I am just not sure if for only this purpose we should add a new LWLock?

Similar logic is used in CreateLockFile() for postmaster file but it doesn't use sleep.
How about reducing the time of sleep or removing sleep, in that user might get
error and he need to retry to get his command successful?

With Regards,
Amit Kapila.


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [COMMITTERS] pgsql: Invent a "one-shot" variant of CachedPlans for better performanc
Next
From: Boszormenyi Zoltan
Date:
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]