Hot Standby and deadlock detection
От | Simon Riggs |
---|---|
Тема | Hot Standby and deadlock detection |
Дата | |
Msg-id | 1264974845.13782.8940.camel@ebony обсуждение исходный текст |
Ответы |
Re: Hot Standby and deadlock detection
|
Список | pgsql-hackers |
Greg Stark has requested that I re-add max_standby_delay = -1. I deferred that in favour of relation-specific conflict resolution, though that seems too major a change from comments received. As discussed in various other posts, in order to re-add the -1 option we need to add deadlock detection. I woke up today with a simplifying assumption and have worked out a solution, the easy parts of which I have committed earlier. Part #2 is to make Startup process do deadlock detection. I attach a WIP patch for comments since signal handling has been a much-discussed area in recent weeks. Normal deadlock detection waits for deadlock_timeout before doing the detection. That is a simple performance tuning mechanism which I think is probably unnecessary with hot standby, at least in the first instance. The way this would work is if Startup waits on a buffer pin we immediately send out a request to all backends to cancel themselves if they are holding the buffer pin required && waiting on a lock. We then sleep until max_standby_delay. When max_standby_delay = -1 we only sleep until deadlock timeout and then check (on the Startup process). That keeps the signal handler code simple and reduces the number of test cases required to confirm everything is solid. This patch and the last commit together present everything we need to reenable max_standby_delay = -1, so that change is included here also. ? -- Simon Riggs www.2ndQuadrant.com
Вложения
В списке pgsql-hackers по дате отправления: