On Sat, Jan 05, 2013 at 08:05:11AM +0100, Boszormenyi Zoltan wrote: > 2013-01-05 05:58 keltez?ssel, Amit kapila ?rta: >> On Friday, January 04, 2013 10:57 PM Boszormenyi Zoltan wrote: >>> 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? > > I think removing the loop entirely is better.
Agreed. A new LWLock with a narrow purpose is fine. CreateLockFile() happens early, before shared memory is available. Its approach is not a relevant precedent for code that runs later. > 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 All other things being equal, the first choice sounds better. (I don't think the decision is essential to the utility of this feature.) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
