On Mon, 2010-01-25 at 09:52 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > On Sat, 2010-01-23 at 21:40 +0000, Greg Stark wrote: > >> On Sat, Jan 23, 2010 at 8:28 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > >>> What is your proposed way of handling buffer pin deadlocks? That will be > >>> acceptable and working to some extent in the next week? > >>> > >>> Wait forever isn't always a good idea, anymore, if it ever was. > >> I've never said it was always a good idea. But killing correctly > >> running queries isn't always a good idea either. I'm interested in > >> using HS for running read-only replicas for load balancing. It would > >> pretty sad if queries dispatched to a read-only replica received a > >> spurious unpredictable errors for reasons the application programmer > >> cannot control. > > > > I understand your concern and seek to provide the best way forwards in > > the time available. Hopefully you have a better way, but we can do > > little about the time. Your input is welcome, and your code also. > > I just woke up to this thread too. I have to agree with Greg, we must > think harder.
Must is a word I would disagree with. There are other bigger usability issues to resolve at present and I'm not personally going to be distracted away from addressing them. I have no problem in other contributions. > Can you summarize the problem again? I don't immediately see how the > deadlock could happen. > > 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. Better ideas welcome, but solutions may not be forthcoming in the time available. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
