[BUGS] misleading error message
hi i just spent over 30 minutes trying to discover what was wrong. i was trying to create view: > create view views.session_user as brama-> select 1; ERROR: parser: syntax error at or near "session_user" at character 19 now - i know that session_user is reserver word, but the error message is totally misleading. can this be improved somehow? i'm using 7.4devel from cvs. depesz -- hubert depesz lubaczewski http://www.depesz.pl/ > wynajmę mieszkanie - 60 metrów, 3 pokoje, piastów - od lutego (po < -=> remoncie) interesuje cię - napisz: [EMAIL PROTECTED]<=- msg05693/pgp0.pgp Description: PGP signature
[BUGS] Bug #882: Cannot manually log in to database.
Ben Kinsey ([EMAIL PROTECTED]; [EMAIL PROTECTED]) reports a bug with a severity of 2 The lower the number the more severe it is. Short Description Cannot manually log in to database. Long Description We are receiving the following error when trying to manually log in to the the database: okapview# /opt/pgsql-7.1.3/bin/psql -U postgres -d AppliedView psql: connectDBStart() -- connect() failed: No such file or directory Is the postmaster running locally and accepting connections on Unix socket '/tmp/.s.PGSQL.5432'? We searched your documentation and all that it said was to verify that the postmaster daemon is running, and it already is running on the system. We have a daemon process that is connected to the database and it is not refused this connection. Only psql command line log ins are refused. Stopping and starting the postmaster daemon clears up this problem, but this problem creeps up about 2 times a week, and is a major annoyance. Sample Code No file was uploaded with this report ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] Postgres 7.3 in PPC
Hi, My name is Catarina Mónica, and I trying to install PostgreSQL 7.3 in a PPC860 processor and I not being sucessfull in the instalations. I followed all the instructions given by you but the problem is when I do /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data I always get a message like this The program '/usr/local/pgsql/bin/postgres' needed by initdb does not belong to PostgreSQL version 7.3, or there may be a configuration problem. Do you know how to help me? In the ./configure options I had to put --without-readline and --without-zlib, othersive in the same step (/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data) I always get Segmentation fault maybe the libraries I have aren't compiled in a good way for ppc. can you tell me something about this , also?? Thanks in advance Best regards Catarina Catarina Mónica *Telef: +351 234 403 626 Fax: +351 234 403 552 * : [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] Bug #878: different format of float values in 7.2.and
On Mon, 20 Jan 2003, Tom Lane wrote: TL> [EMAIL PROTECTED] writes: TL> > The following line: TL> > SELECT 1875/1000.0 TL> > produces different results. In 7.2.3 it is: TL> > ?column? TL> > - TL> >1.875 TL> TL> > while in 7.3.1 it is: TL> > ?column? TL> > - TL> > 1.87500 TL> TL> The above expression is taken as NUMERIC datatype in 7.3, rather than TL> FLOAT8 as it was in 7.2. To get the same output as before, try TL> SELECT 1875/1000.0::float8; Thanks. The main thing I understood is that it was done intentionally. Is there a kind of document (mail message maybe) that describes the intentions to make typecasts more strict and/or pecularities of such changes? I guess many users faced with similar problems, probably it was already explained somewhere. -- Regards, Den. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS]
Sir, In createdb execution the following error has occured. psql: could not connect to server: Connection refused Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"? createdb: database creation failed We created a unix socket, then connection is accepted. But it is expecting some parameters. What all are the parameters it is expecting while creating db. Expecting your reply Remya ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS]
IpcMemoryCreate: shmget(key=5432001, size=1417216, 03600) failed: Invalid argume nt This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter. You can either reduce the request size or reconfigure the kernel with larger SHMMAX. To reduce the request size (currently 1417216 bytes), reduce PostgreSQL's shared_buffers parameter (currently 64) and/or its max_connections parameter (currently 32). If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter, in which case raising the request size or reconfiguring SHMMIN is called for. The PostgreSQL Administrator's Guide contains more information about shared memory configuration. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] DELETE permission problems on table with long name after upgradeto 7.3.1
Hi! Our admin upgraded PostgreSQL 7.2.3 to 7.3.1 a while ago (dump and restore). Previously I had a table with a long name (>32 chars), which at creation was truncated to proper length. The table was used from a perl-script (using the full name) doing mostly DELETE's and INSERT's. The user accessing the table had been granted SELECT, UPDATE and INSERT. After the upgrade the calls to the table didn't truncate the name any longer (as expected), and thus didn't find the table. So I renamed the table to it's full length name, and now the scripts did find the table again. But - deletes were no longer allowed! Selects are ok, and so are inserts and updates, but delete gives "permission denied". I've verified that grants are the same as before. Altering the table name to the previous short version gives the same result. Putting away the data in a temp table, dropping the problematic one and recreating it made the whole thing work again. Below is the declaration used (before and after the upgrade): Regards, Andreas drop table gradsite_dev_course_classification; create table gradsite_dev_course_classification ( cid integer references gradsite_dev_courses (cid) on delete cascade, class integer references gradsite_dev_course_classes (class) on delete cascade, primary key (cid, class) ); create index gradsite_dev_course_classification_cid on gradsite_course_classification (cid); create index gradsite_dev_course_classification_class on gradsite_course_classification (class); grant select,insert,update,delete on gradsite_dev_course_classification to gradsite; ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] IN selection issues
I am encountering problems with IN selections. I am trying this query : delete from status where status_id not in (select distinct status_id from company); "status_id" is a foreign key in "company". It does not delete any records from status table whereas it should because the sub query returns some records. Any explanation ? Thanks -- M. Jérôme CALAIS (Ingénieur Conseil) Portable: 0620648297 E-Mail: [EMAIL PROTECTED] -- Arunix Z.A.L St Amé 62806 Liévin Cedex France Tel: 0321142843 Fax: 0321142831 URL: http://www.arunix.fr ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS]
Sir, In createdb execution the following error has occured. psql: could not connect to server: Connection refused Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"? createdb: database creation failed We created a unix socket, then connection is accepted. But it is expecting some parameters. What all are the parameters it is expecting while creating db. Expecting your reply Remya ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Bug #882: Cannot manually log in to database.
[EMAIL PROTECTED] writes: > okapview# /opt/pgsql-7.1.3/bin/psql -U postgres -d AppliedView > psql: connectDBStart() -- connect() failed: No such file or directory > Is the postmaster running locally > and accepting connections on Unix socket '/tmp/.s.PGSQL.5432'? > Stopping and starting the postmaster daemon clears up this problem, but this problem >creeps up about 2 times a week, and is a major annoyance. Sounds to me like you've got a cron script that removes everything in tmp about twice a week. I suggest teaching it not to remove socket files. On most Unixen the mod date on a socket file isn't changed by normal activity, so a tmp-cleaner that only pays attention to the mod date will mistakenly decide a socket is fair game for removal. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] Bug #883: explain analyze causes postgres to die
Christopher Hodson ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
explain analyze causes postgres to die
Long Description
running explain analyze on the code below causes postgres to crash. See below for
error messages.
version
---
PostgreSQL 7.3.1 on i386-portbld-freebsd4.6.1, compiled by GCC 2.95.3
from psql (almost immediately):
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
the log has this to say:
2003-01-23 20:57:54 [29981] LOG: server process (pid 30037) was terminated by signal
11
2003-01-23 20:57:54 [29981] LOG: terminating any other active server processes
The connection to the server was lost. Attempting reset: 2003-01-23 20:57:54 [29981]
LOG: all server processes terminated; reinitializing shared memory and semaphores
2003-01-23 20:57:54 [30051] LOG: connection received: host=[local]
2003-01-23 20:57:54 [30051] FATAL: The database system is starting up
Failed.
!# 2003-01-23 20:57:54 [30050] LOG: database system was interrupted at 2003-01-23
20:40:44 GMT
2003-01-23 20:57:54 [30050] LOG: checkpoint record is at 26/201BAC04
2003-01-23 20:57:54 [30050] LOG: redo record is at 26/201BAC04; undo record is at
0/0; shutdown TRUE
2003-01-23 20:57:54 [30050] LOG: next transaction id: 5645; next oid: 78509014
2003-01-23 20:57:54 [30050] LOG: database system was not properly shut down;
automatic recovery in progress
2003-01-23 20:57:54 [30050] LOG: ReadRecord: record with zero length at 26/201BAC44
2003-01-23 20:57:54 [30050] LOG: redo is not required
2003-01-23 20:57:57 [30050] LOG: database system is ready
Sample Code
explain analyze INSERT INTO stubs(id, stub_id, nodecount, platform_id, return_count)
SELECT I.id, A.stub_id, L.nodecount, P.platform_id, count(*)
FROM logdata L, id_lookup I, all_stubs A, platform P
WHERE lower(L.email) = lower(I.email)
AND L.stub_marks = A.stub_marks
AND L.os_type = P.os_type
AND L.cpu_type = P.cpu_type
AND L.version = P.version
GROUP BY I.id, A.stub_id, L.nodecount, P.platform_id
here are the results of 'explain' on the same query
Subquery Scan "*SELECT*" (cost=9281796.01..9313773.17 rows=213181 width=155)
-> Aggregate (cost=9281796.01..9313773.17 rows=213181 width=155)
-> Group (cost=9281796.01..9308443.64 rows=2131811 width=155)
-> Sort (cost=9281796.01..9287125.53 rows=2131811 width=155)
Sort Key: i.id, a.stub_id, l.nodecount, p.platform_id
-> Nested Loop (cost=2.75..8361073.78 rows=2131811 width=155)
-> Nested Loop (cost=2.75..1632538.08 rows=1083 width=101)
-> Hash Join (cost=2.75..1626418.99 rows=1083
width=78)
Hash Cond: ("outer".os_type = "inner".os_type)
Join Filter: (("outer".cpu_type =
"inner".cpu_type) AND ("outer"."version" = "inner"."version"))
-> Seq Scan on logdata l
(cost=0.00..458727.96 rows=21230696 width=62)
-> Hash (cost=2.40..2.40 rows=140 width=16)
-> Seq Scan on platform p
(cost=0.00..2.40 rows=140 width=16)
-> Index Scan using all_marks on all_stubs a
(cost=0.00..5.64 rows=1 width=23)
Index Cond: ("outer".stub_marks = a.stub_marks)
-> Index Scan using idlookup_email_lower on id_lookup i
(cost=0.00..6177.29 rows=1968 width=54)
Index Cond: (lower(("outer".email)::text) =
lower((i.email)::text))
(17 rows)
No file was uploaded with this report
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Postgres 7.3 in PPC
Catarina Monica <[EMAIL PROTECTED]> writes: > My name is Catarina Mónica, and I trying to install PostgreSQL 7.3 in a > PPC860 processor and I not being sucessfull in the instalations. What OS (and what version) are you running on that? > I always get a message like this > The program > '/usr/local/pgsql/bin/postgres' > needed by initdb does not belong to PostgreSQL version 7.3, or > there may be a configuration problem. What do you see when you do /usr/local/pgsql/bin/postgres --version by hand? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] IN selection issues
=?ISO-8859-1?Q?J=E9r=F4me?= Calais <[EMAIL PROTECTED]> writes: > I am encountering problems with IN selections. > I am trying this query : > delete from status where status_id not in (select distinct status_id > from company); I'll bet the sub-select yields some NULL rows? If so, this is not a bug. NOT IN is not very intuitive about handling of NULLs. I suggest you consult a SQL textbook ... 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])
Re: [BUGS] Bug #883: explain analyze causes postgres to die
[EMAIL PROTECTED] writes: > explain analyze causes postgres to die Can't do much with this, since you have not provided a complete test case. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] DELETE permission problems on table with long name after upgrade to 7.3.1
Andreas Lange <[EMAIL PROTECTED]> writes: > After the upgrade the calls to the table didn't truncate the name any > longer (as expected), and thus didn't find the table. So I renamed the > table to it's full length name, and now the scripts did find the table > again. But - deletes were no longer allowed! Selects are ok, and so are > inserts and updates, but delete gives "permission denied". I think this is probably pilot error --- are you sure you don't have a table laying about with the truncated name? The example you give does not work as-is (many references to tables not included) and when I remove the undefined references, I see no failure. So it doesn't persuade me that there's any bug. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS]
[EMAIL PROTECTED] writes: > psql: could not connect to server: Connection refused > Is the server running locally and accepting > connections on Unix domain socket "/tmp/.s.PGSQL.5432"? Are you sure the postmaster is running? I don't see how you could get a "connection refused" on a Unix socket unless there is nothing listening for connections. 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])
Re: [BUGS] IN selection issues
Jérôme Calais writes: > delete from status where status_id not in (select distinct status_id > from company); > > "status_id" is a foreign key in "company". > > It does not delete any records from status table whereas it should > because the sub query returns some records. There are probably null values in the result set of the subselect. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
