[BUGS] pg_dump: Too much in COPY ouput

2001-06-01 Thread pgsql-bugs

Jean-Francois Leveque ([EMAIL PROTECTED]) reports a bug with a severity of 4
The lower the number the more severe it is.

Short Description
pg_dump: Too much  in COPY ouput

Long Description
System: SuSE 7.0
select version(); :
PostgreSQL 7.1.2 on i686-pc-linux-gnu, compiled by GCC 2.95.2

pg_dump inserts an extra  between double-quoted tablename
and FROM.

This was not the case with the version I used before:

System: SuSE 7.0
PostgreSQL RPM: postgres-7.0.2-29
select version(); :
PostgreSQL 7.0.2 on i686-pc-linux-gnu, compiled by gcc 2.95.2

Example form two pg_dump outputs 
7.1.2 :
COPY "list"  FROM stdin;
7.0.2 :
COPY "list" FROM stdin;


Sample Code


No file was uploaded with this report


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [BUGS] pg_dump: Too much in COPY ouput

2001-06-01 Thread Tom Lane

[EMAIL PROTECTED] writes:
> Example form two pg_dump outputs 
> 7.1.2 :
>   COPY "list"  FROM stdin;
> 7.0.2 :
>   COPY "list" FROM stdin;

I have a very hard time considering that a bug...

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



[BUGS] Trigger causes the server to crash with SEGV

2001-06-01 Thread pgsql-bugs

Vlad Seryakov ([EMAIL PROTECTED]) reports a bug with a severity of 1
The lower the number the more severe it is.

Short Description
Trigger causes the server to crash with SEGV

