Re: Spurious standby query cancellations

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Spurious standby query cancellations
Дата
Msg-id CAMkU=1ybzavK15R-XCPDmub4UNcKjefz9t9YELwvGdD_mQgJpg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Spurious standby query cancellations  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Spurious standby query cancellations  (Michael Paquier <michael.paquier@gmail.com>)
Re: Spurious standby query cancellations  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-hackers
On Wed, Sep 16, 2015 at 2:44 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
On 14 September 2015 at 12:00, Jeff Janes <jeff.janes@gmail.com> wrote:
 
It's now possible to fix this by putting a lock wait on the actual lock request, which wasn't available when I first wrote that, hence the crappy wait loop. Using the timeout handler would now be the preferred way to solve this. We can backpatch that to 9.3 if needed, where they were introduced.

There's an example of how to use lock waits further down on ResolveRecoveryConflictWithBufferPin(). Could you have a look at doing it that way?

It looks like this will take some major surgery.  The heavy weight lock manager doesn't play well with others when it comes to timeouts other than its own.  LockBufferForCleanup is a simple retry loop, but the lock manager is much more complicated than that.

Not sure I understand this objection. I can't see a reason that my proposal wouldn't work.

On further thought, neither do I.  The attached patch inverts ResolveRecoveryConflictWithLock to be called back from the lmgr code so that is it like ResolveRecoveryConflictWithBufferPin code.  It does not try to cancel the conflicting lock holders from the signal handler, rather it just loops an extra time and cancels the transactions on the next call.

It looks like the deadlock detection is adequately handled within normal lmgr code within the back-ends of the other parties to the deadlock, so I didn't do a timeout for deadlock detection purposes.

Cheers,

Jeff
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Kellerer
Дата:
Сообщение: Re: No Issue Tracker - Say it Ain't So!
Следующее
От: Jeevan Chalke
Дата:
Сообщение: Re: TEXT vs VARCHAR join qual push down diffrence, bug or expected?