Обсуждение: ERROR: XX000: function 60821C60 returned NULL

Поиск
Список
Период
Сортировка

ERROR: XX000: function 60821C60 returned NULL

От
"Obe, Regina"
Дата:
I have an SQL job on SQL Server that dumps data to a table in=0D
PostGreSQL.  This job worked fine when it was going against a PG 8.1.3=0D
server, but since my upgrade to PG 8.3, it has been working=0D
intermittently.  Mostly not working and erroring out with=0D
 =0D
ERROR: XX000: function 60821C60 returned NULL=0D
 =0D
I have other jobs doing similar feeds to other tables, and they still=0D
work fine.  So I can't quite figure out what is wrong with this one.=0D
The only difference with this table is that the copy is done hourly=0D
where as the other ones are done daily.=0D
 =0D
The table being inserted into looks like the below.  If I drop the table=0D
and recreate it, the routine starts working again.  My SQL Server DTS=0D
job uses the ODBC driver, but I tried a .NET script that uses the npgsql=0D
driver and had the same issues.  All fields are inserted into except the=0D
the_point and gid fields.  I'm going to reduce the frequency of=0D
uploading and take out the OID to see if that makes a difference.=0D
 =0D
CREATE TABLE hbasessionsremaining=0D
(=0D
  sessioncode character varying(17) NOT NULL,=0D
  remainingslots integer,=0D
  meetstarttime timestamp without time zone,=0D
  meetendtime timestamp without time zone,=0D
  number smallint NOT NULL,=0D
  date timestamp without time zone,=0D
  course character varying(5) NOT NULL,=0D
  classcode character varying(8) NOT NULL,=0D
  numberwaitlisted integer,=0D
  sessiongroup character varying(17),=0D
  "location" character varying(50),=0D
  locparcelid character(10),=0D
  descrip character varying(50),=0D
  locationcode character varying(3) NOT NULL,=0D
  the_point geometry,=0D
  address character varying(500),=0D
  gid serial NOT NULL,=0D
  CONSTRAINT pk_hbasessionsremaining PRIMARY KEY (sessioncode),=0D
  CONSTRAINT udx_hbasessionsremaining_gid UNIQUE (gid)=0D
) =0D
WITHOUT OIDS;=0D
ALTER TABLE hbasessionsremaining OWNER TO robedev;=0D
GRANT ALL ON TABLE hbasessionsremaining TO robedev;=0D
GRANT ALL ON TABLE hbasessionsremaining TO dnddtsadmins WITH GRANT=0D
OPTION;=0D
 =0D
Thanks,=0D
Regina=0D
 =0D
 =0D
 =0D
 =0D
 =0D
 =0D
=0D
=0D
=0D
-----------------------------------------=0D
The substance of this message, including any attachments, may be=0D
confidential, legally=0D
privileged and/or exempt from disclosure pursuant to Massachusetts=0D
law. It is intended=0D
solely for the addressee. If you received this in error, please=0D
contact the sender and=0D
delete the material from any computer.=0D

Re: ERROR: XX000: function 60821C60 returned NULL

От
"Obe, Regina"
Дата:
Correction upgrade to PG 8.2

________________________________

From: pgsql-bugs-owner@postgresql.org
[mailto:pgsql-bugs-owner@postgresql.org] On Behalf Of Obe, Regina
Sent: Tuesday, January 02, 2007 12:36 PM
To: pgsql-bugs@postgresql.org
Subject: [BUGS] ERROR: XX000: function 60821C60 returned NULL


I have an SQL job on SQL Server that dumps data to a table in
PostGreSQL.  This job worked fine when it was going against a PG 8.1.3
server, but since my upgrade to PG 8.3, it has been working
intermittently.  Mostly not working and erroring out with
=20
ERROR: XX000: function 60821C60 returned NULL
=20
I have other jobs doing similar feeds to other tables, and they still
work fine.  So I can't quite figure out what is wrong with this one.
The only difference with this table is that the copy is done hourly
where as the other ones are done daily.
=20
The table being inserted into looks like the below.  If I drop the table
and recreate it, the routine starts working again.  My SQL Server DTS
job uses the ODBC driver, but I tried a .NET script that uses the npgsql
driver and had the same issues.  All fields are inserted into except the
the_point and gid fields.  I'm going to reduce the frequency of
uploading and take out the OID to see if that makes a difference.
=20
CREATE TABLE hbasessionsremaining
(
  sessioncode character varying(17) NOT NULL,
  remainingslots integer,
  meetstarttime timestamp without time zone,
  meetendtime timestamp without time zone,
  number smallint NOT NULL,
  date timestamp without time zone,
  course character varying(5) NOT NULL,
  classcode character varying(8) NOT NULL,
  numberwaitlisted integer,
  sessiongroup character varying(17),
  "location" character varying(50),
  locparcelid character(10),
  descrip character varying(50),
  locationcode character varying(3) NOT NULL,
  the_point geometry,
  address character varying(500),
  gid serial NOT NULL,
  CONSTRAINT pk_hbasessionsremaining PRIMARY KEY (sessioncode),
  CONSTRAINT udx_hbasessionsremaining_gid UNIQUE (gid)
)=20
WITHOUT OIDS;
ALTER TABLE hbasessionsremaining OWNER TO robedev;
GRANT ALL ON TABLE hbasessionsremaining TO robedev;
GRANT ALL ON TABLE hbasessionsremaining TO dnddtsadmins WITH GRANT
OPTION;
=20
Thanks,
Regina
=20
=20
=20
=20
=20
=20

________________________________



The substance of this message, including any attachments, may be
confidential, legally
privileged and/or exempt from disclosure pursuant to Massachusetts
law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and
delete the material from any computer.

Re: ERROR: XX000: function 60821C60 returned NULL

От
Tom Lane
Дата:
"Obe, Regina" <robe.dnd@cityofboston.gov> writes:
> I have an SQL job on SQL Server that dumps data to a table in
> PostGreSQL.  This job worked fine when it was going against a PG 8.1.3
> server, but since my upgrade to PG 8.3, it has been working
> intermittently.  Mostly not working and erroring out with
>
> ERROR: XX000: function 60821C60 returned NULL

That's a pretty low-level error; you shouldn't be able to trigger it
yourself without writing your own datatype or some such.  Given the
set of types in your table, I'm betting that the bug is actually in
PostGIS, either in the geometry input converter or one of the index
support functions for geometry (you didn't show an index on the_point,
but is there one?).  Try asking over there if they know of any such
problems as of 8.2.

            regards, tom lane