Re: [GENERAL] Serialization errors despite KEY SHARE/NO KEY UPDATE

On 10/12/2015 03:59 PM, Jim Nasby wrote: On 10/6/15 12:18 PM, Olivier Dony wrote: We would happily skip the micro-transactions (as a perf workaround) if there was a way to detect this situation, but we couldn't find a way to do that in 9.3. <9.3 we used SELECT FOR UPDATE NOWAIT to guard similar

Re: [GENERAL] Serialization errors despite KEY SHARE/NO KEY UPDATE

On 10/6/15 12:18 PM, Olivier Dony wrote: We would happily skip the micro-transactions (as a perf workaround) if there was a way to detect this situation, but we couldn't find a way to do that in 9.3. <9.3 we used SELECT FOR UPDATE NOWAIT to guard similar cases. If there is any way I could help

Re: [GENERAL] Serialization errors despite KEY SHARE/NO KEY UPDATE

On 10/05/2015 11:17 PM, Kevin Grittner wrote: Jim Nasby wrote: On 10/2/15 11:44 AM, Olivier Dony wrote: On 10/02/2015 12:28 AM, Jim Nasby wrote: On 9/29/15 9:47 AM, Olivier Dony wrote: -- Setup tables CREATE TABLE users ( id serial PRIMARY KEY, name varchar,

Re: [GENERAL] Serialization errors despite KEY SHARE/NO KEY UPDATE

[Sorry for the delay in responding -- was on vacation.] Jim Nasby wrote: > On 10/2/15 11:44 AM, Olivier Dony wrote: >> On 10/02/2015 12:28 AM, Jim Nasby wrote: >>> On 9/29/15 9:47 AM, Olivier Dony wrote: -- Setup tables CREATE TABLE users ( id serial PRIMARY KEY,

Re: [GENERAL] Serialization errors despite KEY SHARE/NO KEY UPDATE

On 10/2/15 11:44 AM, Olivier Dony wrote: On 10/02/2015 12:28 AM, Jim Nasby wrote: On 9/29/15 9:47 AM, Olivier Dony wrote: My understanding of the KEY SHARE/NO KEY UPDATE locks introduced in 9.3 was that they would avoid side-effects/blocking between transactions that are only linked via FK cons

Re: [GENERAL] Serialization errors despite KEY SHARE/NO KEY UPDATE

On 10/02/2015 12:28 AM, Jim Nasby wrote: On 9/29/15 9:47 AM, Olivier Dony wrote: My understanding of the KEY SHARE/NO KEY UPDATE locks introduced in 9.3 was that they would avoid side-effects/blocking between transactions that are only linked via FK constraints, as long as the target PK was not

Re: [GENERAL] Serialization errors despite KEY SHARE/NO KEY UPDATE

On 9/29/15 9:47 AM, Olivier Dony wrote: My understanding of the KEY SHARE/NO KEY UPDATE locks introduced in 9.3 was that they would avoid side-effects/blocking between transactions that are only linked via FK constraints, as long as the target PK was not touched. Isn't it the case here? Not qui

[GENERAL] Serialization errors despite KEY SHARE/NO KEY UPDATE

Using 9.3.9 and 9.4.4 I'm experiencing serialization errors that I have trouble explaining based on the documentation. The concurrent transactions are framework-driven and all of them are running in REPEATABLE READ isolation level. The error can be reproduced as shown below. T1 fails when acquir

Re: [GENERAL] serialization failure why?

On 29 June 2015 at 21:13, Kevin Grittner wrote: > Simon Riggs wrote: > > On 17 June 2015 at 13:52, Kevin Grittner wrote: > >> Filipe Pina wrote: > > >>> if drop the foreign key constraint on stuff_ext table there are > >>> no failures at all… > >> > >> It is my recollection that we were exclud

Re: [GENERAL] serialization failure why?

Simon Riggs wrote: > On 17 June 2015 at 13:52, Kevin Grittner wrote: >> Filipe Pina wrote: >>> if drop the foreign key constraint on stuff_ext table there are >>> no failures at all… >> >> It is my recollection that we were excluding the queries used to >> enforce referential integrity constrai

Re: [GENERAL] serialization failure why?

On 17 June 2015 at 13:52, Kevin Grittner wrote: > Filipe Pina wrote: > > > if drop the foreign key constraint on stuff_ext table there are > > no failures at all… > > It is my recollection that we were excluding the queries used to > enforce referential integrity constraints from the conflict >

Re: [GENERAL] serialization failure why?

Kevin, assuming you will have some time to confirm that it has been fixed in some version some time next week, I’ve compiled the test steps in http://pastebin.com/4Uqc2kPv Thanks once again > On 17/06/2015, at 14:40, Filipe Pina wrote: > > Hi Kevin, > > I have

Re: [GENERAL] serialization failure why?

Indeed Bill, if drop the foreign key constraint on stuff_ext table I get 0 failures... But, since I can't remove the foreign key, how can I tell postgres that he can "trust" it then? Because it's obvious (for the code reader at least), that the other transaction will not be responsible for cre

Re: [GENERAL] serialization failure why?

Hi Kevin, I have installed: PostgreSQL 9.3.7 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2, 64-bit But as you mentioned it should have been fixed in later versions, I've upgraded to 9.4: PostgreSQL 9.4.4 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu 4.8.2

Re: [GENERAL] serialization failure why?

Filipe Pina wrote: > if drop the foreign key constraint on stuff_ext table there are > no failures at all… It is my recollection that we were excluding the queries used to enforce referential integrity constraints from the conflict tracking, so I am surprised you are seeing this. What is the ex

Re: [GENERAL] serialization failure why?

Indeed Bill, if drop the foreign key constraint on stuff_ext table there are no failures at all... But, since I can't remove the foreign key, how can I tell postgres that he can "trust" it then? Because it's obvious (for the code reader at least), that the other transaction will not be respons

Re: [GENERAL] serialization failure why?

On Tue, 16 Jun 2015 13:33:12 +0001 Filipe Pina wrote: > I have these 2 tables: > > CREATE TABLE "stuff" ("number" integer NOT NULL PRIMARY KEY, "title" > varchar(40) NOT NULL); > CREATE TABLE "stuff_ext" ("stuff_ptr_id" integer NOT NULL PRIMARY KEY, > "extra" integer NOT NULL); > ALTER TABLE "

[GENERAL] serialization failure why?

I have these 2 tables: CREATE TABLE "stuff" ("number" integer NOT NULL PRIMARY KEY, "title" varchar(40) NOT NULL); CREATE TABLE "stuff_ext" ("stuff_ptr_id" integer NOT NULL PRIMARY KEY, "extra" integer NOT NULL); ALTER TABLE "stuff_ext" ADD CONSTRAINT "stuff_ext_stuff_ptr_id_5a4ee8edae53404b"

Re: [GENERAL] Serialization exception : Who else was involved?

Olivier MATROT wrote: > Serialization conflict detection is done in > src/backend/storage/lmgr/predicate.c, where transactions > that are doomed to fail are marked as such with the SXACT_FLAG_DOOMED flag. > > I simply added elog(NOTIFY,...) calls with the DEBUG1 level, each time the > flag is se

Re: [GENERAL] Serialization exception : Who else was involved?

al-ow...@postgresql.org [mailto:pgsql-general-ow...@postgresql.org] De la part de Olivier MATROT Envoyé : mardi 25 novembre 2014 13:00 À : pgsql-general@postgresql.org Objet : [GENERAL] Serialization exception : Who else was involved? I'm using PostgreSQL 9.2.8 on Windows x64. When a transaction as SE

[GENERAL] Serialization exception : Who else was involved?

I'm using PostgreSQL 9.2.8 on Windows x64. When a transaction as SERIALIZABLE isolation level is failing, is there a way to know which connection(s), thus transaction(s), were involved in the overall process ? I'm working on an accounting database. I know that we should retry the transactio

Re: [GENERAL] serialization errors when inserting new records

On Mon, 24 Jan 2005, William Yu wrote: > If you absolutely need the display field to be unique and it has to be a > sequence starting from 1 -- it's simplicity itself. Use the > serialization errors to your advantage. If you try to insert a record > and you get a dupe key violation, just increment

Re: [GENERAL] serialization errors when inserting new records

Ralph van Etten wrote: Ok, but then I have the same problem. The "display" field has to be unique and it needs to use a SELECT MAX in an INSERT query and this gives the same problem. Only not with the primary key but with possible duplicate values in the "display" field. If you absolutely need the

Re: [GENERAL] serialization errors when inserting new records

On Sun, 23 Jan 2005, William Yu wrote: > Ralph van Etten wrote: > > I agree that a serial would be better. > > > > But I think there are situations where a serial isn't convenient > > Like when you want an primary key which consists of the current > > year and an sequence number. Like ('05', 1), (

Re: [GENERAL] serialization errors when inserting new records

On Sun, Jan 23, 2005 at 10:23:50 +0100, Ralph van Etten <[EMAIL PROTECTED]> wrote: > But I think there are situations where a serial isn't convenient > Like when you want an primary key which consists of the current > year and an sequence number. Like ('05', 1), ('05', 2), ('05', 3) etc. > With a

Re: [GENERAL] serialization errors when inserting new records

Ralph van Etten wrote: I agree that a serial would be better. But I think there are situations where a serial isn't convenient Like when you want an primary key which consists of the current year and an sequence number. Like ('05', 1), ('05', 2), ('05', 3) etc. With a sequence you must write extra

Re: [GENERAL] serialization errors when inserting new records

On Sat, 22 Jan 2005, Tino Wildenhain wrote: > > INSERT INTO test (id, name) > > SELECT COALESCE(MAX(id)+1, 1), 'name' FROM test > > > > Ofcourse this gives problems when two clients are inserting a record at > > the same time. (duplicate primary keys) But, i can't use a sequence in my > > applicat

Re: [GENERAL] serialization errors when inserting new records

Ralph van Etten wrote: Hoi, I searched the archives but couldn't find an answer to this: I have a table (simplyfied) CREATE TABLE test ( id INT PRIMARY KEY, name VARCHAR(250) ); I insert records with INSERT INTO test (id, name) SELECT COALESCE(MAX(id)+1, 1), 'name' FROM test Ofcourse this giv

Re: [GENERAL] serialization errors when inserting new records

Am Samstag, den 22.01.2005, 11:14 +0100 schrieb Ralph van Etten: > Hoi, > > I searched the archives but couldn't find an answer to this: > > I have a table (simplyfied) > > CREATE TABLE test ( > id INT PRIMARY KEY, > name VARCHAR(250) > ); > > I insert records with > > INSERT INTO test (

[GENERAL] serialization errors when inserting new records

Hoi, I searched the archives but couldn't find an answer to this: I have a table (simplyfied) CREATE TABLE test ( id INT PRIMARY KEY, name VARCHAR(250) ); I insert records with INSERT INTO test (id, name) SELECT COALESCE(MAX(id)+1, 1), 'name' FROM test Ofcourse this gives problems when

Re: [GENERAL] Serialization, Locking...implement processing Queue with a

I searched for a long time for a response on how correctly use the database lock feature to create a job distribution system. Also I hate programs that pools databases every few seconds. Than I noticed that postgresql have a notify feature that inform clients when a table change. Beautiful!! why

[GENERAL] serialization

I am trying to get data from a table in postgres database through a RemoteObject.But I am getting Exception: java.io.NotSerializableException: postgresql.jdbc2.Connection Does postgres support serialization. Can you help me out. Chequemail.com - a free web based e-mail service that also pay