Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
От | Amit kapila |
---|---|
Тема | Re: Proposal for Allow postgresql.conf values to be changed via SQL [review] |
Дата | |
Msg-id | 6C0B27F7206C9E4CA54AE035729E9C383BEA72EF@szxeml509-mbx обсуждение исходный текст |
Ответ на | Re: Proposal for Allow postgresql.conf values to be changed via SQL [review] (Boszormenyi Zoltan <zb@cybertec.at>) |
Ответы |
Re: Proposal for Allow postgresql.conf values to be
changed via SQL [review]
|
Список | pgsql-hackers |
On Saturday, January 05, 2013 12:35 PM Boszormenyi Zoltan wrote: 2013-01-05 05:58 keltezéssel, Amit kapila írta: > On Friday, January 04, 2013 10:57 PM Boszormenyi Zoltan wrote: >> Hi, >> I am reviewing your patch. > Thank you very much. > >> 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? > I think removing the loop entirely is better. > However, the behaviour should be discussed by a wider audience: > - the backends should wait for each other just like other statements > that fight for the same object (in which case locking is needed), or > - throw an error immediately on conflicting parallel work Okay, I shall update the patch with first option as suggested by Noah as well. >I also tried to trigger one of the errors by creating the lock file manually. > You need an extra space between the "... retry" and "or ...": > + ereport(ERROR, > + (errcode_for_file_access(), > + errmsg("could not create lock file > \"%s\": %m ", LockFileName), > + errhint("May be too many concurrent edit > into file happening, please wait!! and retry" > + "or .lock is file > accidently left there please clean the file from config_dir"))); Will fix. Thank you for review. With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: