On Thu, Feb 4, 2021 at 9:20 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Thu, Feb 4, 2021 at 1:31 PM Peter Smith <smithpb2...@gmail.com> wrote: > > > > PSA a patch which I think implements what we are talking about. > > > > This doesn't seem correct to me. Have you tested that the patch > resolves the problem reported originally? Because the lockmode > (RowExclusiveLock) you have used in the patch will allow multiple > callers to acquire at the same time. The other thing I don't like > about this is that first, it acquires lock in the function > replorigin_drop_by_name and then again we acquire the same lock in a > different mode in replorigin_drop. > > What I was imagining was to have a code same as replorigin_drop with > the first parameter as the name instead of id and additionally, it > will check the existence of origin by replorigin_by_name after > acquiring the lock. So you can move all the common code from > replorigin_drop (starting from restart till end leaving table_close) > to a separate function say replorigin_drop_guts and then call it from > both replorigin_drop and replorigin_drop_by_name. > > Now, I have also thought to directly change replorigin_drop but this > is an exposed API so let's keep it as it is because some extensions > might be using it. We can anyway later drop it if required. >
PSA patch updated per above suggestions. ---- Kind Regards, Peter Smith. Fujitsu Australia
v2-0001-replorigin_drop_by_name.patch
Description: Binary data
