pgsql: In HS, Startup process sets SIGALRM whenwaiting for buffer pin.
in [PgSql]
|
Prev: [HACKERS] Resetting a single statistics counter
Next: pg_listener entries deleted under heavy NOTIFY loadonly on Windows
From: Heikki Linnakangas on 25 Jan 2010 03:56 Simon Riggs wrote: > On Mon, 2010-01-25 at 09:52 +0200, Heikki Linnakangas wrote: >> Would this simple scheme work: >> >> When the startup process has waited for a short while (ie >> deadlock_timeout), it sends the signal "please check if you're holding a >> pin on buffer X" to all backends. When a backend receives that signal, >> it checks if it is holding a pin on the given buffer *and* waiting on a >> lock. If it is, abort the transaction. Assuming that a backend can only >> block waiting on a lock held by the startup process, deadlock detection >> is as simple as that. > > No, it won't work. A deadlock could occur after the startup process has > already been waiting for longer than the deadlock timeout. Retry every deadlock_timeout seconds? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 25 Jan 2010 03:59 Heikki Linnakangas wrote: > Simon Riggs wrote: >> On Mon, 2010-01-25 at 09:52 +0200, Heikki Linnakangas wrote: >>> Would this simple scheme work: >>> >>> When the startup process has waited for a short while (ie >>> deadlock_timeout), it sends the signal "please check if you're holding a >>> pin on buffer X" to all backends. When a backend receives that signal, >>> it checks if it is holding a pin on the given buffer *and* waiting on a >>> lock. If it is, abort the transaction. Assuming that a backend can only >>> block waiting on a lock held by the startup process, deadlock detection >>> is as simple as that. >> No, it won't work. A deadlock could occur after the startup process has >> already been waiting for longer than the deadlock timeout. > > Retry every deadlock_timeout seconds? Or better yet, also check if the current backend is holding the waited-for pin in CheckDeadLock(). -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 25 Jan 2010 04:19 On Mon, 2010-01-25 at 10:59 +0200, Heikki Linnakangas wrote: > Heikki Linnakangas wrote: > > Simon Riggs wrote: > >> On Mon, 2010-01-25 at 09:52 +0200, Heikki Linnakangas wrote: > >>> Would this simple scheme work: > >>> > >>> When the startup process has waited for a short while (ie > >>> deadlock_timeout), it sends the signal "please check if you're holding a > >>> pin on buffer X" to all backends. When a backend receives that signal, > >>> it checks if it is holding a pin on the given buffer *and* waiting on a > >>> lock. If it is, abort the transaction. Assuming that a backend can only > >>> block waiting on a lock held by the startup process, deadlock detection > >>> is as simple as that. > >> No, it won't work. A deadlock could occur after the startup process has > >> already been waiting for longer than the deadlock timeout. > > > > Retry every deadlock_timeout seconds? > > Or better yet, also check if the current backend is holding the > waited-for pin in CheckDeadLock(). The deadlock can be caused by either party. As long as the check occurs in both places, it can be done. The logic for the startup process must be enhanced to allow for both deadlocks and normal pin buffer checks happening at different times without confusion. The SIGUSR1 message received by backend would need to differ as to whether it was a deadlock check timeout or a normal buffer pin timeout. It can be done, though will require very careful testing. It's clearly a lower priority than other code based upon feedback from the Hot Standby user group. My assessment is too much code, too rare a case and too little time, so it is a relative, not absolute judgement. I would not personally argue this is something worth delaying for, though you and Greg may wish to do that. If you insisted it was me that did this, I would not be in a position to start it for about 10 days. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 25 Jan 2010 09:22 Simon Riggs wrote: > It's clearly a > lower priority than other code based upon feedback from the Hot Standby > user group. What's the "the Hot Standby user group"? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 25 Jan 2010 09:25
On Mon, 2010-01-25 at 16:22 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > It's clearly a > > lower priority than other code based upon feedback from the Hot Standby > > user group. > > What's the "the Hot Standby user group"? A group of people who have an interest in using Hot Standby, as advertised on postgresql.org and Weekly News. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |