Ah! pgsql query leads to evil - Mailing list pgsql-admin

From Jamie Lawrence
Subject Ah! pgsql query leads to evil
Date
Msg-id 20031128151212.GD24082@clueinc.net
Whole thread Raw
Responses Re: Ah! _psql_ query leads to evil
Re: Ah! pgsql query leads to evil
List pgsql-admin
OK, my baseline tables are a states table, from commonly available
sources, and cities, from the Census. \d's are:

cal=# \d states
                                       Table "public.states"
   Column   |            Type             |                       Modifiers
------------+-----------------------------+--------------------------------------------------------
 id         | integer                     | not null default nextval('public.states_id_seq'::text)
 name       | text                        |
 abbr       | text                        |
 createdate | timestamp without time zone | default now()
 moddate    | timestamp without time zone |
Indexes: states_pkey primary key btree (id)
Triggers: timestamp_tr

cal=# \d cities
                                       Table "public.cities"
   Column   |            Type             |                       Modifiers
------------+-----------------------------+--------------------------------------------------------
 id         | integer                     | not null default nextval('public.cities_id_seq'::text)
 name       | text                        |
 createdate | timestamp without time zone | default now()
 moddate    | timestamp without time zone |
 states_id  | integer                     |
Indexes: cities_pkey primary key btree (id)
Foreign Key constraints: valid_state FOREIGN KEY (states_id) REFERENCES states(id) ON UPDATE NO ACTION ON DELETE NO
ACTION
Triggers: timestamp_tr

(Timestamps are an ease of use thing - we can purge data if someone
screws up easily. Otherwise, 'id' is defined as SERIAL PRIMARY KEY,
states_id is INT REFERECES states)

I enter a query like so, and get the following errors:

cal=# select * from states, cities;
server sent binary data ("B" message) without prior row description ("T" message)
server sent binary data ("B" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent binary data ("B" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
Enter data to be copied followed by a newline.
End with a backslash and a period on a line by itself.
>> \.
unexpected response from server; first received character was "a"
lost synchronization with server, resetting connection
Asynchronous NOTIFY '2003-11-26 18:15:20.548647' from backend with pid 30 received.
Asynchronous NOTIFY 'n' from backend with pid 1969386866 received.
Asynchronous NOTIFY '2003-11-26 18:15:20.548647' from backend with pid 30 received.
Asynchronous NOTIFY 't' from backend with pid 1836020325 received.
Asynchronous NOTIFY '' from backend with pid 1986359929 received.


I know that's a pathological query, and I performed it only because
Software Gone Wrong did it, and I was looking to see what happened.
The result just seems really, really wrong, and I'm wondering if anyone has
seen something like that before.

This is PG 7.3.4, on Debian/stable on a DEC box (compiled here,
but we didn't do anything strange to it).

-j

--
Jamie Lawrence                                        jal@jal.org
Prediction is very difficult, especially of the future.
   - Niels Bohr



pgsql-admin by date:

Previous
From: Daniel Rubio
Date:
Subject: Re: Randomly error using php persistent connections
Next
From: Jamie Lawrence
Date:
Subject: Re: Ah! _psql_ query leads to evil