Re: Incorrect UPDATE trigger invocation in the UPDATE clause of an UPSERT statement.
От | Stanislav Grozev |
---|---|
Тема | Re: Incorrect UPDATE trigger invocation in the UPDATE clause of an UPSERT statement. |
Дата | |
Msg-id | CAA78GVpOm35QiMUAc0V7_V8KG18CNCueXwi_s8wQ=dmhNo1dTw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Incorrect UPDATE trigger invocation in the UPDATE clause of an UPSERT statement. (Peter Geoghegan <pg@heroku.com>) |
Список | pgsql-bugs |
Peter, thank you very much. We have adopted your patch in our test environment and I can confirm it works as expected. Cheers. On Fri, Dec 4, 2015 at 3:34 AM Peter Geoghegan <pg@heroku.com> wrote: > On Thu, Dec 3, 2015 at 1:10 PM, Peter Geoghegan <pg@heroku.com> wrote: > > I'll need to think about a fix. > > The problem was with the pointer we pass to ExecUpdate(). > > It's a pointer to the target tuple in shared memory. So the field > "tuple.t_data->t_ctid" within ExecOnConflictUpdate() starts out > pointing to an ItemPointerData with the correct ctid (when it > initially points to the current/target tuple, since as an > about-to-be-upserted tuple the "t_ctid" field must be a pointer to the > self-same tuple). Then, it is modified in-place in shared memory by > heap_update(), within its critical section. > > The fix is to take a deep copy (pass a pointer to an ItemPointerData > on the stack), as in the attached. I've also fixed up the tests, which > should have caught this, but didn't. Mea culpa. > > Many thanks to Stanislav for the report! While I didn't adopt his > suggestion, he certainly almost had it right. > > -- > Peter Geoghegan > -- -S
В списке pgsql-bugs по дате отправления: