Re: pg primary key bug?
От | Tom Lane |
---|---|
Тема | Re: pg primary key bug? |
Дата | |
Msg-id | 7012.1109061770@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg primary key bug? (pginfo <pginfo@t1.unisoftbg.com>) |
Список | pgsql-sql |
pginfo <pginfo@t1.unisoftbg.com> writes: > In this table we store the last value for the ID of part from other tables. > For each table we have one constant in this table. We are using the > table as sequence. > For Example if we nee to insert the next record in some table we make: > select constvalue from a_constants_str where constname ='...' for update; > increase the value and make > update a_constants_str set constvalue= (new value) where... > It is not so easy as I described, but in general this is the case. > Al this is connected with replications and data syncronisation and so on. "Connected"? What exactly is hiding under that last comment? One way I could take your report is that you've found a weird interaction between SELECT FOR UPDATE and VACUUM FULL that no one else has seen before. Another way is that you're using some nonstandard backend extension that has nasty bugs in it. It is interesting that you say this system has been working well for years and only recently have you seen problems. To me the obvious question is "what have you changed recently?" It might not be a bogus change in itself, but it could have triggered a bug at lower levels. It's certainly possible that you have your finger on a backend bug, but if so there's not nearly enough information here for anyone to find and fix it. You need to be thinking in terms of how to reproduce the problem so that it can be studied and fixed. "How can I avoid this problem" is exactly the wrong question to be asking, because even if avoiding it is all that concerns you, no one can answer with any confidence until we understand what the failure mechanism is. regards, tom lane
В списке pgsql-sql по дате отправления: