[pgpool-hackers: 48] Re: Implementing SERIAL rewriting

Tatsuo Ishii ishii at postgresql.org
Fri Mar 23 16:53:23 JST 2012


>> >> Suppose we have two different session A and B to pgpool.  It is
>> >> possible that following order of SQL execution could happen:
>> >>
>> >> A: SELECT nextval('t1_i_seq');          -- suppose this returns 100
>> >> B: SELECT nextval('t1_i_seq');          -- suppose this returns 101
>> >> A: INSERT INTO t1 VALUES(100, 1);       -- on the master and slaves
>> >> B: INSERT INTO t1 VALUES(101, 1);       -- on the master and slaves
>> >> B: SELECT setval('t1_i_seq', 101);  -- on the slaves
>> >> A: SELECT setval('t1_i_seq', 100);      -- on the slaves
>> >>
>> >> In this scenario, the sequence' value results in 101 on the master, on
>> >> the other hand 100 on the slaves. Any idea how to prevent this?
>> > 
>> > 
>> > My idea is, at slave, before set the value, check if current value is
>> > bigger than the given one.
>> 
>> How do you get the current sequence value without
>> incrementing(i.e. nextval()) the sequence value?
> 
> SELECT last_value FROM the_sequence;
> 
> Not saying this is a good idea, though :)

Thanks for good point. Now I realize that we need lock anyway.

A: SELECT nextval('t1_i_seq');          -- suppose this returns 100
B: SELECT nextval('t1_i_seq');          -- suppose this returns 101
A: INSERT INTO t1 VALUES(100, 1);       -- on the master and slaves
B: INSERT INTO t1 VALUES(101, 1);       -- on the master and slaves
B: SELECT last_value FROM t1_i_seq;		-- suppose this returns 99
A: SELECT last_value FROM t1_i_seq;		-- suppose this returns 99 as well
B: SELECT setval('t1_i_seq', 101);		-- 101 > 99. So execute this
A: SELECT setval('t1_i_seq', 100);      -- 100 > 99. So execute this

You got sequence value 101 on the master whereas 100 on the slave. No
good.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp


More information about the pgpool-hackers mailing list