Alvaro,
Is there a PostgreSQL bug number that I could refer to for this problem?
Thank you.
On Tue, Jul 9, 2013 at 4:53 PM, Alvaro Herrera wrote:
> Jamey Poirier escribió:
> >
> > Thank you Alvaro. Yes, this explains it.
> > It doesn't help to fix it but at least I know now that it's a known
pg noob escribió:
> Alvaro,
>
> Is there a PostgreSQL bug number that I could refer to for this problem?
#8290 ?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.
Jamey Poirier escribió:
>
> Thank you Alvaro. Yes, this explains it.
> It doesn't help to fix it but at least I know now that it's a known "feature".
> I'll have to see about coming up with a work-around as we likely won't get to
> 9.3 anytime soon.
Perhaps you can use FOR SHARE instead of FOR
gsql-bugs-ow...@postgresql.org [mailto:pgsql-bugs-ow...@postgresql.org]
On Behalf Of Alvaro Herrera
Sent: Tuesday, July 09, 2013 2:59 PM
To: pgn...@gmail.com
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #8290: broken/unexpected locking behavior
pgn...@gmail.com escribió:
> I sent t
pgn...@gmail.com escribió:
> I sent the following information to pgsql-general to ask if it is expected
> locking behavior. The only responses that I got said that the behavior is
> reproducible on 9.1 and 9.3 beta 2.
> Nobody said that this is expected locking behavior and I believe it to be a
>
Doing that just moves the problem from the time of the UPDATE to the time
of the COMMIT.
It is still possible to get a deadlock and I'm not sure how making it
deferrable helps in this case.
You can still end up with a deadlock like this:
CON1: BEGIN;
CON1: SELECT * FROM A WHERE id = 1 FOR UPDATE;
On Tue, Jul 9, 2013 at 9:02 AM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 8290
> Logged by: pgnoob
> Email address: pgn...@gmail.com
> PostgreSQL version: 8.4.13
> Operating system: CentOS Linux
> Description:
>
> I experienced a db deadloc
