Re: [BUGS] [PORTS] Bug Report with Postgres 7.4 on AIX 5.3
Hi,
We opened a call to IBM also, but until now we didn't receive anything (see
the attached mail).
In order to take into account the RFC 3943, we find a way to fixed the
problem by modifying the file socket.h :
#define _SS_MAXSIZE 128 /* Implementation specific max size */
SHOULD BE REPLACED BY
#define _SS_MAXSIZE (sizeof(struct sockaddr_un))/* Implementation
specific max size */
With this modification, Postgres 7.4 run on AIX5.3.
This is really an AIX problem.
An other's proposal done by Bull (our provider of the AIX system) is the
following :
Reduce the size of the field sun_path in the structure sockaddr_un (un.h)
and not increase the size of the structure sockaddr_storage.
charsun_path[PATH_MAX]; /* changed from 104 to PATH_MAX to support
long user names */
SHOULD BE REPLACED BY
charsun_path[104]; /* changed from 104 to PATH_MAX to support long
user names */
With this modification, Postgres 7.4 run also on AIX5.3.
Both modification can have an impact on the AIX5.3 OS and IBM should be
confirm if a fixed is needed for that problem ?
Kind Regards,
Vincent Vanwynsberghe
> -Original Message-
> From: Mohan, Ross [mailto:[EMAIL PROTECTED]
> Sent: jeudi 19 mai 2005 2:23
> To: [EMAIL PROTECTED]
> Subject: RE: [PORTS] Bug Report with Postgres 7.4 on AIX 5.3
>
>
> Vincent,
>
> 1) I am having the exact same problem: I cannot even do a
> CREATEDB in 8.0.2 on AIX5.3
>
> 2) You sent your mail to the PG lists, but not to IBM, possibly?
>
> 3) If you think it will help, I can call support as well.
>
>
>
> If you get ANY word on this, whether a fix, a tweak, or a
> workaround, please Please PLEASE
> post to the list rapidly.
>
> We're dead in the water on this and the IT environment around
> here is such that if I can't
> get PG working on AIX, it'll be marked for death. And I really
> wanted to start
> using PG around here.
>
> Thanks!
>
>
> -- Ross Mohan
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Vincent
> Vanwynsberghe
> Sent: Tuesday, May 10, 2005 4:08 AM
> To: [EMAIL PROTECTED]; pgsql-bugs@postgresql.org
> Subject: [PORTS] Bug Report with Postgres 7.4 on AIX 5.3
>
>
> Dear Support,
>
> We try to install Postgres 7.4 on AIX 5.3 (IBM,9111-520).
> The compilation is good and we are able to start the postmaster.
> When we try to start the psql we got the following error :
> FATAL: unsupported frontend protocol 0.0: server supports 1.0 to 3.0
>
> We run the psql under the AIX debugger dbx and our conclusions
> are the following :
>
> In the file fe-connect.c we try to copy a area of 1025 in the
> conn->raddr.addr area but the size of that area is only 144.
> The result is a corruption of the pg_conn structure
>
> +1175 /* Remember
> current address
> for possible error msg */
> +1176 memcpy(&conn->raddr.addr,
> addr_cur->ai_addr,
> +1177
> addr_cur->ai_addrlen);
>
>
> The addr_cur->ai_addrlen is set with the sizeof(struct
> sockaddr_un) in the file ip.c.
>
> In the file libpq-int.h the structure pg_conn contains 2 fields SockAddr
> * PGconn stores all the state data associated with a single connection
> * to a backend.
> */
> struct pg_conn
> {
> ...
> SockAddrladdr; /* Local address */
> SockAddrraddr;
> ...
> }
>
> The structure SockAddr is defined in the file pqcomm.h
>
> typedef struct
> {
> struct sockaddr_storage addr;
> ACCEPT_TYPE_ARG3 salen;
> } SockAddr;
>
>
> On Our AIX 5.3 the sockaddr_un is defined in the file
> /usr/include/sys/un.h
>
> #if defined(COMPAT_43) && !defined(_KERNEL)
> struct sockaddr_un {
> ushort_tsun_family; /* AF_UNIX */
> charsun_path[PATH_MAX]; /* changed from 104 to PATH_MAX to
> support long user names */
> };
> #else
> struct sockaddr_un {
> uchar_t sun_len;/* sockaddr len including null */
> sa_family_t sun_family; /* AF_UNIX */
> charsun_path[PATH_MAX]; /* changed from 104 to PATH_MAX to
> support long user names */
> };
> #endif /* COMPAT_43 && !_KERNEL */
>
> PATH_MAX is defined in the file /usr/include/sys/limits.h
>
> #if _POSIX_C_SOURCE >= 200112L && !(defined _ALL_SOURCE) ||
> defined(_PATHMAX_HAS_NULL)
> #define PATH_MAX1024/* max number of bytes in a
> pathname.
>includes a terminating
> null */ #else
> #define PATH_MAX1023
> #endif
>
> In our platform the sizeof of struct sockaddr_un is 1025 and the
> sizeof of SockAddr is 144. In conclusion the instructions done in
> the function PQconnectPoll cause a memory overflow !!!
>
> +1175 /* Remember current address
> for possible error msg */
> +1176 memcpy(&conn->raddr.addr,
> addr_cur->ai_addr,
> +1177
> addr_cur->ai_addrle
[BUGS] BUG #1675: very slow work
The following bug has been logged online: Bug reference: 1675 Logged by: Dimitar Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.2 win32 Operating system: Windows Server 2003: Web Edition Description:very slow work Details: Posgre works slower on Wndows than on Linux. We worked previously with Posgre on Linux and it's over 100 times faster than Windows. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #1674: CREATE TABLE "name" (with double quotes) and resulting behavior
The following bug has been logged online: Bug reference: 1674 Logged by: Herman Bos Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4.7 Operating system: Ubuntu Linux 5.04 Description:CREATE TABLE "name" (with double quotes) and resulting behavior Details: for the create table in question: http://users.lichtsnel.nl/~spacey/school/vib/vib.sql entered into the database like this: psql -d vib -U vib < vib.sql results on my system vib=> \d List of relations Schema | Name | Type | Owner +--+---+--- public | SANCTIES | table | vib (1 row) vib=> select * from SANCTIES; ERROR: relation "sancties" does not exist vib=> \d SANCTIES Did not find any relation named "SANCTIES". After realizing that it occurred after putting the tablename between double qoutes. The same behavior happend with the column names. vib=> select * from "bedrag"; ERROR: relation "bedrag" does not exist vib=> select bedrag from sancties; ERROR: column "bedrag" does not exist vib=> select "bedrag" from sancties; ERROR: column "bedrag" does not exist vib=> select "BEDRAG" from sancties; BEDRAG (0 rows) I was wondering if this behavior is correct. According to my local postgresql poweruser its a bug. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] BUG #1671: Long interval string representation rejected
Tom Lane wrote: I'm too tired to think about this more tonight, but it seems like the basic point is that we can't just construct a list of pointers into (a copy of) the original input string. I think we _can_ do it that way, it's just a question of whether that is the best approach. I think the solution I outlined before would work fine: pass the length of the working buffer to ParseDateTime(), and reject the input only if the parsing process actually requires more working space than was provided. ParseDateTime() can easily skip whitespace without storing it in the temporary buffer -- and once we've done that, AFAIK we _can_ place an upper bound on the amount of working space that is needed (each field has a maximum length and there are a maximum number of fields). Or we could rewrite how we do parsing, which seems to be what you're suggesting. I agree the code could do with cleanup, although we will also need some kind of minimally-invasive fix for back branches. -Neil ---(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] [PORTS] Bug Report with Postgres 7.4 on AIX 5.3
Vincent,
1) I am having the exact same problem: I cannot even do a CREATEDB in 8.0.2 on
AIX5.3
2) You sent your mail to the PG lists, but not to IBM, possibly?
3) If you think it will help, I can call support as well.
If you get ANY word on this, whether a fix, a tweak, or a workaround, please
Please PLEASE
post to the list rapidly.
We're dead in the water on this and the IT environment around here is such that
if I can't
get PG working on AIX, it'll be marked for death. And I really wanted to start
using PG around here.
Thanks!
-- Ross Mohan
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vincent
Vanwynsberghe
Sent: Tuesday, May 10, 2005 4:08 AM
To: [EMAIL PROTECTED]; pgsql-bugs@postgresql.org
Subject: [PORTS] Bug Report with Postgres 7.4 on AIX 5.3
Dear Support,
We try to install Postgres 7.4 on AIX 5.3 (IBM,9111-520).
The compilation is good and we are able to start the postmaster. When we try to
start the psql we got the following error :
FATAL: unsupported frontend protocol 0.0: server supports 1.0 to 3.0
We run the psql under the AIX debugger dbx and our conclusions are the
following :
In the file fe-connect.c we try to copy a area of 1025 in the
conn->raddr.addr area but the size of that area is only 144.
The result is a corruption of the pg_conn structure
+1175 /* Remember current address
for possible error msg */
+1176 memcpy(&conn->raddr.addr,
addr_cur->ai_addr,
+1177
addr_cur->ai_addrlen);
The addr_cur->ai_addrlen is set with the sizeof(struct sockaddr_un) in the file
ip.c.
In the file libpq-int.h the structure pg_conn contains 2 fields SockAddr
* PGconn stores all the state data associated with a single connection
* to a backend.
*/
struct pg_conn
{
...
SockAddrladdr; /* Local address */
SockAddrraddr;
...
}
The structure SockAddr is defined in the file pqcomm.h
typedef struct
{
struct sockaddr_storage addr;
ACCEPT_TYPE_ARG3 salen;
} SockAddr;
On Our AIX 5.3 the sockaddr_un is defined in the file /usr/include/sys/un.h
#if defined(COMPAT_43) && !defined(_KERNEL)
struct sockaddr_un {
ushort_tsun_family; /* AF_UNIX */
charsun_path[PATH_MAX]; /* changed from 104 to PATH_MAX to
support long user names */
};
#else
struct sockaddr_un {
uchar_t sun_len;/* sockaddr len including null */
sa_family_t sun_family; /* AF_UNIX */
charsun_path[PATH_MAX]; /* changed from 104 to PATH_MAX to
support long user names */
};
#endif /* COMPAT_43 && !_KERNEL */
PATH_MAX is defined in the file /usr/include/sys/limits.h
#if _POSIX_C_SOURCE >= 200112L && !(defined _ALL_SOURCE) ||
defined(_PATHMAX_HAS_NULL)
#define PATH_MAX1024/* max number of bytes in a
pathname.
includes a terminating null */ #else
#define PATH_MAX1023
#endif
In our platform the sizeof of struct sockaddr_un is 1025 and the sizeof of
SockAddr is 144. In conclusion the instructions done in the function
PQconnectPoll cause a memory overflow !!!
+1175 /* Remember current address
for possible error msg */
+1176 memcpy(&conn->raddr.addr,
addr_cur->ai_addr,
+1177
addr_cur->ai_addrlen);
Are you aware about this problem ?
Could you give us a way to solve the problem ?
Kind Regards,
Vincent Vanwynsberghe
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] BUG #1676: Statment order in rules
The following bug has been logged online: Bug reference: 1676 Logged by: Olleg Samoylov Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4.7 Operating system: on x86_64-pc-linux-gnu, compiled by GCC x86_64-linux-gcc (GCC) 3.3.5 (Debian 1:3.3.5-12) Description:Statment order in rules Details: -- Here example for delete rule, but for update rule bug arised also. -- This is simplified example from working database. -- create tables -- counter create table c (c integer); insert into c values (0); -- private table create table a (a integer); -- public view create view v as select a from a; -- create worked rules, for example create rule insert_last as on insert to v do instead (update c set c=c+1;insert into a values (new.a)); create rule delete_last as on delete to v do instead (update c set c=c-1;delete from a where a=old.a); insert into v values (0); select * from a; -- 1 row select * from c; -- 1 delete from v where a=0; select * from a; -- 0 rows select * from c; -- 0, Okey -- now change order of statment drop rule insert_last on v; drop rule delete_last on v; create rule insert_first as on insert to v do instead (insert into a values (new.a);update c set c=c+1); create rule delete_first as on delete to v do instead (delete from a where a=old.a;update c set c=c-1); insert into v values (0); select * from a; -- 1 row select * from c; -- 1, Ok delete from v where a=0; select * from a; -- 0 row, as expected :-) select * from c; -- 1, this is incorrect ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] BUG #1673: Can not run initdb on install and no log
The following bug has been logged online: Bug reference: 1673 Logged by: Iavor Raytchev Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3 Operating system: Windows XP Professional Description:Can not run initdb on install and no log Details: C: is on FAT32 so I tried to install on E: which is NTFS. Pop up at the end of install says 'can not run initdb - see ...log for details' but the log is not there (even before I press the OK). ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] BUG #1674: CREATE TABLE "name" (with double quotes) and
Herman Bos wrote: vib=> select * from "bedrag"; ERROR: relation "bedrag" does not exist Naturally: there is no such table, regardless of case. vib=> select "BEDRAG" from sancties; BEDRAG (0 rows) Not with the SQL you provided: neilc=# select "BEDRAG" from sancties; ERROR: relation "sancties" does not exist I was wondering if this behavior is correct. This behavior is intended, although it is true some people find it confusing. The logic is: - identifiers specified without double-quotes are folded to lower case - identifiers specified with double-quotes are not case folded So your DDL creates a table called SANCTIES since the table name is double-quoted, whereas "SELECT * FROM SANCTIES" is actually looking for a table called "sancties". See here for more info: http://www.postgresql.org/docs/8.0/interactive/sql-syntax.html#SQL-SYNTAX-IDENTIFIERS -Neil ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] [PORTS] Bug Report with Postgres 7.4 on AIX 5.3
Vincent,
Thanks for this, I'll run this by our SAs. Should
be funny to watch their reaction.
Meanwhile, I've requested that we file a bug w/IBM
as well.
Thanks again for sharing your information!
-- Ross Mohan
-Original Message-
From: Vincent Vanwynsberghe [mailto:[EMAIL PROTECTED]
Sent: Thu 5/19/2005 8:49 AM
To: [EMAIL PROTECTED]; pgsql-bugs@postgresql.org
Cc: Mohan, Ross
Subject:RE: [PORTS] Bug Report with Postgres 7.4 on AIX 5.3
Hi,
We opened a call to IBM also, but until now we didn't receive anything (see
the attached mail).
In order to take into account the RFC 3943, we find a way to fixed the
problem by modifying the file socket.h :
#define _SS_MAXSIZE 128 /* Implementation specific max size */
SHOULD BE REPLACED BY
#define _SS_MAXSIZE (sizeof(struct sockaddr_un))/* Implementation
specific max size */
With this modification, Postgres 7.4 run on AIX5.3.
This is really an AIX problem.
An other's proposal done by Bull (our provider of the AIX system) is the
following :
Reduce the size of the field sun_path in the structure sockaddr_un (un.h)
and not increase the size of the structure sockaddr_storage.
charsun_path[PATH_MAX]; /* changed from 104 to PATH_MAX to support
long user names */
SHOULD BE REPLACED BY
charsun_path[104]; /* changed from 104 to PATH_MAX to support long
user names */
With this modification, Postgres 7.4 run also on AIX5.3.
Both modification can have an impact on the AIX5.3 OS and IBM should be
confirm if a fixed is needed for that problem ?
Kind Regards,
Vincent Vanwynsberghe
> -Original Message-
> From: Mohan, Ross [mailto:[EMAIL PROTECTED]
> Sent: jeudi 19 mai 2005 2:23
> To: [EMAIL PROTECTED]
> Subject: RE: [PORTS] Bug Report with Postgres 7.4 on AIX 5.3
>
>
> Vincent,
>
> 1) I am having the exact same problem: I cannot even do a
> CREATEDB in 8.0.2 on AIX5.3
>
> 2) You sent your mail to the PG lists, but not to IBM, possibly?
>
> 3) If you think it will help, I can call support as well.
>
>
>
> If you get ANY word on this, whether a fix, a tweak, or a
> workaround, please Please PLEASE
> post to the list rapidly.
>
> We're dead in the water on this and the IT environment around
> here is such that if I can't
> get PG working on AIX, it'll be marked for death. And I really
> wanted to start
> using PG around here.
>
> Thanks!
>
>
> -- Ross Mohan
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Vincent
> Vanwynsberghe
> Sent: Tuesday, May 10, 2005 4:08 AM
> To: [EMAIL PROTECTED]; pgsql-bugs@postgresql.org
> Subject: [PORTS] Bug Report with Postgres 7.4 on AIX 5.3
>
>
> Dear Support,
>
> We try to install Postgres 7.4 on AIX 5.3 (IBM,9111-520).
> The compilation is good and we are able to start the postmaster.
> When we try to start the psql we got the following error :
> FATAL: unsupported frontend protocol 0.0: server supports 1.0 to 3.0
>
> We run the psql under the AIX debugger dbx and our conclusions
> are the following :
>
> In the file fe-connect.c we try to copy a area of 1025 in the
> conn->raddr.addr area but the size of that area is only 144.
> The result is a corruption of the pg_conn structure
>
> +1175 /* Remember
> current address
> for possible error msg */
> +1176 memcpy(&conn->raddr.addr,
> addr_cur->ai_addr,
> +1177
> addr_cur->ai_addrlen);
>
>
> The addr_cur->ai_addrlen is set with the sizeof(struct
> sockaddr_un) in the file ip.c.
>
> In the file libpq-int.h the structure pg_conn contains 2 fields SockAddr
> * PGconn stores all the state data associated with a single connection
> * to a backend.
> */
> struct pg_conn
> {
> ...
> SockAddrladdr; /* Local address */
> SockAddrraddr;
> ...
> }
>
> The structure SockAddr is defined in the file pqcomm.h
>
> typedef struct
> {
> struct sockaddr_storage addr;
> ACCEPT_TYPE_ARG3 salen;
> } SockAddr;
>
>
> On Our AIX 5.3 the sockaddr_un is defined in the file
> /usr/include/sys/un.h
>
> #if defined(COMPAT_43) && !defined(_KERNEL)
> struct sockaddr_un {
> ushort_tsun_family; /* AF_UNIX */
> charsun_path[PATH_MAX]; /* changed from 104 to PATH_MAX to
> support long user names */
> };
> #else
> struct sockaddr_un {
> uchar_t sun_len;/* sockaddr len including null */
> sa_family_t sun_family; /* AF_UNIX */
> charsun_path[PATH_MAX]; /* changed from 104 to PATH_MAX to
> support long user names */
> };
> #endif /* COMPAT_43 && !_KERNEL */
>
> PATH_MAX is defined in the file /usr/include/sys/limits.h
>
> #if _POSIX_C_SOURCE >= 200112L && !(defined _ALL_SOURCE) ||
> defined(_PATHMAX_HAS_NULL)
> #define PATH_MAX1024/* max number of bytes in a
> pathname.
>includes a terminating
> null */ #
Re: [BUGS] BUG #1676: Statment order in rules
"Olleg Samoylov" <[EMAIL PROTECTED]> writes: > create rule delete_first as on delete to v do instead (delete from a where > a=old.a;update c set c=c-1); > delete from v where a=0; > select * from a; > -- 0 row, as expected :-) > select * from c; > -- 1, this is incorrect This isn't a bug. The DELETE causes the a=0 row to disappear from the view, so the subsequent statement (which is implicitly conditional on there being an a=0 row) doesn't do anything. If it did do something, then a "delete from v" that didn't delete any rows would still decrement c, which is not what you want, eh? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #1675: very slow work
On Thu, May 19, 2005 at 01:27:17PM +0100, Dimitar wrote: > > Posgre works slower on Wndows than on Linux. We worked previously with > Posgre on Linux and it's over 100 times faster than Windows. Could you provide more information about what you're doing? Are you running comparable queries against a comparable data set on comparable hardware with a comparable database configuration? Have you vacuumed and analyzed the database? Could you post the EXPLAIN ANALYZE output from an example query that's 100 times faster on Linux? If you still have a Linux system then please post the EXPLAIN ANALYZE output from both systems so we can see the difference. This thread might be more appropriate in pgsql-performance until there's more evidence that the performance difference is indeed a PostgreSQL bug and that other possibilities have been investigated and ruled out. BTW, it's "PostgreSQL" or "Postgres", not "Posgre". -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
