Thread: cvs tip problems
I just grabbed cvs tip this afternoon and ran into two issues:
- First one is that the regression fails on "geometry" on what appears to be
a difference in the 13th decimal place of the output value. See the attached
regression diff.
- Second was on reloading my data, I got the following error message (4
times): ERROR: operator class "timestamp_ops" does not accept data type
timestamp with time zone
I've not seen either of these problems before, and I've gone through this
routine at least a dozen times in the past month or so. The second problem
is caused by the following statements (auto generated by pg_dumpall):
CREATE UNIQUE INDEX "lda_idx_1" on "laser_diagnostic_activity" using btree
( "laser_sn" "varchar_ops", "diag_run_date" "timestamp_ops" );
CREATE INDEX "ldi_idx_1" on "laser_diagnostic_items" using btree (
"laser_sn" "varchar_ops", "diag_run_date" "timestamp_ops", "diag_type"
"bpchar_ops", "diag_item" "int4_ops" );
CREATE INDEX "lv_processed_hdr_idx4" on "lv_processed_hdr" using btree (
"lv_dt" "timestamp_ops" );
CREATE INDEX "lv_processed_hdr_idx3" on "lv_processed_hdr" using btree (
"laser_type" "varchar_ops", "lv_dt" "timestamp_ops" );
And the related tables look like:
CREATE TABLE "laser_diagnostic_activity" ( "lda_id" integer DEFAULT
nextval('"laser_diagnostic_act_lda_id_seq"'::text) NOT NULL, "laser_sn" character varying(15) NOT NULL,
"diag_run_date"timestamp with time zone NOT NULL, "diag_ul_date" timestamp with time zone NOT NULL,
Constraint"laser_diagnostic_activity_pkey" Primary Key ("lda_id")
);
CREATE TABLE "laser_diagnostic_items" ( "ldi_id" integer DEFAULT
nextval('"laser_diagnostic_ite_ldi_id_seq"'::text) NOT NULL, "laser_sn" character varying(15) NOT NULL,
"diag_run_date"timestamp with time zone NOT NULL, "diag_type" character(1) NOT NULL, "diag_item" integer
NOTNULL, "diag_description" character varying(20) NOT NULL, "diag_value" character varying(24),
"diag_units"character varying(10), "lda_id" integer, Constraint "laser_diagnostic_items_pkey" Primary Key
("ldi_id")
);
CREATE TABLE "lv_processed_hdr" ( "hdr_id" integer NOT NULL, "laser_sn" character varying(15) NOT NULL,
"config_id" integer, "file_path" character varying(255) NOT NULL, "file_name" character varying(255) NOT
NULL, "lv_dt" timestamp with time zone NOT NULL, "orig_lv_file" character varying(255) NOT NULL,
"app_ver"character varying(50) NOT NULL, "lte_name" character varying(50) NOT NULL, "lte_login" character
varying(50)NOT NULL, "integrator" character varying(25) NOT NULL, "laser_type" character varying(50) NOT
NULL, "test_name" character varying(50) NOT NULL, "data_set_name" character varying(50) NOT NULL,
"data_set_id"character varying(50) NOT NULL
);
Any suggestions?
Thanks,
Joe
"Joe Conway" <joseph.conway@home.com> writes:
> I just grabbed cvs tip this afternoon and ran into two issues:
> - First one is that the regression fails on "geometry" on what appears to be
> a difference in the 13th decimal place of the output value. See the attached
> regression diff.
Looks like it was not you that changed, but Thomas' reference machine.
What platform are you on, anyway?
> - Second was on reloading my data, I got the following error message (4
> times):
> ERROR: operator class "timestamp_ops" does not accept data type
> timestamp with time zone
Oh, ye olde change-of-opclass-name problem. I've stuck a hack into
gram.y as we've done in the past, but I'm starting to think that we
need a better answer going forward. Maybe pg_dump could be tweaked to
not dump opclass names if they are default opclasses?
regards, tom lane
> > - First one is that the regression fails on "geometry" on what appears to be > > a difference in the 13th decimal place of the output value. See the attached > > regression diff. > > Looks like it was not you that changed, but Thomas' reference machine. > What platform are you on, anyway? > Not sure if this question was for Thomas or me, but for the record: i686 arch (AMD Athlon CPU), Red Hat 7.0 with lots of updates and a 2.4.2 kernel compiled from source. test=# select version(); version ----------------------------------------------------------------PostgreSQL 7.2devel on i686-pc-linux-gnu, compiled by GCC2.96 > > - Second was on reloading my data, I got the following error message (4 > > times): > > ERROR: operator class "timestamp_ops" does not accept data type > > timestamp with time zone > > Oh, ye olde change-of-opclass-name problem. I've stuck a hack into > gram.y as we've done in the past, but I'm starting to think that we > need a better answer going forward. Maybe pg_dump could be tweaked to > not dump opclass names if they are default opclasses? > That sounds like a good plan to me. I was able to rebuild the indexes last night by changing "timestamp_ops" to "timestamptz_ops", but it sure wasn't intuitive. Thanks, Joe
> > - First one is that the regression fails on "geometry" on what appears to be
> > a difference in the 13th decimal place of the output value. See the attached
> > regression diff.
> Looks like it was not you that changed, but Thomas' reference machine.
> What platform are you on, anyway?
fwiw, the former regression test results had column alignment problems,
seemingly from psql! Not sure why those were there.
I'm running Mandrake 7.2 which has glibc-2.1.3, and I've had regression
test failures on *my* machine for quite some time now (which went away,
of course, after the last updates).
I would propose that the reference machine be one that one of the
"committers" owns, and be one whose owner is willing to *always* go
through the effort to resolve regression test changes and differences.
- Thomas
Thomas Lockhart <lockhart@fourpalms.org> writes:
> I would propose that the reference machine be one that one of the
> "committers" owns, and be one whose owner is willing to *always* go
> through the effort to resolve regression test changes and differences.
Er ... wasn't that *you*?
regards, tom lane
> > I would propose that the reference machine be one that one of the
> > "committers" owns, and be one whose owner is willing to *always* go
> > through the effort to resolve regression test changes and differences.
> Er ... wasn't that *you*?
Yes. At the moment my toes are bright red and sore from being stepped
on, and I'm trying to get out of the way or figure out what the problems
are. I'm happy to continue to contribute things like this, but don't
like being held up then bypassed then ignored (cf current docs building
troubles). I'm frustrated.
I'm trying to keep an open mind about all this to help move in a
different direction if that is desired and/or necessary. That's all.
- Thomas
> > > I would propose that the reference machine be one that one of the > > > "committers" owns, and be one whose owner is willing to *always* go > > > through the effort to resolve regression test changes and differences. > > Er ... wasn't that *you*? > > Yes. At the moment my toes are bright red and sore from being stepped > on, and I'm trying to get out of the way or figure out what the problems > are. I'm happy to continue to contribute things like this, but don't > like being held up then bypassed then ignored (cf current docs building > troubles). I'm frustrated. I think we are all just scrambing to get beta ready while the server reconfigures itself. :-) I don't see any fundamental changes being proposed. We are trying to plug leaks and are stepping on toes, or at least it looks that way sometimes. :-) I can yank my CVS build if it causes confusion once we get the main one working. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Monday 01 October 2001 05:07 pm, Bruce Momjian wrote: > I think we are all just scrambing to get beta ready while the server > reconfigures itself. :-) I don't see any fundamental changes being > proposed. We are trying to plug leaks and are stepping on toes, or at > least it looks that way sometimes. :-) I can yank my CVS build if it > causes confusion once we get the main one working. IMHO, we should have the server configuration working before going beta. Especially little details like documentation. :-O But I tend to believe that's EXACTLY what Marc meant when he said we weren't ready to go beta. So, let's all please take a deep breath, count ten, and see what the server situation develops into. After all, we all want the beta to go smoothly -- and differences in the present and past server configs are not making a smooth beta practical right now. Once we work through the differences, and get things smooth again, Marc's hard work in upgrading the server situation is sure to reap benefits if we'll be patient as he works out the kinks. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
>> ERROR: operator class "timestamp_ops" does not accept data type
>> timestamp with time zone
> Oh, ye olde change-of-opclass-name problem. I've stuck a hack into
> gram.y as we've done in the past, but I'm starting to think that we
> need a better answer going forward. Maybe pg_dump could be tweaked to
> not dump opclass names if they are default opclasses?
Not having heard any objections, I have done this. We're still stuck
with needing the hack for 7.2, but perhaps future rearrangements of
index opclasses will be less painful.
regards, tom lane
On Mon, 1 Oct 2001, Bruce Momjian wrote: > > > > I would propose that the reference machine be one that one of the > > > > "committers" owns, and be one whose owner is willing to *always* go > > > > through the effort to resolve regression test changes and differences. > > > Er ... wasn't that *you*? > > > > Yes. At the moment my toes are bright red and sore from being stepped > > on, and I'm trying to get out of the way or figure out what the problems > > are. I'm happy to continue to contribute things like this, but don't > > like being held up then bypassed then ignored (cf current docs building > > troubles). I'm frustrated. > > I think we are all just scrambing to get beta ready while the server > reconfigures itself. :-) I don't see any fundamental changes being > proposed. We are trying to plug leaks and are stepping on toes, or at > least it looks that way sometimes. :-) I can yank my CVS build if it > causes confusion once we get the main one working. the reason what we have not gone beta as of yet, and will not for a little whlie yet, is the disruption caused by re-merging all of the functionality on the new server ... docs have never been a hold up for beta in the past, not sure why you consider them to be now, but they definitely shouldn't be something that is 'rushed to go beta' ... tangents to bandaid a problem that needs to be fixed, like the docs build, just detract from everything else that has to get done, I think ...