Long Description
PostgreSQL version : PostgreSQL 7.2devel on i686-pc-linux-gnu, compiled by GCC 
egcs-2.91.66
create table D_Inv_Location_Types (
   Inv_Loc_Type_ID integer not null,
   Inv_Loc_Type_Name varchar not null,
   Inv_Loc_Type_Description varchar not null,
   Inv_Loc_Type_Disp_ID_Name varchar null,
   CONSTRAINT DILT_pk PRIMARY KEY(Inv_Loc_Type_ID),
   CONSTRAINT DILT_uk UNIQUE(Inv_Loc_Type_Name)
);
insert into d_inv_location_types (inv_loc_type_id,inv_loc_type_name,inv_loc_type_desc
ription,inv_loc_type_disp_id_name) values(96,'State','These are what make up the Unit
ed States of America','State');
insert into d_inv_location_types (inv_loc_type_id,inv_loc_type_name,inv_loc_type_desc
ription,inv_loc_type_disp_id_name) values(3,'City','This is a big town','City');
insert into d_inv_location_types (inv_loc_type_id,inv_loc_type_name,inv_loc_type_desc
ription,inv_loc_type_disp_id_name) values(15,'County','This is a large piece of land
that holds numerous settlements including cities and towns.','County ID');
insert into d_inv_location_types (inv_loc_type_id,inv_loc_type_name,inv_loc_type_desc
ription,inv_loc_type_disp_id_name) values(174,'Country','This is an area of geographi
cal location that governs itself from a central location. i.e. Like that country Scot
land in the Continent of Europe','Country ID');
insert into d_inv_location_types (inv_loc_type_id,inv_loc_type_name,inv_loc_type_desc
ription,inv_loc_type_disp_id_name) values(166,'Central Office','CO is the facility wh
ere all Telco equipment serving a particular area is located. The CO may host voice a
nd/or data and/or video equipment.There may also be network management servers there.
','CO ID');
insert into d_inv_location_types (inv_loc_type_id,inv_loc_type_name,inv_loc_type_desc
ription,inv_loc_type_disp_id_name) values(4,'Street','This is basically a road','ACIS
A');
insert into d_inv_location_types (inv_loc_type_id,inv_loc_type_name,inv_loc_type_desc
ription,inv_loc_type_disp_id_name) values(337,'Intersection','This is a location that
 basically joins two points','Intersect ID');
create table D_Inv_Loc_Type_Parent_Allowed (
   Inv_Loc_Type_ID integer not null,
   Inv_Loc_Parent_ID integer not null,
   CONSTRAINT D_Inv_LPTA_pk PRIMARY KEY(Inv_Loc_Type_ID,Inv_Loc_Parent_ID),
   CONSTRAINT D_Inv_LPTA_fk FOREIGN KEY(Inv_Loc_Type_ID) references D_Inv_Location_Ty
pes(Inv_Loc_Type_ID),
   CONSTRAINT D_Inv_LPTA2_fk FOREIGN KEY(Inv_Loc_Parent_ID) references D_Inv_Location
_Types(Inv_Loc_Type_ID)
);
insert into d_inv_loc_type_parent_allowed (inv_loc_type_id,inv_loc_parent_id) values
(4,15);
insert into d_inv_loc_type_parent_allowed (inv_loc_type_id,inv_loc_parent_id) values
(4,3);
insert into d_inv_loc_type_parent_allowed (inv_loc_type_id,inv_loc_parent_id) values
(3,15);
insert into d_inv_loc_type_parent_allowed (inv_loc_type_id,inv_loc_parent_id) values
(15,96);
insert into d_inv_loc_type_parent_allowed (inv_loc_type_id,inv_loc_parent_id) values
(166,3);
insert into d_inv_loc_type_parent_allowed (inv_loc_type_id,inv_loc_parent_id) values
(96,174);
insert into d_inv_loc_type_parent_allowed (inv_loc_type_id,inv_loc_parent_id) values
(337,3);
insert into d_inv_loc_type_parent_allowed (inv_loc_type_id,inv_loc_parent_id) values
(337,4);
DROP FUNCTION sp_loc_parent_check(INTEGER);
CREATE FUNCTION sp_loc_parent_check(INTEGER) RETURNS BOOLEAN AS '
DECLARE
   ID ALIAS FOR $1;
   rows RECORD;
BEGIN
  FOR rows IN SELECT * FROM d_inv_loc_type_parent_allowed
  WHERE inv_loc_parent_id=ID LOOP
IF rows.inv_loc_type_id = ID THEN
   RAISE EXCEPTION ''OSS: You can not make a child of the location type its paren
t'';
END IF;
PERFORM sp_loc_parent_check(rows.inv_loc_type_id);
  END LOOP;
  RETURN TRUE;
END;' LANGUAGE 'plpgsql';

DROP FUNCTION loc_types_parent_trigger_func();
CREATE FUNCTION loc_types_parent_trigger_func() RETURNS OPAQUE AS '
DECLARE
rows RECORD;
BEGIN
PERFORM sp_loc_parent_check(NEW.inv_loc_type_id);
RETURN NEW;
END;' LANGUAGE 'plpgsql';

DROP TRIGGER loc_types_parent_trigger ON d_inv_loc_type_parent_allowed;
CREATE TRIGGER loc_types_parent_trigger AFTER INSERT ON d_inv_loc_type_parent_allowed
FOR EACH ROW EXECUTE PROCEDURE loc_types_parent_trigger_func();

/* The statement that is causing the error with the system*/
insert into d_inv_loc_type_parent_allowed values(96,3);




Sample Code


No file was uploaded with this report


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [BUGS] Trigger causes the server to crash with SEGV

2001-06-01 Thread Tom Lane

[EMAIL PROTECTED] writes:
> Trigger causes the server to crash with SEGV

> PostgreSQL version : PostgreSQL 7.2devel on i686-pc-linux-gnu, compiled by GCC 
>egcs-2.91.66

You'll need to be more specific than "7.2devel".  When was your last CVS
pull?

If it was since my trigger patches of yesterday evening, did you do a
full recompile after the CVS update?  I changed some trigger data
structures... 

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [BUGS] Trigger causes the server to crash with SEGV

2001-06-01 Thread Tom Lane

I tried it here.  I don't get a crash; I get a rather long delay and
then

psql:vlad.sql:61: NOTICE:  Error occurred while executing PL/pgSQL function 
sp_loc_parent_check
psql:vlad.sql:61: NOTICE:  line 12 at return
psql:vlad.sql:61: ERROR:  Memory exhausted in AllocSetContextCreate(8192)

which is not too surprising seeing that your function is in an infinite
recursion (chasing the loop 96 -> 15 -> 3 -> 96 that your insert has
created).

It would be interesting to know why your copy SEGV's rather than
recovering gracefully.  Can you provide a debugger backtrace from the
coredump?

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [BUGS] Trigger causes the server to crash with SEGV

2001-06-01 Thread Tom Lane

I wrote:
> I tried it here.  I don't get a crash; I get a rather long delay and
> then
> psql:vlad.sql:61: ERROR:  Memory exhausted in AllocSetContextCreate(8192)

Some experimentation with other infinitely-recursive plpgsql functions
soon turned up a crash, however: spi.c was being sloppy about not
checking for a failure return from malloc().  I have repaired that,
as well as some other similar omissions elsewhere in the backend.
I can't be sure if that's the case that was biting you, however.

Someday we ought to mount a concerted effort to get rid of all direct
uses of malloc() and friends in the backend; they're too easy to misuse,
and there's no good reason not to funnel everything through palloc.

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl