The following bug has been logged on the website:
Bug reference: 8288
Logged by: Thomas Gauss
Email address: tga...@wolfsysteme.de
PostgreSQL version: Unsupported/Unknown
Operating system: Windows 7 64bit
Description:
Having data directory on drive d:\database\data-9.
The following bug has been logged on the website:
Bug reference: 8289
Logged by: Dmitriy Potapov
Email address: potapov.dmi...@gmail.com
PostgreSQL version: 9.2.4
Operating system: Scientific Linux 6.3
Description:
pg_stat_statements view contains incorrectly normali
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 deadlock. After tracking down the problem I attributed
it
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
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;
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
>
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.
Thank you!
-Original Message-
From: pgsql-bugs-ow...@postgresql.org [m
potapov.dmi...@gmail.com writes:
> The testcase runs five UPDATE commands with two PQexec calls.
> First PQexec call runs: "UPDATE t1 SET a=101 WHERE id=0; UPDATE t1 SET a=102
> WHERE id=1; UPDATE t1 SET a=103 WHERE id=2"
> Second PQexec call runs: "UPDATE t2 SET b=1 where a=0; UPDATE t2 SET a=2
>
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
The following bug has been logged on the website:
Bug reference: 8291
Logged by: Lloyd Albin
Email address: lal...@fhcrc.org
PostgreSQL version: Unsupported/Unknown
Operating system: Windows 7 (64-bit)
Description:
Tested on
Windows 7 (64-bit) Postgres 9.3.0 Beta 2 -
It's looking like I can use a plpgsql function to insert data into a table
that violates a domain constraint. Is this a known problem?
Session 1:
create domain my_domain text check (length(value) > 2);
create table my_table (name my_domain);
create function f(text) returns void as $$
declare my_
11 matches
Mail list logo
