Sean,
I thought that at first, but there are only a half dozen or so people on the system. So I would have taken a gap of 3-4 of 'transactions in progress', but the 33 gap is far too big for that
- unless its a caching issue. I have had no reports of missing data though (and the numbers on the physical data would seem to echo that it's all ok - ie the 52 rec is pre crash by about 2-3 mins and the 85 rec is just after the restart). Typically these tables increase by 30-50 rows a day - so a gap of 33 is a whole days worth! I've checked the code this morning and can only find 2 sets of inserts into the tables in question - one in the manual entry and one in a batch process. So I checked the batches around that time and nothing was transferred.
Totally stumped. I could also have taken 'corruption' on one of the sequences, but I must have 5 sequences (all related tables in this area) that all exhibit the same 33 gap.
I'm obviously missing something obvious here, but I just can't see it.PS the version of PostgreSQL is a bit old - its an 8.0.3 On Tue, 2008-04-15 at 05:47 -0400, Sean Davis wrote:
On Tue, Apr 15, 2008 at 4:21 AM, Steve T <steve@retsol.co.uk> wrote:
>
> Is it possible for a whole set of sequences to suddenly 'jump'?
>
> I have a set of claims tables that cover the claim itself, the customer,
> contact points etc. Yesterday there was a power failure and the server
> suffered an immediate power outage. When the server came back, everything
> seemed fine, apart from the fact that the claim related sequences had all
> jumped and left a gap of 33 (last was 52 before power failure, next one
> allocated after power failure 85). This seems consistent across all the
> tables related to the claim (it may be across the tables in the database -
> I haven't checked all of them as yet).
>
> Does this sound feasible and if so, what is the cause?
One explanation: if there were uncommitted transactions at the time of
the power failure, the sequence would have been advanced, but the
corresponding rows would not have entered the database.
Sean
