From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Any idea for serializing INSERTING SERIAL column? |
Date: | 2011-06-01 00:08:47 |
Message-ID: | 20110601.090847.972525811823855267.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Pgpool currently acquires row locks on sequences to sync sequences
among PostgreSQL servers in "replication mode".
Suppose you have a table t1(i int, j SERIAL) and two sessions are
trying to INSERT the table(initial value of t1_j_seq is 100 on
PostgreSQL server D1 and D2):
S1: INSERT INTO t1 VALUES(1); on D1 -- sequence "t1_j_seq" becomes 101 and
new row on D1 will be (1, 101)
S2: INSERT INTO t1 VALUES(2); on D1 -- sequence "t1_j_seq" becomes 102 and
new row on D1 will be (2, 102)
S2: INSERT INTO t1 VALUES(2); on D2-- sequence "t1_j_seq" becomes 101 and
new row on D1 will be (2, 101)
S1: INSERT INTO t1 VALUES(1); on D2 -- sequence "t1_j_seq" becomes 102 and
new row on D1 will be (1, 102)
So you have these rows which are incorrectly replicated:
D1: (1, 101) (2, 102)
D2: (2, 101) (1, 102)
This can be fixed by serializing INSERTs into t1. One idea is
acquiring lock on t1. Unfortunately this conflicts with autovacuum. So
pgpool-II does following:
SELECT 1 FROM LOCK t1_j_seq FOR UPDATE;
(LOCK t1_j_seq will not work)
INSERT INTO t1...
Problem is, "SELECT 1 FROM LOCK t1_j_seq FOR UPDATE" will fail after
XID wraparound happens.
In summary,
1) "LOCK table foo" cannot be used because of conflict with autovacuum
2) "LOCK sequence" just doesn't work
3) "SELECT 1 FROM LOCK sequece" fails after XID wraparound
If you have other idea to serialize concurrent INSERT to a table, I
would like to hear from you.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | Thom Brown | 2011-06-01 00:18:18 | Re: creating CHECK constraints as NOT VALID |
Previous Message | Greg Stark | 2011-05-31 23:57:24 | Re: pgsql: Protect GIST logic that assumes penalty values can't be negative |