Re: BUG #16676: SELECT ... FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED locks rows it doesn't return
В списке pgsql-bugs по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: BUG #16676: SELECT ... FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED locks rows it doesn't return |
| Дата | |
| Msg-id | 604509.1603203416@sss.pgh.pa.us обсуждение |
| Ответ на | Re: BUG #16676: SELECT ... FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED locks rows it doesn't return (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
| Ответы |
Re: BUG #16676: SELECT ... FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED locks rows it doesn't return
|
| Список | pgsql-bugs |
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2020-Oct-19, David Christensen wrote:
>> Maybe splitting LockRows into two nodes, one for locking and one for
>> emitting unlocked nodes then interleaving Limit in between? (Or only
>> doing something along these lines for this admittedly narrow use case.)
> I was having a similar idea, but the main reason I don't think it's a
> good fix is that we can't backpatch such a change to pg13.
Um, why not? I don't have a position yet on whether this is a good way
to fix it; but if we did do it, AFAICS the only thing we'd have to be
careful of in v13 is not renumbering existing NodeTag values.
If your concern is just that EXPLAIN plans will look different, the same
could be said of David's other proposal.
regards, tom lane
В списке pgsql-bugs по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера