|
|
[BUGS] BUG #3558: Comunication cut after 5 mins aprox. in remote acces to Postgres
By Gilberto Vidal at Aug 20, 2007, 6:03 pm UTC
The following bug has been logged online: Bug reference: 3558 Logged by: Gilberto Vidal Email address: gvidal@att.net.mx PostgreSQL version: 8.2 Operating system: SUSE Linux 10.0 (X86-64) Kernel 2.6.13-15 Description: Comunication cut after 5 mins aprox. in remote acces to Postgres Details: I... More...
The following bug has been logged online:
Bug reference: 3558
Logged by: Gilberto Vidal
Email address: [email protected: g...@att.net.mx]
PostgreSQL version: 8.2
Operating system: SUSE Linux 10.0 (X86-64) Kernel 2.6.13-15
Description: Comunication cut after 5 mins aprox. in remote acces to
Postgres
Details:
I develop an aplication for Up,Down,Change records in Table 'Customs' in
Postgres.
First I Start Linux Server with Postgres about no problem.
I connect to Postgres via IP Public registered in my office Router. Router
forward at IP and Port in Server Postgre No problem all OK.
After Working with aplication, and prefectly conection at Remote Postgres
and Database, aprox 5 min then disconect
received messages into aplication "Disconect abnormally DataBase
'BD_PROJECT'
What is the problem? Do you Help me?
By Attention Thanks.
atte.
GVL
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
0 Replies
|
|
|
[BUGS] BUG #3555: does not work VACUUM
By Dmitry at Aug 20, 2007, 4:30 pm UTC
The following bug has been logged online: Bug reference: 3555 Logged by: Dmitry Email address: dd442@mail.ru PostgreSQL version: 8.1 Operating system: Linux Slackware 11 Description: does not work VACUUM Details: root@darkstar:~# su postgres postgres@darkstar:/root$ postgres -D /var/lib/pgsql/data/... More...
The following bug has been logged online:
Bug reference: 3555
Logged by: Dmitry
Email address: [email protected: d...@mail.ru]
PostgreSQL version: 8.1
Operating system: Linux Slackware 11
Description: does not work VACUUM
Details:
root@darkstar:~# su postgres
postgres@darkstar:/root$ postgres -D /var/lib/pgsql/data/ -P taxi
WARNING: database "baza" must be vacuumed within 976150 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"baza".
WARNING: database "baza" must be vacuumed within 976150 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"baza".
PostgreSQL stand-alone backend 8.1.5
backend>VACUUM;
WARNING: database "baza" must be vacuumed within 976005 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"baza".
WARNING: database "baza" must be vacuumed within 976004 transactions
HINT: To avoid a database shutdown, execute a full-
[...]
WARNING: database "baza" must be vacuumed within 975895 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"baza".
backend>
is not got use VACUUM, VACUUM FULL...
3 months PostgreSQL work together with 1C:Enterprice 8.1 server.
Prompt, how correct givenned mistake.
Thank you, Dmitry.
2 Replies
|
|
|
[BUGS] BUG #3556: Installroutine hides destination folder
By Ruediger Kemmler at Aug 20, 2007, 08:08 am UTC
The following bug has been logged online: Bug reference: 3556 Logged by: Ruediger Kemmler Email address: r.kemmler@gmx.de PostgreSQL version: 8.2 Operating system: Windows XP/Vista Description: Installroutine hides destination folder Details: If you click first on the components which you want to... More...
The following bug has been logged online:
Bug reference: 3556
Logged by: Ruediger Kemmler
Email address: [email protected: r.ke...@gmx.de]
PostgreSQL version: 8.2
Operating system: Windows XP/Vista
Description: Installroutine hides destination folder
Details:
If you click first on the components which you want to install, the field
where the installation folder can be changed disappears and can't be
selected any more.
You have to go back in the installation routine to resolve it.
Minor bug, but can be problematic.
Kind regards
Ruediger
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
2 Replies
|
|
|
[BUGS] BUG #3530: Can't start as service if sb created 'c:\program' file
By " at Aug 20, 2007, 04:28 am UTC
The following bug has been logged online: Bug reference: 3530 Logged by: Email address: irek_m@poczta.fm PostgreSQL version: 8.1 Operating system: Windows XP Description: Can't start as service if sb created 'c:\program' file Details: I've installed PostgreSQL in 'c:\program files'. Some buggy... More...
The following bug has been logged online:
Bug reference: 3530
Logged by:
Email address: [email protected: i...@poczta.fm]
PostgreSQL version: 8.1
Operating system: Windows XP
Description: Can't start as service if sb created 'c:\program' file
Details:
I've installed PostgreSQL in 'c:\program files'. Some buggy program created
file named 'c:\program', and what? PostgreSQL doesn't start!
This error is due to Windows's stupid rules of resolving executable names.
You've added registry entry ImagePath=c:\program files\Postgre
SQL\bin\pg_ctl.exe ...
Now Windows tries to execute c:\program, if not found - c:\program
files\Postgre, and so on, until reaches the end of string.
pg_ctl.exe when registering the service should quote this name:
ImagePath="c:\program files\Postgre SQL\bin\pg_ctl.exe".
But even this doesn't solve the problem, pg_ctl.exe starts postgres.exe, and
probably you haven't used quotations again in CreateProcess invocation. So
there are at least two bugs with lack of "..." in pg_ctl.exe.
If the server started not using net start, but manually (using postgres.exe
-D "..."), everything works ok, so postgres.exe probably doesn't have this
bug.
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
1 Reply
|
|
|
[BUGS] POSTGRES - DATA RECOVERY
By Alejandro Sengès González at Aug 20, 2007, 03:11 am UTC
Please I beg your perdon I need some help with postgres running on windows. I copy the Postgres archives under Program files and Lost all information on my server so know I need to recreate all from that Copy wich contains the data folder and base folder with database oid with its contents. "BUT"... More...
Please I beg your perdon I need some help with postgres running on windows.
I copy the Postgres archives under Program files and Lost all information on
my server so know I need to recreate all from that Copy wich contains the
data folder and base folder with database oid with its contents. "BUT" when
installing it all and copying the folder data the schemas does not appear
and even I cannot see anything of the data I had before...
Please if you mey help I will appreciate it!!!!
Best regards,
--
Alejandro Sengès González
PHP Programmer
1 Reply
|
|
|
[BUGS] 8.3devel BUG with Cash send and recv
By Andrew Chernow at Aug 19, 2007, 8:10 pm UTC
There is what looks like a bug in 8.3devel. When getting the money type in binary format from a libpq client, the below error is thrown from the backend: ERROR: unsupported integer size 8 It appears that the Cash typedef, defined in include/utils/cash.h, has changed to an int64 (previously an... More...
There is what looks like a bug in 8.3devel. When getting the money type in
binary format from a libpq client, the below error is thrown from the backend:
ERROR: unsupported integer size 8
It appears that the Cash typedef, defined in include/utils/cash.h, has changed
to an int64 (previously an int32). The cash_send and cash_recv functions, in
backend/utils/adt/cash.c, are still calling pq_sendint and pq_getmsgint.
I tested on an 8.2rc box and that did not suffer from this issue because it uses
a 32-bit Cash type.
Below is a test to reproduce the issue.
create table money_test (amount money);
insert into money_test values ('13.85');
/* libpq test code (breaks on 8.3devel, works on 8.2rc) */
#include <libpq-fe.h>
#include <stdio.h>
int main(void)
{
PGresult *res;
PGconn *conn = PQconnectdb("hostaddr=127.0.0.1 user=postgres");
if(PQstatus(conn) != CONNECTION_OK)
{
printf("connection failure\n");
return 1;
}
res = PQexecParams(
conn,
"SELECT amount FROM money_test LIMIT 1",
0,
(const Oid *)NULL,
(const char * const *)NULL,
(const int *)NULL,
(const int *)NULL,
1); /* binary */
printf("tuples=%d, err=%s, res_err=%s\n",
PQntuples(res),
PQerrorMessage(conn),
PQresultErrorMessage(res));
PQclear(res);
PQfinish(conn);
return 0;
}
andrew
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
0 Replies
|
|
|
[BUGS] JDBC-Interface - Behaviour on Update, Insert or Delete returning ResultSets - Inconsistency to Console & ODBC
By Otto Weichselbaum at Aug 18, 2007, 5:29 pm UTC
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> Dear Ladies and Gentlemen, I do not know if this can even be considered a bug, but I would be pleased, if somebody could make a statement on this: environment: PostgreSQL 8.1 and 8.2 Redhat and WinXP While using views calling functions... More...
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Dear Ladies and Gentlemen,
I do not know if this can even be considered a bug, but I would be
pleased, if somebody could make a statement on this:
environment:
PostgreSQL 8.1 and 8.2
Redhat and WinXP
While using views calling functions on INSERT, UPDATE and DELETE via
according rules, I noticed an inconsistent behaviour of the
JDBC-interface of postgres;
an INSERT-, UPDATE- or DELETE-statement producing tuples as
return-value (in our case through rules calling functions but although
via the 'RETURNING'-clause of a single INSERT- or UPDATE-statement) is
returning the expected number of tuples when called via the console
(even through pgAdmin) or via ODBC
BUT
when called via JDBC only an 'UpdateCount' of 0 is returned;
debugging to protocol-level showed, that the postgreSQL-server does not
even differ between a 'simple' UPDATE or one returning tuples;
a 'simple' UPDATE returning only an 'UpdateCount' produces the
following sequence of commands (at protocol-level):
49 - 50 - 110 - 67 - 90 or in characters '1' - '2' - 'n' -
'C' - Z'
exactly the same is returned on an UPDATE returning tuples;
of course, as 'n' means that no data is available (according to class
org.postgresql.core.v3.QueryExecutorImpl) no tuple will be available
and the 'UpdateCount' will also be 0;
... so am I right guessing that there is no way to retrieve the
resulting tuples via JDBC? (- in difference to the console and ODBC)
For our needs we implemented a java.sql.Driver encapsulating the
sun.jdbc.odbc.JdbcOdbcDriver that returns the expected values as a
workaround, but that causes additional conversions that are not really
necessary;
in my opinion it would be a better solution to leave the decision,
whether to return the tuples, an 'UpdateCount' or even throw an
Exception up to the implementor of the driver and not to ignore the
fact that tuples where produced already on server-side;
I am looking forward to hearing your point of view!
With best regards,
Otto Weichselbaum
--
<!--
body{
font-family: arial;
font-size: 12px;
}
p.title{
font-size: 14px;
font-variant: small-caps;
font-weight: bold;
font-style: italic;
margin-top: 3px;
margin-bottom: 3px;
}
p.space{
margin-top: 2px;
margin-bottom: 2px;
}
-->
____________________________
SEW – Otto Weichselbaum
DI (FH) Otto Weichselbaum
A-4040 LINZ, Heindlstrasse 19/4
eMail: [email protected: Otto.Weichse...@sew.at]
fax: +43 (0) 732 925400
mobile: +43 (0) 664 8251111
1 Reply
|
|
|
[BUGS] error while starting database
By Nitin Saxena at Aug 18, 2007, 5:01 pm UTC
I am using postgres 7.0 on linux platform. My java application was running fine ,but i got this message Connection refused. Check that the hostname and port is correct, and that the postmaster is r unning with the -i flag, which enables TCP/IP networking. at... More...
I am using postgres 7.0 on linux platform.
My java application was running fine ,but i got this message
Connection refused. Check that the hostname and port is correct, and that
the postmaster is r
unning with the -i flag, which enables TCP/IP networking.
at org.postgresql.Connection.openConnection(Connection.java:123)
at org.postgresql.Driver.connect(Driver.java:116)
at java.sql.DriverManager.getConnection(DriverManager.java:517)
at java.sql.DriverManager.getConnection(DriverManager.java:177)
at SendGrpSmpp.readSMPPtable(SendGrpSmpp.java:219)
at SendGrpSmpp.run(SendGrpSmpp.java:96)
When i am connecting as su via su - postgres
at bash: when i give psql Database Name
It is giving error:
psql: connectDBStart() -- connect() failed: No such file or directory
Is the postmaster running at 'localhost'
and accepting connections on Unix socket '5432'?
when i am using pg_ctl status command:
it gives output: pg_ctl: postmaster is running (pid: 776)
options are:
/usr/bin/postmaster
-p 5432
-D /var/lib/pgsql/data
-B 64
-b /usr/bin/postgres
-i
-N 32
when i am using pg_ctl stop it gives
/usr/bin/pg_ctl: kill: (776) - No such pid
postmaster successfully shut down.
when i am using pg_ctl restart it gives
bash-2.04$ pg_ctl restart
/usr/bin/pg_ctl: kill: (776) - No such pid
Waiting for postmaster shutting
down...............................................................pg_ctl:
postmaster does not shut down
when i am giving pg_ctl start:
pg_ctl: It seems another postmaster is running. Try to start postmaster
anyway.
FATAL: StreamServerPort: bind() failed: No such file or directory
Is another postmaster already running on that port?
If not, remove socket node (/tmp/.s.PGSQL.5432) and retry.
pg_ctl: Cannot start postmaster. Is another postmaster is running?
bash-2.04$ /usr/bin/postmaster: cannot create UNIX stream port.
Expecting your kind help on urgent.
Regards--
NItin Saxena
9 Replies
|
|
|
[BUGS] BUG #3544: SQLException from JDBC driver
By Scott Harper at Aug 17, 2007, 7:03 pm UTC
The following bug has been logged online: Bug reference: 3544 Logged by: Scott Harper Email address: scott@mycellularsessions.com PostgreSQL version: 8.1.9 Operating system: Debian Linux (2.6.18-4-486) Description: SQLException from JDBC driver Details: I have installed PostgreSQL 8.1 via the... More...
The following bug has been logged online:
Bug reference: 3544
Logged by: Scott Harper
Email address: [email protected: s...@mycellularsessions.com]
PostgreSQL version: 8.1.9
Operating system: Debian Linux (2.6.18-4-486)
Description: SQLException from JDBC driver
Details:
I have installed PostgreSQL 8.1 via the Debian package manager (APT) --
installed the package postgresql-8.1.
We are running Sun Java 5, Apache 2, and Tomcat 5.5.
From the discussion at http://jdbc.postgresql.org/download.html, I have
determined that I should be using the 8.1-410 JDBC 3 driver.
I downloaded the driver, and it is bundled into my servlet's war file in
WEB-INF/lib.
When the servlet makes the DriverManager.getConnection() call, the following
exception is thrown:
org.postgresql.util.PSQLException: Something unusual has occured to cause
the driver to fail. Please report this exception.
I wasn't sure to whom I should report the exception, so I started here. :)
I should point out that I have successfully run the same servlet, with the
same JDBC driver, on an equivalent installation on Mac OS X.
Any ideas? Is there anything special I need to know about running JDBC on a
Debian Linux platform?
Thanks,
Scott
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
2 Replies
|
|
|
[BUGS] BUG #3504: Some listening sessions never return from writing, problems ensue
By Peter Koczan at Aug 17, 2007, 5:17 pm UTC
The following bug has been logged online: Bug reference: 3504 Logged by: Peter Koczan Email address: pjkoczan@gmail.com PostgreSQL version: 8.2.4 Operating system: CentOS 4.5 Linux (RHEL 4), kernel 2.6.9-55.ELsmp Description: Some listening sessions never return from writing, problems ensue... More...
The following bug has been logged online:
Bug reference: 3504
Logged by: Peter Koczan
Email address: [email protected: pjk...@gmail.com]
PostgreSQL version: 8.2.4
Operating system: CentOS 4.5 Linux (RHEL 4), kernel 2.6.9-55.ELsmp
Description: Some listening sessions never return from writing,
problems ensue
Details:
There is a problem where connections listening for asynchronous notifies
occasionally block for writing on ther server side and never finish,
resulting in connections that always have the status "notify interrupt".
Apparently, this causes no ill effects for the application that's listening
(i.e. it still updates somehow), but no data is written to the connection
when it should be. It also becomes a problem for restarting the server since
postgres cannot kill the connections when they're in that state. I either
have to explicitly kill the connections, kill the client apps, or reboot the
server. If I try to restart postgres, it kills all but the "notify
interrupt" connections, but it doesn't shut down so I can't restart it short
of rebooting.
Here are stack traces from listening sessions, the first is ok, the second
is blocked.
-----------------------------------------------------
OK:
[[email protected: r...@vero] ~]# ps axvw | grep 30728
30728 ? Ss 0:00 0 3265 42526 29240 0.7 postgres: koczan
csdb ator.cs.wisc.edu(38753) idle
[[email protected: r...@vero] ~]# gdb -p 30728
...Standard loading messages...
(gdb) bt
#0 0x003bc7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x001bac93 in __read_nocancel () from /lib/tls/libc.so.6
#2 0x00e81e2e in sock_read () from
/s/openssl-0.9.8e/lib/libcrypto.so.0.9.8e
#3 0x00000008 in ?? ()
#4 0x08c40068 in ?? ()
#5 0x00000005 in ?? ()
#6 0x00f160e8 in ?? () from /s/openssl-0.9.8e/lib/libcrypto.so.0.9.8e
#7 0x08c3a310 in ?? ()
#8 0x00000000 in ?? ()
(This stack trace is of the last 3 updates, and is farily representative of
what I've seen).
[[email protected: r...@vero] ~]# strace -p 30728
read(8, 0x8c40068, 5) = ? ERESTARTSYS (To be restarted)
--- SIGUSR2 (User defined signal 2) @ 0 (0) ---
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={1, 0}}, NULL) = 0
semop(1081358, 0xbfe20b9c, 1) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
semop(1081358, 0xbfe20b6c, 1) = 0
_llseek(6, 0, [6078464], SEEK_END) = 0
time(NULL) = 1185998905
_llseek(5, 6569984, [6569984], SEEK_SET) = 0
write(5, "^\320\1\0\1\0\0\0!\0\0\0\[email protected: 1...@d]\225\34\0\0\0\10\0\0\0(\372"..., 8192)
= 8192
fdatasync(5) = 0
semop(1048589, 0xbfe20adc, 1) = 0
semop(1048589, 0xbfe20b2c, 1) = 0
write(8, "\27\3\1\0 \221\363{!\235\355\317\223\260\253\tY\242\350"..., 90) =
90
sigreturn() = ? (mask now [])
read(8, 0x8c40068, 5) = ? ERESTARTSYS (To be restarted)
--- SIGUSR2 (User defined signal 2) @ 0 (0) ---
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={1, 0}}, NULL) = 0
semop(1081358, 0xbfe20b9c, 1) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
semop(1081358, 0xbfe20b6c, 1) = 0
_llseek(6, 0, [6078464], SEEK_END) = 0
time(NULL) = 1185998905
write(5, "^\320\1\0\1\0\0\0!\0\0\0\0`d\225H\0\0\0req\0 \272\301\10"...,
8192) = 8192
fdatasync(5) = 0
semop(1212434, 0xbfe20adc, 1) = 0
write(8, "\27\3\1\0 \'\6\235\323\2\33\321\216R\370\277i\304\217h"..., 90) =
90
sigreturn() = ? (mask now [])
read(8, 0x8c40068, 5) = ? ERESTARTSYS (To be restarted)
--- SIGUSR2 (User defined signal 2) @ 0 (0) ---
select(0, NULL, NULL, NULL, {0, 1000}) = 0 (Timeout)
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={1, 0}}, NULL) = 0
semop(1081358, 0xbfe20b9c, 1) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
_llseek(6, 0, [6078464], SEEK_END) = 0
time(NULL) = 1186000276
_llseek(5, 9453568, [9453568], SEEK_SET) = 0
write(5, "^\320\1\0\1\0\0\0!\0\0\0\0@\220\225r\4\0\0\0\0\0\0\0\0"..., 8192)
= 8192
fdatasync(5) = 0
semop(1081358, 0xbfe20adc, 1) = 0
write(8, "\27\3\1\0 \301\307_\375=\0032\243\212\215\362\3457\335"..., 90) =
90
sigreturn() = ? (mask now [])
read(8, 0x8c40068, 5) = ? ERESTARTSYS (To be restarted)
--- SIGUSR1 (User defined signal 1) @ 0 (0) ---
semop(1081358, 0xbfe20d2c, 1) = 0
semop(1081358, 0xbfe20d2c, 1) = 0
semop(1081358, 0xbfe20d2c, 1) = 0
sigreturn() = ? (mask now [])
read(8,
-----------------------------------------------------
Blocked process:
[[email protected: r...@vero] ~]# ps axvw | grep 19583
19583 ? Ss 0:02 0 3265 42518 29368 0.7 postgres: craft
csdb zim.cs.wisc.edu(32777) notify interrupt
[[email protected: r...@vero] ~]# gdb -p 19583
...Standard loading messages...
(gdb) bt
#0 0x003bc7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x001bad13 in __write_nocancel () from /lib/tls/libc.so.6
#2 0x00e81ec4 in sock_write () from
/s/openssl-0.9.8e/lib/libcrypto.so.0.9.8e
#3 0x00000008 in ?? ()
#4 0x08c4484a in ?? ()
#5 0x00000038 in ?? ()
#6 0x00000030 in ?? ()
#7 0x00f160e8 in ?? () from /s/openssl-0.9.8e/lib/libcrypto.so.0.9.8e
#8 0x08c3a7f0 in ?? ()
#9 0x00000000 in ?? ()
(Stack trace from the same amount of time, same 3 updates)
[[email protected: r...@vero] ~]# strace -p 19583
Process 19583 attached - interrupt to quit
write(8, "\224\337\252\27\3\1\0000\247W\250\2-\307;\204w\276\242"..., 56) =
? ERESTARTSYS (To be restarted)
--- SIGUSR1 (User defined signal 1) @ 0 (0) ---
sigreturn() = ? (mask now [USR2])
write(8, "\224\337\252\27\3\1\0000\247W\250\2-\307;\204w\276\242"..., 56
From my best guess, looks like something's weird with semop, but I don't
know.
Note: I'm compiling from source with PAM, krb5 (1.5.3), and openssl
(0.9.8e).
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
23 Replies
|
|
|
[BUGS] BUG #3548: When quickly switching between databases the server lags behind
By Daniel Heyder at Aug 17, 2007, 4:29 pm UTC
The following bug has been logged online: Bug reference: 3548 Logged by: Daniel Heyder Email address: Daniel.Heyder@comsoft.de PostgreSQL version: 8.2.4 Operating system: Linux (Red Hat EL4 Update 4 + PostgreSQL 8.2.4 update + compat libraries) Description: When quickly switching between databases... More...
The following bug has been logged online:
Bug reference: 3548
Logged by: Daniel Heyder
Email address: [email protected: Daniel.H...@comsoft.de]
PostgreSQL version: 8.2.4
Operating system: Linux (Red Hat EL4 Update 4 + PostgreSQL 8.2.4 update +
compat libraries)
Description: When quickly switching between databases the server lags
behind
Details:
Hi,
when I do quick PQconnectdb give the connection something to do PQfinish the
connection and PQconnectdb to another database the database server does not
keep up, neither does PQconnectdb or PQfinish block until the work is
complete. This is annoying when I want to delete the still working database.
(Causes an error as it is still in use.)
Here some code which demonstrates the problem (make sure it is the only
process accessing the database):
#include <libpq-fe.h>
#include <string.h>
int main()
{
char *pq_db;
char *tb_db;
PGconn *conn;
PGresult *res;
for (int x = 0; x < 2000; x++)
{
conn = PQconnectdb("host=127.0.0.1 dbname=postgres port=5432");
pq_db = PQdb(conn);
res = PQexec(conn, "SELECT * FROM pg_catalog.pg_stat_activity ORDER BY
usename, procpid;");
tb_db = PQgetvalue(res, 0, 1);
if (strcmp(pq_db, tb_db) != 0)
{
fprintf(stderr, "********* ERROR WRONG DATABASE OPEN (pq=%s, tb=%s)
**********\n", pq_db, tb_db);
return 1;
}
PQclear(res);
PQexec(conn, "CREATE TABLE x1 (x integer PRIMARY KEY, y integer,z
timestamp without time zone,u timestamp without time zone);");
PQexec(conn, "CREATE TABLE x2 (x integer PRIMARY KEY, y integer,z
timestamp without time zone,u timestamp without time zone);");
PQexec(conn, "CREATE TABLE x3 (x integer PRIMARY KEY, y integer,z
timestamp without time zone,u timestamp without time zone);");
PQexec(conn, "CREATE TABLE x4 (x integer PRIMARY KEY, y integer,z
timestamp without time zone,u timestamp without time zone);");
PQexec(conn, "CREATE TABLE x5 (x integer PRIMARY KEY, y integer,z
timestamp without time zone,u timestamp without time zone);");
PQexec(conn, "CREATE TABLE x6 (x integer PRIMARY KEY, y integer,z
timestamp without time zone,u timestamp without time zone);");
PQexec(conn, "CREATE TABLE x7 (x integer PRIMARY KEY, y integer,z
timestamp without time zone,u timestamp without time zone);");
PQexec(conn, "CREATE TABLE x8 (x integer PRIMARY KEY, y integer,z
timestamp without time zone,u timestamp without time zone);");
PQexec(conn, "CREATE TABLE x9 (x integer PRIMARY KEY, y integer,z
timestamp without time zone,u timestamp without time zone);");
PQexec(conn, "DROP TABLE x1");
PQexec(conn, "DROP TABLE x2");
PQexec(conn, "DROP TABLE x3");
PQexec(conn, "DROP TABLE x4");
PQexec(conn, "DROP TABLE x5");
PQexec(conn, "DROP TABLE x6");
PQexec(conn, "DROP TABLE x7");
PQexec(conn, "DROP TABLE x8");
PQexec(conn, "DROP TABLE x9");
PQfinish(conn);
conn = PQconnectdb("host=127.0.0.1 dbname=template1 user=csntool
password=comsoft port=5432");
pq_db = PQdb(conn);
res = PQexec(conn, "SELECT * FROM pg_catalog.pg_stat_activity ORDER BY
usename, procpid;");
tb_db = PQgetvalue(res, 0, 1);
if (strcmp(pq_db, tb_db) != 0)
{
fprintf(stderr, "********* ERROR WRONG DATABASE OPEN (pq=%s, tb=%s)
**********\n", pq_db, tb_db);
return 1;
}
PQclear(res);
PQfinish(conn);
}
return 0;
}
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
1 Reply
|
|
|
[BUGS] BUG #3547: getting error during salient Installation
By Abhay at Aug 17, 2007, 11:47 am UTC
The following bug has been logged online: Bug reference: 3547 Logged by: Abhay Email address: abhay@panaceatek.com PostgreSQL version: 8.2 Operating system: XP , window 2000 Description: getting error during salient Installation Details: We need salient installation of postgresql.We run the command... More...
The following bug has been logged online:
Bug reference: 3547
Logged by: Abhay
Email address: [email protected: a...@panaceatek.com]
PostgreSQL version: 8.2
Operating system: XP , window 2000
Description: getting error during salient Installation
Details:
We need salient installation of postgresql.We run the command
C:\>msiexec /l*v "C:\postgresql-8.2.4-1\log.txt" /i
C:\postgresql-8.2.4-1\postgr
esql-8.2-int.msi /qn INTERNALLAUNCH=1 SERVICEDOMAIN="%COMPUTERNAME%"
SERVICEACCO
UNT="postgre" SERVICEPASSWORD="secret123" SUPERPASSWORD="secret123";
then we got the error on log file
MSI (s) (CC:C0) [12:55:28:000]: Note: 1: 1708
MSI (s) (CC:C0) [12:55:28:000]: Note: 1: 2205 2: 3: Error
MSI (s) (CC:C0) [12:55:28:000]: Note: 1: 2228 2: 3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 1708
MSI (s) (CC:C0) [12:55:28:015]: Note: 1: 2205 2: 3: Error
MSI (s) (CC:C0) [12:55:28:015]: Note: 1: 2228 2: 3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 1709
MSI (s) (CC:C0) [12:55:28:015]: Product: PostgreSQL 8.2 -- Installation
failed.
MSI (s) (CC:C0) [12:55:28:015]: Cleaning up uninstalled install packages, if
any exist
what is doing wrong. please help ASAP.
0 Replies
|
|
|
[BUGS] some information
By rakesh kumar at Aug 17, 2007, 07:39 am UTC
how to connect postgresql database with perl Please if server ip:192.168.0.1 server name=abcd we using Slackware 10.2 & kernel 2.6.17 which suport postgresql version rakesh Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.... More...
how to connect postgresql database with perl
Please if server ip:192.168.0.1
server name=abcd
we using Slackware 10.2 & kernel 2.6.17
which suport postgresql version
rakesh
---------------------------------
Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
1 Reply
|
|
|
[BUGS] BUG #3542: Dropped and recreated columns have problems with NOT NULL contraints
By Jens-Wolfhard Schicke at Aug 16, 2007, 3:02 pm UTC
The following bug has been logged online: Bug reference: 3542 Logged by: Jens Schicke Email address: j.schicke@asco.de PostgreSQL version: 8.2.4 Operating system: GNU/Linux Description: Dropped and recreated columns have problems with NOT NULL contraints Details: pizza_de=# alter table store_flags... More...
The following bug has been logged online:
Bug reference: 3542
Logged by: Jens Schicke
Email address: [email protected: j.sc...@asco.de]
PostgreSQL version: 8.2.4
Operating system: GNU/Linux
Description: Dropped and recreated columns have problems with NOT
NULL contraints
Details:
pizza_de=# alter table store_flags add column flag integer;
ALTER TABLE
pizza_de=# alter table store_flags drop column flag;
ALTER TABLE
pizza_de=# alter table store_flags add column flag integer not null;
ERROR: column "flag" contains null values
pizza_de=# alter table store_flags drop column flag;
ERROR: column "flag" of relation "store_flags" does not exist
pizza_de=# alter table store_flags add column flag integer not null;
ERROR: column "flag" contains null values
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
2 Replies
|
|
|
[BUGS] BUG #3543: ARRAY(SELECT ...) contruct yields NULL without rows
By Jens-Wolfhard Schicke at Aug 16, 2007, 2:09 pm UTC
The following bug has been logged online: Bug reference: 3543 Logged by: Jens Schicke Email address: j.schicke@asco.de PostgreSQL version: 8.2.4 Operating system: GNU/Linux Description: ARRAY(SELECT ...) contruct yields NULL without rows Details: SELECT ARRAY(SELECT 1 WHERE 1 = 0) IS NULL; -- true... More...
The following bug has been logged online:
Bug reference: 3543
Logged by: Jens Schicke
Email address: [email protected: j.sc...@asco.de]
PostgreSQL version: 8.2.4
Operating system: GNU/Linux
Description: ARRAY(SELECT ...) contruct yields NULL without rows
Details:
SELECT ARRAY(SELECT 1 WHERE 1 = 0) IS NULL; -- true
this leads imho to inconsistencies later, if tests with = ANY or similar are
done.
1 Reply
|
|
|
[BUGS] BUG #3539: tsearch2 broken on Intel Macs running Leopard
By Erik R. at Aug 16, 2007, 06:09 am UTC
The following bug has been logged online: Bug reference: 3539 Logged by: Erik R. Email address: erik@mage.net PostgreSQL version: 8.2.4 Operating system: Mac OS X 10.5 (9A499) Description: tsearch2 broken on Intel Macs running Leopard Details: Any tsearch query results in the following error... More...
The following bug has been logged online:
Bug reference: 3539
Logged by: Erik R.
Email address: [email protected: e...@mage.net]
PostgreSQL version: 8.2.4
Operating system: Mac OS X 10.5 (9A499)
Description: tsearch2 broken on Intel Macs running Leopard
Details:
Any tsearch query results in the following error message:
mydb=# select * from product_search('test');
ERROR: could not find tsearch config by locale
CONTEXT: SQL function "product_search" statement 1
Same thing on 8.2.3. The same database works fine on a PPC Mac running the
same Leopard build as well as various flavors of Linux.
I wish I had more information to give you.
Cheers,
Erik
1 Reply
|
|
|
[BUGS] BUG #3541: typo - minor importance
By Leoj at Aug 15, 2007, 7:01 pm UTC
The following bug has been logged online: Bug reference: 3541 Logged by: Leoj Email address: a.rice13@gmail.com PostgreSQL version: 8 Operating system: win32 Description: typo - minor importance Details: step 12 on http://pginstaller.projects.postgresql.org has a typo: ~quote: Finished Installation... More...
The following bug has been logged online:
Bug reference: 3541
Logged by: Leoj
Email address: [email protected: a.r...@gmail.com]
PostgreSQL version: 8
Operating system: win32
Description: typo - minor importance
Details:
step 12 on http://pginstaller.projects.postgresql.org has a typo:
~quote:
Finished
Installation is complete. You >>>>acn<<<< now go ahead and test your
installation and subscribe to the pgsql-announce mailing list to keep up to
date.
If you need to add or remove a feature from PostgreSQL, use the Add/remove
programs feature in the Control Panel.
~
It should say "can" not "acn"
-hope this helps you guys sound more 1337 =)
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
1 Reply
|
|
|
[BUGS] BUG #3540: "REVOKE CREATE ON SCHEMA" public doesn't work
By Richard Rowell at Aug 15, 2007, 5:44 pm UTC
The following bug has been logged online: Bug reference: 3540 Logged by: Richard Rowell Email address: richard.rowell@gmail.com PostgreSQL version: 8.2 Operating system: Linux Description: "REVOKE CREATE ON SCHEMA" public doesn't work Details: richard@meowth:~/download$ createdb perm_test CREATE... More...
The following bug has been logged online:
Bug reference: 3540
Logged by: Richard Rowell
Email address: [email protected: richard.r...@gmail.com]
PostgreSQL version: 8.2
Operating system: Linux
Description: "REVOKE CREATE ON SCHEMA" public doesn't work
Details:
richard@meowth:~/download$ createdb perm_test
CREATE DATABASE
richard@meowth:~/download$ psql -U postgres perm_test
Welcome to psql 8.2.4, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
perm_test=> create schema foo;
CREATE SCHEMA
perm_test=# create role bar login;
CREATE ROLE
perm_test=> revoke create on schema foo from bar;
REVOKE
perm_test=# revoke create on schema public from bar;
REVOKE
perm_test=# \q
richard@meowth:~/download$ psql -U bar perm_test
Welcome to psql 8.2.4, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
perm_test=> create table foo.test (uid integer);
ERROR: permission denied for schema foo
perm_test=> create table test (uid integer);
CREATE TABLE
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
2 Replies
|
|
|
[BUGS] BUG #3537: Postgres odbc can only access public schema and any other schema does not work
By Govender, Maya at Aug 15, 2007, 08:32 am UTC
The following bug has been logged online: Bug reference: 3537 Logged by: maya Email address: maya.govender@ebucks.com PostgreSQL version: 08.02.0400 Operating system: solaris 9 64 bit Description: Postgres odbc can only access public schema and any other schema does not work Details: Hi , I have a... More...
The following bug has been logged online:
Bug reference: 3537
Logged by: maya
Email address: [email protected: maya.gov...@ebucks.com]
PostgreSQL version: 08.02.0400
Operating system: solaris 9 64 bit
Description: Postgres odbc can only access public schema and any
other schema does not work
Details:
Hi ,
I have a solaris 9 64 bit server with sas installed.I have unix odbc 2.2
installed and psqlodbc08.02.0400 installed.i can access only the public
schema and any other schema i cannot.I am test from the sas application ,
see comments from SAS
SAS query the odbc driver regarding Schema usage and the PostgreSQL driver
comes back basically saying "no schema usage". Therefore tables are not
prefix'ed with the schema.
ODBC: ENTER SQLGetInfo
0x000000000033e530
91 <SQL_SCHEMA_USAGE>
0x0000000078024528
4
0x000000007307c0fe
ODBC: EXIT SQLGetInfo with return code 0 (SQL_SUCCESS)
0x000000000033e530
91 <SQL_SCHEMA_USAGE>
0x000000007307bf4c (0) <> <---- This is the information
returned from the PostgreSQL driver - no schema usage
4
0x000000007307c0fe (4)
This is what the driver should return (exmple with oracle's odbc driver):
ODBC: EXIT SQLGetInfo with return code 0 (SQL_SUCCESS)
0x049a1348
91 <SQL_SCHEMA_USAGE>
0x0495f028 (31) <SQL_SU_DML_STATEMENTS |
SQL_SU_PROCEDURE_INVOCATION | SQL_SU_TABLE_DEFINITION |
SQL_SU_INDEX_DEFINITION
| SQL_SU_PRIVILEGE_DEFINITION>
4
0x0495f2be (4)
I suggest that they contact the ODBC driver vendor with the issue. Maybe
there is an option to turn on the schema usage within the driver
configuration."
TX
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
0 Replies
|
|
 | |
