--=-grKYYxS+I6YXYVnx2fPQ
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
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 re****ts 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@[EMAIL PROTECTED]
> 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
--=-grKYYxS+I6YXYVnx2fPQ
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.12.3">
</HEAD>
<BODY>
Sean,<BR>
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<FONT COLOR="#000000"> -
unless its a caching issue. I have had no re****ts 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!</FONT><BR>
<BR>
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.<BR>
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.<FONT COLOR="#000000"> I'm obviously
missing something obvious here, but I just can't see it.</FONT><BR>
<BR>
<FONT COLOR="#000000">PS the version of PostgreSQL is a bit old - its an
8.0.3</FONT><BR>
<BR>
On Tue, 2008-04-15 at 05:47 -0400, Sean Davis wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">On Tue, Apr 15, 2008 at 4:21 AM, Steve T <<A
HREF="mailto:steve@[EMAIL PROTECTED]
">steve@[EMAIL PROTECTED]
>> wrote:</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> Is it possible for a whole set of sequences to
suddenly 'jump'?</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> I have a set of claims tables that cover the
claim itself, the customer,</FONT>
<FONT COLOR="#000000">> contact points etc. Yesterday there was a power
failure and the server</FONT>
<FONT COLOR="#000000">> suffered an immediate power outage. When the
server came back, everything</FONT>
<FONT COLOR="#000000">> seemed fine, apart from the fact that the claim
related sequences had all</FONT>
<FONT COLOR="#000000">> jumped and left a gap of 33 (last was 52 before
power failure, next one</FONT>
<FONT COLOR="#000000">> allocated after power failure 85). This seems
consistent across all the</FONT>
<FONT COLOR="#000000">> tables related to the claim (it may be across
the tables in the database -</FONT>
<FONT COLOR="#000000">> I haven't checked all of them as yet).</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> Does this sound feasible and if so, what is
the cause?</FONT>
<FONT COLOR="#000000">One explanation: if there were uncommitted
transactions at the time of</FONT>
<FONT COLOR="#000000">the power failure, the sequence would have been
advanced, but the</FONT>
<FONT COLOR="#000000">corresponding rows would not have entered the
database.</FONT>
<FONT COLOR="#000000">Sean</FONT>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-grKYYxS+I6YXYVnx2fPQ--
|
