| От | Laurenz Albe |
|---|---|
| Тема | Re: COPY, lock release and MVCC |
| Дата | |
| Msg-id | 9f043b1dac1347a757236fd84eed8d67d8eeec6b.camel@cybertec.at обсуждение |
| Ответ на | Re: COPY, lock release and MVCC (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: COPY, lock release and MVCC
|
| Список | pgsql-hackers |
On Tue, 2020-05-12 at 11:50 -0400, Tom Lane wrote: > Laurenz Albe <laurenz.albe@cybertec.at> writes: > > On Mon, 2020-05-11 at 15:43 -0400, Robert Haas wrote: > > > On Fri, May 8, 2020 at 4:58 AM Laurenz Albe <laurenz.albe@cybertec.at> wrote: > > > > I happened to notice that COPY TO releases the ACCESS SHARE lock > > > > on the table right when the command ends rather than holding it > > > > until the end of the transaction: > > > That seems inconsistent with what an INSERT statement would do, and thus bad. > > Well, should we fix the code or the documentation? > > I'd agree with fixing the code. Early lock release is something we do on > system catalog accesses, and while it hasn't bitten us yet, I've been > kind of expecting that someday it will. We should not do it on SQL-driven > accesses to user tables. > > Having said that, I'd vote for just changing it in HEAD, not > back-patching. It's not clear that there are consequences bad enough > to merit a back-patched behavior change. Agreed. Here is a patch. Yours, Laurenz Albe
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера