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 NOT NULL,
        "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
Sun, 30 Sep 2001 19:36:24 -0700
"Joe Conway" <joseph.conway@home.com>
cvs tip problems
"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

Mon, 01 Oct 2001 01:29:51 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: cvs tip problems 
> > - 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 GCC 2.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




Mon, 1 Oct 2001 08:50:50 -0700
"Joe Conway" <joseph.conway@home.com>
Re: cvs tip problems 
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

Mon, 01 Oct 2001 15:05:37 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: cvs tip problems 
> > - 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

Mon, 01 Oct 2001 19:06:17 +0000
Thomas Lockhart <lockhart@fourpalms.org>
Re: cvs tip problems
> > 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

Mon, 01 Oct 2001 21:01:10 +0000
Thomas Lockhart <lockhart@fourpalms.org>
Re: cvs tip problems
> > > 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, Pennsylvania 19026

Mon, 1 Oct 2001 17:07:52 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: cvs tip problems
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

Mon, 1 Oct 2001 17:19:24 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: cvs tip problems
>> 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

Mon, 01 Oct 2001 17:41:39 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: cvs tip problems 
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 ...



Tue, 2 Oct 2001 08:22:40 -0400 (EDT)
"Marc G. Fournier" <scrappy@hub.org>
Re: cvs tip problems