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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
