[BUGS] Segmentation fault when changing view

2001-04-16 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
Segmentation fault when changing view

Long Description
When i dropped column quantity in view package_tree_view, recreated this view, but 
didn't recreated the view package_packages_tree_view and ran SQL statement below in 
Example, the server died with segfault.
Earlier i remember it complaints about missing cache object but didn; crashed.
Thank you


Database schema:

CREATE TABLE usage_rates (
   rate_id VARCHAR(16) NOT NULL CHECK(rate_id != ''),
   rate_name VARCHAR(64) NOT NULL,
   description VARCHAR(255) NULL,
   CONSTRAINT usage_rates_pk PRIMARY KEY(rate_id),
   CONSTRAINT usage_rates_un UNIQUE(rate_name)
);

CREATE TABLE prices (
   price_id INTEGER NOT NULL CHECK(price_id > 0),
   install_price NUMERIC(5,2) DEFAULT 0 NOT NULL,
   periodic_price NUMERIC(5,2) DEFAULT 0 NOT NULL,
   usage_price NUMERIC(5,2) DEFAULT 0 NOT NULL,
   usage_rate VARCHAR(16) NULL
  CONSTRAINT service_usage_rate_fk REFERENCES usage_rates(rate_id),
   termination_price NUMERIC(5,2) DEFAULT 0 NOT NULL,
   CONSTRAINT prices_pk PRIMARY KEY(price_id)
);

CREATE TABLE service_status (
   status_id VARCHAR(16) NOT NULL CHECK(status_id != ''),
   status_name VARCHAR(64) NOT NULL,
   precedence SMALLINT NOT NULL,
   description VARCHAR(255) NULL,
   CONSTRAINT service_status_pk PRIMARY KEY(status_id),
   CONSTRAINT service_status_un UNIQUE(status_name)
);

CREATE TABLE services (
   service_id INTEGER NOT NULL CHECK(service_id > 0),
   service_name VARCHAR(64) NOT NULL,
   service_status VARCHAR(16) NOT NULL
  CONSTRAINT service_status_fk REFERENCES service_status(status_id),
   service_owner INTEGER NULL
  CONSTRAINT service_owner_fk REFERENCES services(service_id),
   description VARCHAR(255) NULL,
   path VARCHAR(255) NULL,
   CONSTRAINT services_pk PRIMARY KEY(service_id),
   CONSTRAINT service_un UNIQUE(service_name),
   CONSTRAINT service_owner_ck CHECK(service_id != service_owner)
);

CREATE TABLE packages (
   package_id INTEGER NOT NULL CHECK(package_id > 0),
   package_name VARCHAR(64) NOT NULL,
   package_status VARCHAR(16) NOT NULL
  CONSTRAINT package_status_fk REFERENCES service_status(status_id),
   start_date DATETIME NOT NULL,
   stop_date DATETIME NOT NULL,
   description VARCHAR(255) NULL,
   install_price NUMERIC(5,2) NULL,
   periodic_price NUMERIC(5,2) NULL,
   termination_price NUMERIC(5,2) NULL,
   CONSTRAINT packages_pk PRIMARY KEY(package_id),
   CONSTRAINT packages_un UNIQUE(package_name)
);

CREATE TABLE package_services (
   package_id INTEGER NOT NULL REFERENCES packages(package_id),
   service_id INTEGER NOT NULL REFERENCES services(service_id),
   quantity SMALLINT DEFAULT 1 NOT NULL,
   description VARCHAR(255) NULL,
   CONSTRAINT package_servies_pk PRIMARY KEY(package_id,service_id)
);
CREATE TABLE package_packages (
   package_id INTEGER NOT NULL
 CONSTRAINT packages_pkg_fk REFERENCES packages(package_id),
   package_owner INTEGER NOT NULL
 CONSTRAINT packages_pkg_owner_fk REFERENCES packages(package_id),
   price_id INTEGER NOT NULL
 CONSTRAINT packages_price_fk REFERENCES prices(price_id),
   CONSTRAINT packages_pkg_pk PRIMARY KEY(package_id,package_owner),
   CONSTRAINT packages_pkg_ck CHECK(package_id != package_owner)
);

CREATE TABLE package_tree (
   path VARCHAR(255) NOT NULL,
   id INTEGER NOT NULL
 CONSTRAINT packages_tree_id_fk REFERENCES packages(package_id),
   owner INTEGER NULL
 CONSTRAINT packages_tree_o_fk REFERENCES packages(package_id),
   tree_level INTEGER NOT NULL,
   leaf_node CHAR(1) DEFAULT 'N' NOT NULL
 CONSTRAINT packages_leaf_ck CHECK(leaf_node IN ('Y','N')),
   path2 VARCHAR(255) NOT NULL,
   CONSTRAINT packages_tree_pk PRIMARY KEY(path)
);

