From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Subject: | Re: Assertion failure on hot standby |
Date: | 2010-11-27 10:05:39 |
Message-ID: | 1290852339.2981.1022.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2010-11-26 at 18:35 -0500, Tom Lane wrote:
> Speaking of which, is there any code in there to ensure that a
> deadlock
> in the standby is resolved by killing HS queries and not the replay
> process? Because deadlocks are certainly going to be possible no
> matter
> what.
Locks cause query conflicts, so any attempt to take a lock that is
blocked will be resolved before a deadlock takes place. So that
situation does not arise in the startup process.
--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and Services
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-11-27 11:00:07 | Re: Assertion failure on hot standby |
Previous Message | Quan Zongliang | 2010-11-27 09:03:12 | Patch BUG #5103: "pg_ctl -w (re)start" fails with custom unix_socket_directory |