pginfo <pginfo(at)t1(dot)unisoftbg(dot)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
In response to
pgsql-sql by date
|Next:||From: pginfo||Date: 2005-02-22 09:33:51|
|Subject: Re: pg primary key bug?|
|Previous:||From: Achilleus Mantzios||Date: 2005-02-22 08:24:11|
|Subject: Re: Timestamp with timezone question.|