DROP VIEW packages_tree_view;
CREATE VIEW packages_tree_view AS
  SELECT p.package_id,
 p.package_name,
 p.package_status,
 status_name,
 ps.service_id,
 ps.quantity,
 COALESCE(p.description,ps.description) AS description,
 t.path,
 t.owner,
 t.tree_level,
 t.leaf_node,
 s.service_name,
 s.service_status
  FROM packages p,
   service_status,
   package_tree t
   LEFT OUTER JOIN package_services ps ON t.id=ps.package_id
   LEFT OUTER JOIN services s ON ps.service_id=s.service_id
  WHERE t.id=p.package_id AND
p.package_status=status_id;

DROP VIEW package_packages_tree_view;
CREATE VIEW package_packages_tree_view AS
  SELECT pv.*,
 pr.price_id,
 pr.install_price,
 pr.periodic_price,
 pr.usage_price,
 pr.termination_price
  FROM packages_tree_view pv
   LEFT OUTER JOIN package_packages pp
   ON pv.package_id=pp.package_id AND
  pv.owner=pp.package_owner
   LEFT OUTER JOIN prices pr ON pr.price_id=pp.price_id;

INSERT INTO service_status (status_id,status_name,precedence,description)

Re: [BUGS] Segmentation fault when changing view

2001-04-16 Thread Tom Lane

[EMAIL PROTECTED] writes:
> Segmentation fault when changing view

I ran this script and didn't see any problem ...

In general though, whenever you drop/recreate a view you are going to
have to drop/recreate views that refer to it, too.

regards, tom lane

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



Re: [BUGS] Segmentation fault when changing view

2001-04-16 Thread Tom Lane

Vlad Seryakov <[EMAIL PROTECTED]> writes:
> Is it possible to get core file, i couldn't find how to setup this.

A crashed backend should leave a core file in $PGDATA/base/YOURDB/core

If you don't see a core file in that directory, it's possible that
the postmaster was started with "ulimit -c 0" to forbid core dumping.
(I think most Linuxen run their boot scripts with this setting.)
Restart the postmaster with "ulimit -c unlimited" to allow core dumping.
You might want to add that command to the boot script for Postgres.

regards, tom lane

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



Re: [BUGS] Segmentation fault when changing view

2001-04-16 Thread Tom Lane

Vlad Seryakov <[EMAIL PROTECTED]> writes:
> i just created new database and ran this script.
> First time the query ran okay, then i removed ps.quantity
> and re-created package_tree_view.
> After this the query crashed the server.

Hmm, I see: there's not a defense against references to
no-longer-existing tables/views when the same name has been re-used
for a new table/view.  I've fixed this.  Thanks for the report!

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])



[BUGS] another possible ODBC error (inserting memo fields in varchar)

2001-04-16 Thread Calvin Dodge

I've run across a consistent problem with M$oft Access, psqlodbc.dll,
and Postgres.

If I try to do an insert query from an Access table to a Postgres table,
Access 97 crashes IF that insert includes any memo fields (appending to
a varchar field, in my case). Access 2000 doesn't crash, but it doesn't
append anything, either.

For the record, I'm using PostgreSQL 7.1 on Red Hat 7.0 (using the RPMs
from Sourceforge's PostgreSQL mirror), and the latest version of
psqlodbc (004).  But the same problem occurred with PostgreSQL 7.0, and
with earlier version of psqlodbc.

I CAN work around this by inserting everything EXCEPT for the memo
fields, then updating the destination fields using code (ODBC workspace
and ODBC connection's Execute method), but it does concern me a bit.

Am I doing something wrong here? I wonder because I haven't seen this
problem mentioned in my Google and Postgresql.org searches. Or is this
so well-known that everyone already knows the workaround, so it's not
considered newsworthy? Is this a general issue with Access and ODBC,
rather than specifically with psqlodbc?  Inquiring minds like mine want
to know.

Thanks for listening,

Calvin Dodge
[EMAIL PROTECTED] (writing from work)

---(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



[BUGS] p.s. (Re: another possible ODBC error)

2001-04-16 Thread Calvin Dodge

It also doesn't matter whether I have MDAC version 2.5 OR 2.6 installed.

Calvin

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

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