Lists: | pgsql-novice |
---|
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Betsy Barker <betsy(dot)barker(at)supportservicesinc(dot)com> |
Cc: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: problem with sequence PostgreSQL 7.3.4 |
Date: | 2004-11-12 22:25:58 |
Message-ID: | 372.1100298358@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-novice |
Betsy Barker <betsy(dot)barker(at)supportservicesinc(dot)com> writes:
> I am using PostgreSQL 7.3.4 and have noticed something odd while using
> a sequence. After using 3000 values, I seem to be getting a duplicate.
I don't think I'm going to believe that without seeing a complete test
case. It seems much more likely that there's a bug in your program.
The cache_value setting of 1000 seems awfully high; that would very
likely cause odd behavior in terms of values being skipped or not being
handed out in sequence. But I've not heard of any problems that could
cause generation of duplicates (at least not since 7.2.1, and even that
bug only surfaced during a database crash).
regards, tom lane
From: | Betsy Barker <betsy(dot)barker(at)supportservicesinc(dot)com> |
---|---|
To: | pgsql-novice(at)postgresql(dot)org |
Cc: | betsy(dot)barker(at)supportservicesinc(dot)com |
Subject: | problem with sequence PostgreSQL 7.3.4 |
Date: | 2004-11-12 22:31:15 |
Message-ID: | 20041112153115.7ece7e8c.betsy.barker@supportservicesinc.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-novice |
I am using PostgreSQL 7.3.4 and have noticed something odd while using a sequence. After using 3000 values, I seem to be getting a duplicate. I'm running a stored procedure that uses this sequence and it fails with a :
WARNING: Error occurred while executing PL/pgSQL function calc_sum_facilities
WARNING: line 678 at SQL statement
ERROR: Cannot insert a duplicate key into unique index calculationdifferential_pkey
I ran the program 4 times and checked the value of the sequence after each failure. There is a 3000 difference. Look at the last_value in each case.
ssi=> select * from calc_id_seq;
sequence_name | last_value | increment_by | max_value | min_value | cache_value | log_cnt | is_cycled | is_called
---------------+------------+--------------+---------------------+-----------+-------------+---------+-----------+-----------
calc_id_seq | 4527999 | 1 | 9223372036854775807 | 1 | 1000 | 32 | f | t
sequence_name | last_value | increment_by | max_value | min_valu
---------------+------------+--------------+---------------------+---------
calc_id_seq | 4530999 | 1 | 9223372036854775807 |
ssi=> select * from calc_id_seq;
sequence_name | last_value | increment_by | max_value | min_valu
---------------+------------+--------------+---------------------+---------
calc_id_seq | 4533999 | 1 | 9223372036854775807 |
(1 row)
ssi=> select * from calc_id_seq;
sequence_name | last_value | increment_by | max_value | min_value | cache_value | log_cnt | is_cycled | is_called
---------------+------------+--------------+---------------------+-----------+-------------+---------+-----------+-----------
calc_id_seq | 4536999 | 1 | 9223372036854775807 | 1 | 1000 | 32 | f | t
(1 row)
Does anyone know what is going on , or how I can get the sequence to not act this way?
Thank you,
--
Betsy Barker
IT Manager
Support Services, Inc
(720)489-1630 X 38
From: | Betsy Barker <betsy(dot)barker(at)supportservicesinc(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: problem with sequence PostgreSQL 7.3.4 |
Date: | 2004-11-12 23:37:26 |
Message-ID: | 20041112163726.77d39b2f.betsy.barker@supportservicesinc.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-novice |
Hi Tom,
I actually select the nextval right before the insert, as you can see below, so I'm not sure how it could be a programming issue.
Also, the program fails at different places as it progresses, but it seems that it is always on the 3000th value of the sequence.
IF diffdolhospitals >= 5 THEN
checkdollar := true;
RAISE NOTICE ''Will insert differential dollar calculation '';
SELECT nextval(''calc_id_seq'') INTO diffcalcid;
INSERT INTO calculationdifferential VALUES (diffcalcid,calcid,_tempdifferentials.differentialid, diffdolhospitals,diffdolrangebegin, diffdolrangeend,diffdolmode,diffdolfiftieth,diffdolmean, diffdoltwentyfifth,diffdolfiftieth,diffdolseventyfifth,checkdollar);
END IF;
-- INSERT PERCENTAGE DIFFERENTIAL CALCULATION
IF diffpcthospitals >= 5 THEN
checkdollar := false;
RAISE NOTICE ''Will insert differential percentage calculation '';
SELECT nextval(''calc_id_seq'') INTO diffcalcid;
INSERT INTO calculationdifferential VALUES (diffcalcid,calcid,_tempdifferentials.differentialid, diffpcthospitals,diffpctrangebegin, diffpctrangeend,diffpctmode,diffpctfiftieth,diffpctmean, diffpcttwentyfifth,diffpctfiftieth,diffpctseventyfifth,checkdollar);
END IF;
However, do you think it might have something to do with the fact that I run the program over and over again, after these failures, and there is a transaction issue or something like that?
The reason I have the cache at 1000 is that I will easily use 1000 values in one run. Do you recommend I decrease that value? Because I can.
Thanks,
Betsy
On Fri, 12 Nov 2004 17:25:58 -0500
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Betsy Barker <betsy(dot)barker(at)supportservicesinc(dot)com> writes:
> > I am using PostgreSQL 7.3.4 and have noticed something odd while using
> > a sequence. After using 3000 values, I seem to be getting a duplicate.
>
> I don't think I'm going to believe that without seeing a complete test
> case. It seems much more likely that there's a bug in your program.
>
> The cache_value setting of 1000 seems awfully high; that would very
> likely cause odd behavior in terms of values being skipped or not being
> handed out in sequence. But I've not heard of any problems that could
> cause generation of duplicates (at least not since 7.2.1, and even that
> bug only surfaced during a database crash).
>
> regards, tom lane
>
--
Betsy Barker
IT Manager
Support Services, Inc
(720)489-1630 X 38
From: | Terry Lee Tucker <terry(at)esc1(dot)com> |
---|---|
To: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: problem with sequence PostgreSQL 7.3.4 |
Date: | 2004-11-16 17:13:50 |
Message-ID: | 200411161213.50914.terry@esc1.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-novice |
Not a waste of time. Just a reminder that we all make mistakes. You should
hear some of mine ;o)
On Tuesday 16 November 2004 12:24 pm, Betsy Barker saith:
> Tom & List,
> I apologize. I found the problem and it turns out that the original unique
> number generator for this table was being incremented by 3000 and those ids
> actually existed in the table. So, it wasn't the program and it wasn't the
> sequence, just my stupidity.
>
> My sincere apologies for wasting your time.....
>
> Betsy Barker
>
>
> On Fri, 12 Nov 2004 16:37:26 -0700
>
> Betsy Barker <betsy(dot)barker(at)supportservicesinc(dot)com> wrote:
> > Hi Tom,
> > I actually select the nextval right before the insert, as you can see
> > below, so I'm not sure how it could be a programming issue.
> >
> > Also, the program fails at different places as it progresses, but it
> > seems that it is always on the 3000th value of the sequence.
> >
> >
> > IF diffdolhospitals >= 5 THEN
> > checkdollar := true;
> > RAISE NOTICE ''Will insert differential dollar calculation '';
> > SELECT nextval(''calc_id_seq'') INTO diffcalcid;
> > INSERT INTO calculationdifferential VALUES
> > (diffcalcid,calcid,_tempdifferentials.differentialid,
> > diffdolhospitals,diffdolrangebegin,
> > diffdolrangeend,diffdolmode,diffdolfiftieth,diffdolmean,
> > diffdoltwentyfifth,diffdolfiftieth,diffdolseventyfifth,checkdollar); END
> > IF;
> >
> > -- INSERT PERCENTAGE DIFFERENTIAL CALCULATION
> > IF diffpcthospitals >= 5 THEN
> > checkdollar := false;
> > RAISE NOTICE ''Will insert differential percentage calculation '';
> > SELECT nextval(''calc_id_seq'') INTO diffcalcid;
> > INSERT INTO calculationdifferential VALUES
> > (diffcalcid,calcid,_tempdifferentials.differentialid,
> > diffpcthospitals,diffpctrangebegin,
> > diffpctrangeend,diffpctmode,diffpctfiftieth,diffpctmean,
> > diffpcttwentyfifth,diffpctfiftieth,diffpctseventyfifth,checkdollar); END
> > IF;
> >
> >
> >
> > However, do you think it might have something to do with the fact that I
> > run the program over and over again, after these failures, and there is a
> > transaction issue or something like that?
> >
> > The reason I have the cache at 1000 is that I will easily use 1000 values
> > in one run. Do you recommend I decrease that value? Because I can.
> >
> > Thanks,
> > Betsy
> >
> >
> > On Fri, 12 Nov 2004 17:25:58 -0500
> >
> > Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > > Betsy Barker <betsy(dot)barker(at)supportservicesinc(dot)com> writes:
> > > > I am using PostgreSQL 7.3.4 and have noticed something odd while
> > > > using a sequence. After using 3000 values, I seem to be getting a
> > > > duplicate.
> > >
> > > I don't think I'm going to believe that without seeing a complete test
> > > case. It seems much more likely that there's a bug in your program.
> > >
> > > The cache_value setting of 1000 seems awfully high; that would very
> > > likely cause odd behavior in terms of values being skipped or not being
> > > handed out in sequence. But I've not heard of any problems that could
> > > cause generation of duplicates (at least not since 7.2.1, and even that
> > > bug only surfaced during a database crash).
> > >
> > > regards, tom lane
> >
> > --
> > Betsy Barker
> > IT Manager
> > Support Services, Inc
> > (720)489-1630 X 38
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 7: don't forget to increase your free space map settings
>
> --
> Betsy Barker
> IT Manager
> Support Services, Inc
> (720)489-1630 X 38
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
--
Quote: 42
"You know how Congress is. They'll vote for anything if the thing they
vote for will turn around and vote for them. Politics ain't nothing but
reciprocity."
--Will Rogers
Work: 1-336-372-6812
Cell: 1-336-363-4719
email: terry(at)esc1(dot)com
From: | Betsy Barker <betsy(dot)barker(at)supportservicesinc(dot)com> |
---|---|
To: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: problem with sequence PostgreSQL 7.3.4 |
Date: | 2004-11-16 17:24:29 |
Message-ID: | 20041116102429.728ec26a.betsy.barker@supportservicesinc.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-novice |
Tom & List,
I apologize. I found the problem and it turns out that the original unique number generator for this table was being incremented by 3000 and those ids actually existed in the table. So, it wasn't the program and it wasn't the sequence, just my stupidity.
My sincere apologies for wasting your time.....
Betsy Barker
On Fri, 12 Nov 2004 16:37:26 -0700
Betsy Barker <betsy(dot)barker(at)supportservicesinc(dot)com> wrote:
> Hi Tom,
> I actually select the nextval right before the insert, as you can see below, so I'm not sure how it could be a programming issue.
>
> Also, the program fails at different places as it progresses, but it seems that it is always on the 3000th value of the sequence.
>
>
> IF diffdolhospitals >= 5 THEN
> checkdollar := true;
> RAISE NOTICE ''Will insert differential dollar calculation '';
> SELECT nextval(''calc_id_seq'') INTO diffcalcid;
> INSERT INTO calculationdifferential VALUES (diffcalcid,calcid,_tempdifferentials.differentialid, diffdolhospitals,diffdolrangebegin, diffdolrangeend,diffdolmode,diffdolfiftieth,diffdolmean, diffdoltwentyfifth,diffdolfiftieth,diffdolseventyfifth,checkdollar);
> END IF;
>
> -- INSERT PERCENTAGE DIFFERENTIAL CALCULATION
> IF diffpcthospitals >= 5 THEN
> checkdollar := false;
> RAISE NOTICE ''Will insert differential percentage calculation '';
> SELECT nextval(''calc_id_seq'') INTO diffcalcid;
> INSERT INTO calculationdifferential VALUES (diffcalcid,calcid,_tempdifferentials.differentialid, diffpcthospitals,diffpctrangebegin, diffpctrangeend,diffpctmode,diffpctfiftieth,diffpctmean, diffpcttwentyfifth,diffpctfiftieth,diffpctseventyfifth,checkdollar);
> END IF;
>
>
>
> However, do you think it might have something to do with the fact that I run the program over and over again, after these failures, and there is a transaction issue or something like that?
>
> The reason I have the cache at 1000 is that I will easily use 1000 values in one run. Do you recommend I decrease that value? Because I can.
>
> Thanks,
> Betsy
>
>
> On Fri, 12 Nov 2004 17:25:58 -0500
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> > Betsy Barker <betsy(dot)barker(at)supportservicesinc(dot)com> writes:
> > > I am using PostgreSQL 7.3.4 and have noticed something odd while using
> > > a sequence. After using 3000 values, I seem to be getting a duplicate.
> >
> > I don't think I'm going to believe that without seeing a complete test
> > case. It seems much more likely that there's a bug in your program.
> >
> > The cache_value setting of 1000 seems awfully high; that would very
> > likely cause odd behavior in terms of values being skipped or not being
> > handed out in sequence. But I've not heard of any problems that could
> > cause generation of duplicates (at least not since 7.2.1, and even that
> > bug only surfaced during a database crash).
> >
> > regards, tom lane
> >
>
>
> --
> Betsy Barker
> IT Manager
> Support Services, Inc
> (720)489-1630 X 38
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>
--
Betsy Barker
IT Manager
Support Services, Inc
(720)489-1630 X 38