[BUGS] PGCLUSTER -- ERROR

[Alex Lima Silva]

Hi,

I´m trying to install pgcluster 1.7 on Aix 5.3 and I´m having problems, when I 
run "./configure --enable-thread-safety" I receive the msg bellow and when a 
try to do make make install I got a error about libpg

Could someone help me please ?

 

Thanks in advance

 

 

 

checking for sys/sem.h... yes

checking sys/socket.h usability... no

checking sys/socket.h presence... yes

configure: WARNING: sys/socket.h: present but cannot be compiled

configure: WARNING: sys/socket.h: check for missing prerequisite headers?

configure: WARNING: sys/socket.h: see the Autoconf documentation

configure: WARNING: sys/socket.h: section "Present But Cannot Be Compiled"

configure: WARNING: sys/socket.h: proceeding with the preprocessor's result

configure: WARNING: sys/socket.h: in the future, the compiler will take 
precedence

configure: WARNING: ##  ##

configure: WARNING: ## Report this to pgsql-bugs@postgresql.org ##

configure: WARNING: ##  ##

checking for sys/socket.h... yes

checking sys/shm.h usability... yes

checking sys/shm.h presence... yes

checking for sys/shm.h... yes

checking sys/time.h usability... yes

checking sys/time.h presence... yes

checking for sys/time.h... yes

checking sys/un.h usability... yes

 

 

 

 

gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline 
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing 
-DUSE_REPLICATION -DPRINT_DEBUG -pthread -L../../src/port  -L/usr/lib/threads  
-Wl,-blibpath:/pgcluster17/lib:/usr/lib:/lib access/SUBSYS.o bootstrap/SUBSYS.o 
catalog/SUBSYS.o parser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o 
lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o 
port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o 
storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o ../../src/timezone/SUBSYS.o  
../../src/port/libpgport_srv.a -Wl,-bE:../../src/backend/postgres.imp -lld -lm 
-o postgres

ld: 0711-317 ERROR: Undefined symbol: .PQsetdbLogin

ld: 0711-317 ERROR: Undefined symbol: .PQstatus

ld: 0711-317 ERROR: Undefined symbol: .PQfinish

ld: 0711-317 ERROR: Undefined symbol: .PQexec

ld: 0711-317 ERROR: Undefined symbol: .PQresultStatus

ld: 0711-317 ERROR: Undefined symbol: .PQclear

ld: 0711-317 ERROR: Undefined symbol: .PQntuples

ld: 0711-317 ERROR: Undefined symbol: .PQgetvalue

ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.

collect2: ld returned 8 exit status

gmake[2]: *** [postgres] Error 1

 

[BUGS] BUG #3288: Select command giving error

[Srinivas]

The following bug has been logged online:

Bug reference:  3288
Logged by:  Srinivas
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.2
Operating system:   Win XP
Description:Select command giving error
Details: 

Hi, We are using PGOleDB drivers with ASP.Net C# code. We could connect and
give the Insert, Update and Delete commands successfully. When we give a
Select command, it is giving the following error. 
'PostgreSQL' failed with no error message available, result code:
-2147221163(0x80040155).

Can anyone please help.

regards
Srinivas

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

[BUGS] BUG #3287: I cann't instal postgres sql in windows vista

[Siva]

The following bug has been logged online:

Bug reference:  3287
Logged by:  Siva
Email address:  [EMAIL PROTECTED]
PostgreSQL version: postgresql-8.1
Operating system:   Windows vista
Description:I cann't instal postgres sql in windows vista
Details: 

Dear All,
I cann't instal postgres sql in windows vista.How i can instal postgres
sql in windows vista.Any body know my queries pls reply me.Advance thanks
for u.

With Kindly Regards
Siva

---(end of broadcast)---
TIP 1: 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] BUG #3286: psqlodbc not able to connect

[Aravind C]

The following bug has been logged online:

Bug reference:  3286
Logged by:  Aravind C
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.2.3
Operating system:   Windows XP on VMWare
Description:psqlodbc not able to connect
Details: 

My Host os is Windows XP with Postgresql 8.2.3 tried to connect from Windows
XP on VMWare using psqlodbc 8.2.3

While trying to create a odbc and test the connection, i got a blank
messagebox with exclamation symbol. The connection was not going through.

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

[BUGS] BUG #3289: SIN(PI()) expected to return 0, but returns garbage

[Daniel Kastenholz]

The following bug has been logged online:

Bug reference:  3289
Logged by:  Daniel Kastenholz
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.1, 8.2.4
Operating system:   Linux, Windows
Description:SIN(PI()) expected to return 0, but returns garbage
Details: 

Trouble case:

Action:
Type in SELECT SIN(PI())

Expected output:
0

Actual output:
* Windows, using 8.2.4:
  garbage (-2.2..)

* Linux, using 8.1:
  garbage (1.22...)

--

Comments:
SIN(3.1414) and SIN(3.1417) come close to 0 and work on both platforms.
SIN(3.1415) and SIN(3.1416) produce the same garbage output as using PI() on
both platforms.

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [BUGS] BUG #3289: SIN(PI()) expected to return 0, but returns garbage

[Heikki Linnakangas]

Daniel Kastenholz wrote:

Type in SELECT SIN(PI())

Expected output:
0

Actual output:
* Windows, using 8.2.4:
  garbage (-2.2..)

* Linux, using 8.1:
  garbage (1.22...)

--

Comments:
SIN(3.1414) and SIN(3.1417) come close to 0 and work on both platforms.
SIN(3.1415) and SIN(3.1416) produce the same garbage output as using PI() on
both platforms.


You don't get 0 because the value of pi is just an approximation, and 
most likely the output of sin is not exact either. What you get is 
pretty darn close to 0, however. Apparently you didn't read the output 
carefully: it's in scientific notation. I'm getting


 1.22460635382238e-16

on my laptop, which means 1.22460635382238 * 10^(-16).

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

[BUGS] ON DELETE CASCADE with multiple paths

[Max Khon]

Hi!

Suppose the following schema:

create table foo(foo_id integer primary key);
create table bar(bar_id integer primary key, foo_id integer,
constraint bar_fk0 foreign key (foo_id) references foo(foo_id)
on delete cascade);
create table foobar(foobar_id serial primary key, foo_id integer, bar_id
integer);

alter table foobar add constraint foobar_fk1 foreign key (bar_id)
references bar(bar_id) on delete cascade;
alter table foobar add constraint foobar_fk0 foreign key (foo_id)
references bar(bar_id);

And data:

insert into foo(foo_id) values(1);
insert into bar(bar_id, foo_id) values(1, 1);
insert into foobar(foo_id, bar_id) values(1, 1);

The following statement does work:

delete from foo;

All is ok. The row in foobar is deleted because of ON DELETE CASCADE fk
constraints bar_fk0 and foobar_fk1.

After altering the schema:

alter table foobar drop constraint foobar_fk0;
alter table foobar drop constraint foobar_fk1;

alter table foobar add constraint foobar_fk0 foreign key (foo_id)
references bar(bar_id);
alter table foobar add constraint foobar_fk1 foreign key (bar_id)
references bar(bar_id) on delete cascade;

(note that constraints are now added in different order)

and the same data:

insert into foo(foo_id) values(1);
insert into bar(bar_id, foo_id) values(1, 1);
insert into foobar(foo_id, bar_id) values(1, 1);

"delete from foo" fails:

ERROR: update or delete on table "bar" violates foreign key constraint
"foobar_fk0" on table "foobar"
SQL state: 23503
Detail: Key (bar_id)=(1) is still referenced from table "foobar".
Context: SQL statement "DELETE FROM ONLY "public"."bar" WHERE "foo_id" = $1"

PostgreSQL version: any (I tested on 8.2.4 for Win32 and 8.1.3 for Linux)

-- 
Max Khon
PEM Platform Team Leader
SWsoft, Inc.
E-mail: [EMAIL PROTECTED]
Web Site: http://swsoft.com/

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [BUGS] ON DELETE CASCADE with multiple paths

[Tom Lane]

Max Khon <[EMAIL PROTECTED]> writes:
> "delete from foo" fails:

> ERROR: update or delete on table "bar" violates foreign key constraint
> "foobar_fk0" on table "foobar"
> SQL state: 23503
> Detail: Key (bar_id)=(1) is still referenced from table "foobar".
> Context: SQL statement "DELETE FROM ONLY "public"."bar" WHERE "foo_id" = $1"

I see no bug here.  There is no guarantee about the order in which
constraints are applied.

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [BUGS] strange problem with ip6

[Andrew Sullivan]

On Mon, May 14, 2007 at 08:32:21PM -0600, Brian Hirt wrote:
> I have postgresql installed on a mac, and I'm connecting from another  
> mac on the network using ip6.   When I  try to select out of  
> pg_stat_activity i get this error.  I suspect the %en0 has something  
> to do with the problem, but I'm no IP6 expert.

That would indeed be a problem.  "%" is not a valid character in an
IPv6 text representation of the address (see RFC 4291,
).
Whether this is a bug for postgres seems to depend on whether that
reading is coming from the OS or postgres itself.  (I don't know the
answer to that.)

A 

-- 
Andrew Sullivan  | [EMAIL PROTECTED]
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism. 
--Brad Holland

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [BUGS] strange problem with ip6

[Tom Lane]

Andrew Sullivan <[EMAIL PROTECTED]> writes:
> On Mon, May 14, 2007 at 08:32:21PM -0600, Brian Hirt wrote:
>> I have postgresql installed on a mac, and I'm connecting from another  
>> mac on the network using ip6.   When I  try to select out of  
>> pg_stat_activity i get this error.  I suspect the %en0 has something  
>> to do with the problem, but I'm no IP6 expert.

> That would indeed be a problem.  "%" is not a valid character in an
> IPv6 text representation of the address (see RFC 4291,
> ).
> Whether this is a bug for postgres seems to depend on whether that
> reading is coming from the OS or postgres itself.

I enabled IPv6 on my laptop (maybe I did it wrong, dunno) and noted that
%en1 and %lo0 and similar notations were appended to some but not all of
the IPv6 addresses output by "netstat -r -n".  Furthermore it seemed
that adding or not adding these notations to IPv6 addresses given to
psql's -h switch affected whether I could connect or not.  I didn't see
a case where the %-thingy showed up in getnameinfo() output within
Postgres, as is apparently happening for Brian; but it sure looked like
it was happening to netstat.  So Apple is doing something mighty
nonstandard here :-(.  I ran out of time/interest to probe deeper.

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [BUGS] BUG #3266: SSL broken pipes kill the machine and fill the disk

[Bruce Momjian]

I didn't see any comment on this.  Seems like a problem.

---

Peter Koczan wrote:
> 
> The following bug has been logged online:
> 
> Bug reference:  3266
> Logged by:  Peter Koczan
> Email address:  [EMAIL PROTECTED]
> PostgreSQL version: 8.2.4
> Operating system:   CentOS Linux 4.4 (RHEL 4) running on Pentium 4
> Description:SSL broken pipes kill the machine and fill the disk
> Details: 
> 
> If a connection using SSL is terminated on the client side before a query
> completes, postgres keeps trying to write to the broken connection, shooting
> CPU and load very high and filling the postgres syslog (I have that pointed
> to /var/log/pglog) with ~2000 of the following messages per second.
> 
> May 10 14:45:01 mitchell postgres[10340]: [15729-1] LOG:  SSL SYSCALL error:
> Broken pipe
> 
> This quickly fills up the /var partition on the server.
> 
> To replicate the problem:
> 1. Connect to an running server using an SSL connection. Using psql is
> fine.
> 2. Begin a query on any table. For full effect the query should be expensive
> and large.
> 3. Kill psql *on the client side* BEFORE the query finishes (don't do
> anything to the server side connection).
> 4. 'tail -f' wherever the postgres server output and error is going to.
> 5. Wait a few seconds while the server gets all of its data.
> 6. See thousands of error messages fill up your terminal on the server.
> 
> This has also happened when people stop web browsers in the middle of
> serving up a postgresql-driven web page, but this is harder to replicate.
> 
> This usually terminates, but after 3 hours for a query that usually takes 20
> seconds. During this time, the server is slow to the point of unusable.
> 
> ---(end of broadcast)---
> TIP 6: explain analyze is your friend

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [BUGS] ON DELETE CASCADE with multiple paths

[Stephan Szabo]

On Thu, 17 May 2007, Tom Lane wrote:

> Max Khon <[EMAIL PROTECTED]> writes:
> > "delete from foo" fails:
>
> > ERROR: update or delete on table "bar" violates foreign key constraint
> > "foobar_fk0" on table "foobar"
> > SQL state: 23503
> > Detail: Key (bar_id)=(1) is still referenced from table "foobar".
> > Context: SQL statement "DELETE FROM ONLY "public"."bar" WHERE "foo_id" = $1"
>
> I see no bug here.  There is no guarantee about the order in which
> constraints are applied.

Except that SQL92 at least does seem to say in 11.8 that "All rows that
are marked for deletion are effectively deleted at the end of the
SQL-statement, prior to the checking of any integrity constraints." I
think that likely makes our behavior wrong, but I'm not really sure how to
get there from what we have now.

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [BUGS] strange problem with ip6

[Andrew Sullivan]

On Thu, May 17, 2007 at 06:42:39PM +0200, Christian Kratzer wrote:
> of a specific interface. This is why bsd based oprating systems append 
> %ifname to the address so that they know which Interface this address 

Oh, I forgot about that wart in RFC4007.  Thanks for the cluestick.

> There is propbaly not much point in using link local addreses for postgres.

I think that's not quite right.  For instance, JDBC can't use UNIX
domain sockets last I checked, and I can imagine using it in a
disconnected context where you'd want to emulate multiple connection
points.  Link local addresses would be perfect for this.  So I think
it might be a bug, because Postgres isn't accepting the address
specification for scoped addresses.  (In the local 8.1.x version I
have installed here, the inet type doesn't accept it either.) Now
that I re-read it, RFC4007 seems to be pretty clear that the scope
info is a necessary part of the addressing, so I don't think it can
be thrown away before looking at the address.

A

-- 
Andrew Sullivan  | [EMAIL PROTECTED]
I remember when computers were frustrating because they *did* exactly what 
you told them to.  That actually seems sort of quaint now.
--J.D. Baldwin

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [BUGS] strange problem with ip6

[Christian Kratzer]

Hi,

On Thu, 17 May 2007, Tom Lane wrote:


Andrew Sullivan <[EMAIL PROTECTED]> writes:

On Mon, May 14, 2007 at 08:32:21PM -0600, Brian Hirt wrote:

I have postgresql installed on a mac, and I'm connecting from another
mac on the network using ip6.   When I  try to select out of
pg_stat_activity i get this error.  I suspect the %en0 has something
to do with the problem, but I'm no IP6 expert.



That would indeed be a problem.  "%" is not a valid character in an
IPv6 text representation of the address (see RFC 4291,
).
Whether this is a bug for postgres seems to depend on whether that
reading is coming from the OS or postgres itself.


I enabled IPv6 on my laptop (maybe I did it wrong, dunno) and noted that
%en1 and %lo0 and similar notations were appended to some but not all of
the IPv6 addresses output by "netstat -r -n".  Furthermore it seemed
that adding or not adding these notations to IPv6 addresses given to
psql's -h switch affected whether I could connect or not.  I didn't see
a case where the %-thingy showed up in getnameinfo() output within
Postgres, as is apparently happening for Brian; but it sure looked like
it was happening to netstat.  So Apple is doing something mighty
nonstandard here :-(.  I ran out of time/interest to probe deeper.


fe80:: addresses adre link local addresses and only valid in the context
of a specific interface. This is why bsd based oprating systems append 
%ifname to the address so that they know which Interface this address 
is on.


Windows seems to append %interfacenumber.  Not sure what linux does. 
Propably %ethN.


Check RFC4007 IPv6 Scoped Address Architecture for details.

There is propbaly not much point in using link local addreses for postgres.
You should have global ipv6 prefix on your interfaces to really make use 
of ipv6.


Greetins
Christian

--
Christian Kratzer  CK Software GmbH
Email:   [EMAIL PROTECTED]  Schwarzwaldstr. 31
Phone:   +49 7452 889 135  D-71131 Jettingen
Fax: +49 7452 889 136  HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [BUGS] strange problem with ip6

[Christian Kratzer]

Hi,

On Thu, 17 May 2007, Andrew Sullivan wrote:


On Thu, May 17, 2007 at 06:42:39PM +0200, Christian Kratzer wrote:

of a specific interface. This is why bsd based oprating systems append
%ifname to the address so that they know which Interface this address


Oh, I forgot about that wart in RFC4007.  Thanks for the cluestick.


There is propbaly not much point in using link local addreses for postgres.


I think that's not quite right.  For instance, JDBC can't use UNIX
domain sockets last I checked, and I can imagine using it in a
disconnected context where you'd want to emulate multiple connection
points.  Link local addresses would be perfect for this.  So I think
it might be a bug, because Postgres isn't accepting the address
specification for scoped addresses.  (In the local 8.1.x version I
have installed here, the inet type doesn't accept it either.) Now
that I re-read it, RFC4007 seems to be pretty clear that the scope
info is a necessary part of the addressing, so I don't think it can
be thrown away before looking at the address.


supporting scoped addresses could have their uses but then again
theres nothing stopping you to bind multiple global ipv6 addresses
to your loopback interface which would work fine for disconnected
setups and it might be a bit cleaner.

Greetings
Christian

--
Christian Kratzer  CK Software GmbH
Email:   [EMAIL PROTECTED]  Schwarzwaldstr. 31
Phone:   +49 7452 889 135  D-71131 Jettingen
Fax: +49 7452 889 136  HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

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

  http://archives.postgresql.org

Re: [BUGS] strange problem with ip6

[Andrew Sullivan]

On Thu, May 17, 2007 at 07:29:47PM +0200, Christian Kratzer wrote:
> supporting scoped addresses could have their uses but then again
> theres nothing stopping you to bind multiple global ipv6 addresses
> to your loopback interface which would work fine for disconnected
> setups and it might be a bit cleaner.

True, but there's no unscoped private-use address space in IPv6 the
way there is in v4 (i.e. no 1918-style addresses for v6).  Which
means that unless you want to use addresses that ought to be
scoped (like link-local) without a scope, you have to use real
addresses instead.  Hmm.  Well, I guess you could use 2001:DB8::/32,
which is reserved for documentation.  I'm just worried that, because
we don't support scoped addresses, people are going to configure
things with _real_ addresses they haven't been allocated, and then
accidentally connect such a configuration to the Internet.  All my
experience tells me that such things eventually always leak, and I'd
hate for Postgres to be the source of that sort of damage.

A

-- 
Andrew Sullivan  | [EMAIL PROTECTED]
The whole tendency of modern prose is away from concreteness.
--George Orwell

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [BUGS] strange problem with ip6

[Tom Lane]

Andrew Sullivan <[EMAIL PROTECTED]> writes:
> On Thu, May 17, 2007 at 06:42:39PM +0200, Christian Kratzer wrote:
>> of a specific interface. This is why bsd based oprating systems append 
>> %ifname to the address so that they know which Interface this address 

> Oh, I forgot about that wart in RFC4007.  Thanks for the cluestick.

>> There is propbaly not much point in using link local addreses for postgres.

> I think that's not quite right.  For instance, JDBC can't use UNIX
> domain sockets last I checked, and I can imagine using it in a
> disconnected context where you'd want to emulate multiple connection
> points.  Link local addresses would be perfect for this.  So I think
> it might be a bug, because Postgres isn't accepting the address
> specification for scoped addresses.  (In the local 8.1.x version I
> have installed here, the inet type doesn't accept it either.) Now
> that I re-read it, RFC4007 seems to be pretty clear that the scope
> info is a necessary part of the addressing, so I don't think it can
> be thrown away before looking at the address.

It seems the correct solution here is to extend the inet type to support
RFC4007 "zone_id" strings.  Yech.  Not going to happen as a bug fix,
but we should probably put it on the TODO list.

As a temporary workaround, should we hack the server to suppress any
%-foo found in the result of getnameinfo()?

regards, tom lane

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [BUGS] strange problem with ip6

[Christian Kratzer]

Hi,

On Thu, 17 May 2007, Andrew Sullivan wrote:


On Thu, May 17, 2007 at 07:29:47PM +0200, Christian Kratzer wrote:

supporting scoped addresses could have their uses but then again
theres nothing stopping you to bind multiple global ipv6 addresses
to your loopback interface which would work fine for disconnected
setups and it might be a bit cleaner.


True, but there's no unscoped private-use address space in IPv6 the
way there is in v4 (i.e. no 1918-style addresses for v6).  Which
means that unless you want to use addresses that ought to be
scoped (like link-local) without a scope, you have to use real
addresses instead.  Hmm.  Well, I guess you could use 2001:DB8::/32,
which is reserved for documentation.  I'm just worried that, because
we don't support scoped addresses, people are going to configure
things with _real_ addresses they haven't been allocated, and then
accidentally connect such a configuration to the Internet.  All my
experience tells me that such things eventually always leak, and I'd
hate for Postgres to be the source of that sort of damage.


thats what I also thought.  Using link local addresses for real
applications is propably not quite what I would call "best practice"
but it will happen when people just turn on ipv6 and check what their 
shiny new address looks like.


It's not that simple though.  The ipv6 stack will propably not allow
users to build sockets from addresses in link local scope from a 
specific interface to a server bound to a global address, ::1, or

scoped to any other interface.  After all link local means exactly
this.

So if you have your postgres listening on ::1 you will not be
able to connect from your fe80::dead:beef%fxp0 address.

All in all it seems to me its best to leave everything as it is.

Greetings
Christian




A

--
Andrew Sullivan  | [EMAIL PROTECTED]
The whole tendency of modern prose is away from concreteness.
--George Orwell

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate




--
Christian Kratzer  CK Software GmbH
Email:   [EMAIL PROTECTED]  Schwarzwaldstr. 31
Phone:   +49 7452 889 135  D-71131 Jettingen
Fax: +49 7452 889 136  HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

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

  http://archives.postgresql.org

Re: [BUGS] strange problem with ip6

[Andrew Sullivan]

On Thu, May 17, 2007 at 02:39:55PM -0400, Tom Lane wrote:
> It seems the correct solution here is to extend the inet type to support
> RFC4007 "zone_id" strings.  Yech.  Not going to happen as a bug fix,
> but we should probably put it on the TODO list.
> 
> As a temporary workaround, should we hack the server to suppress any
> %-foo found in the result of getnameinfo()?

Well, Christian's point about scoped versus global addresses is a
good one, so there might be an argument for leaving it alone, on the
grounds that you ought not to be able to come from there.  On the
other hand, since people are tripping over the feature right now,
they obviously _are_ able to come from there.  So maybe just hacking
it up is the best answer for the time being.  (I'm slightly more
concerned that the inet datatype apparently has this issue too,
because it would seem that it's rejecting perfectly well-formed
input, which is surely bad.)

A

-- 
Andrew Sullivan  | [EMAIL PROTECTED]
Everything that happens in the world happens at some place.
--Jane Jacobs 

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [BUGS] strange problem with ip6

[Christian Kratzer]

Hi,

On Thu, 17 May 2007, Tom Lane wrote:


It seems the correct solution here is to extend the inet type to support
RFC4007 "zone_id" strings.  Yech.  Not going to happen as a bug fix,
but we should probably put it on the TODO list.


propably yes. But we should bear in mind that addresses of different
scopes are not comparable with each other in the sense of apples vs.
oranges.

i.e:

 select 'fe80::1%em0'::inet = 'fe80::1%em1'::inet;

should return null.

Also how do we define sort order if not all values are comparable.


As a temporary workaround, should we hack the server to suppress any
%-foo found in the result of getnameinfo()?


Not sure what that would buy us.  Stripping the scope from the address
does not seem the right thing to do.

Extending the generic inet type with scoped addresss is another question.

Greetings
Christian

--
Christian Kratzer  CK Software GmbH
Email:   [EMAIL PROTECTED]  Schwarzwaldstr. 31
Phone:   +49 7452 889 135  D-71131 Jettingen
Fax: +49 7452 889 136  HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [BUGS] BUG #3266: SSL broken pipes kill the machine and fill the disk

[Magnus Hagander]

This looks a lot like bug #2829 (excep that one is Windows), as I
mentioned here:
http://archives.postgresql.org/pgsql-hackers/2007-05/msg00461.php

Haven't looked into the actual code, though, but Tom had a suggestion in
the original bug, but AFAIK nobody has done that yet (at least not me.:)

//Magnus

Bruce Momjian wrote:
> I didn't see any comment on this.  Seems like a problem.
> 
> ---
> 
> Peter Koczan wrote:
>> The following bug has been logged online:
>>
>> Bug reference:  3266
>> Logged by:  Peter Koczan
>> Email address:  [EMAIL PROTECTED]
>> PostgreSQL version: 8.2.4
>> Operating system:   CentOS Linux 4.4 (RHEL 4) running on Pentium 4
>> Description:SSL broken pipes kill the machine and fill the disk
>> Details: 
>>
>> If a connection using SSL is terminated on the client side before a query
>> completes, postgres keeps trying to write to the broken connection, shooting
>> CPU and load very high and filling the postgres syslog (I have that pointed
>> to /var/log/pglog) with ~2000 of the following messages per second.
>>
>> May 10 14:45:01 mitchell postgres[10340]: [15729-1] LOG:  SSL SYSCALL error:
>> Broken pipe
>>
>> This quickly fills up the /var partition on the server.
>>
>> To replicate the problem:
>> 1. Connect to an running server using an SSL connection. Using psql is
>> fine.
>> 2. Begin a query on any table. For full effect the query should be expensive
>> and large.
>> 3. Kill psql *on the client side* BEFORE the query finishes (don't do
>> anything to the server side connection).
>> 4. 'tail -f' wherever the postgres server output and error is going to.
>> 5. Wait a few seconds while the server gets all of its data.
>> 6. See thousands of error messages fill up your terminal on the server.
>>
>> This has also happened when people stop web browsers in the middle of
>> serving up a postgresql-driven web page, but this is harder to replicate.
>>
>> This usually terminates, but after 3 hours for a query that usually takes 20
>> seconds. During this time, the server is slow to the point of unusable.
>>
>> ---(end of broadcast)---
>> TIP 6: explain analyze is your friend
> 


---(end of broadcast)---
TIP 1: 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] BUG #3288: Select command giving error

[Magnus Hagander]

Srinivas wrote:
> The following bug has been logged online:
> 
> Bug reference:  3288
> Logged by:  Srinivas
> Email address:  [EMAIL PROTECTED]
> PostgreSQL version: 8.2
> Operating system:   Win XP
> Description:Select command giving error
> Details: 
> 
> Hi, We are using PGOleDB drivers with ASP.Net C# code. We could connect and
> give the Insert, Update and Delete commands successfully. When we give a
> Select command, it is giving the following error. 
> 'PostgreSQL' failed with no error message available, result code:
> -2147221163(0x80040155).

Any specific reason you're using pgoledb from C#? You will likely get
much better results using the native npgsql driver.

It's been my experience that you often get this kind of unhelpful error
messages from the oledb layer regardless of what db you're using - I see
it all the time with the sqlserver and AD providers. Never really found
a good way to deal with it :( So if you can change, I very much
recommend you look at npgsql.

//Magnus

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [BUGS] strange problem with ip6

[Tom Lane]

Christian Kratzer <[EMAIL PROTECTED]> writes:
> On Thu, 17 May 2007, Tom Lane wrote:
>> As a temporary workaround, should we hack the server to suppress any
>> %-foo found in the result of getnameinfo()?

> Not sure what that would buy us.

Mostly, it would buy us not having pg_stat_activity fail completely
whenever someone is connected over a scoped connection.

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [BUGS] strange problem with ip6

[Tom Lane]

Christian Kratzer <[EMAIL PROTECTED]> writes:
> It's not that simple though.  The ipv6 stack will propably not allow
> users to build sockets from addresses in link local scope from a 
> specific interface to a server bound to a global address, ::1, or
> scoped to any other interface.  After all link local means exactly
> this.

> So if you have your postgres listening on ::1 you will not be
> able to connect from your fe80::dead:beef%fxp0 address.

But if you tell it to listen to *, won't it bind to everything in sight?
In particular we know that this thread started because someone had a
connection through a scoped address, so one way or another it's possible.

regards, tom lane

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] [BUGS] Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped)

[Bruce Momjian]

Is there a TODO here?

---

Russell Smith wrote:
> Alvaro Herrera wrote:
> > Russell Smith wrote:
> >   
> >> Alvaro Herrera wrote:
> >> 
> >>> Alvaro Herrera wrote:
> >>>
> >>>  
> >>>   
>  2. decide that the standard is braindead and just omit dumping the
>    grantor when it's no longer available, but don't remove
>    pg_auth_members.grantor
> 
>  Which do people feel should be implemented?  I can do whatever we
>  decide; if no one has a strong opinion on the matter, my opinion is we
>  do (2) which is the easiest.
>  
> >>> Here is a patch implementing this idea, vaguely based on Russell's.
> >>>   
> >> I haven't had time to finalize my research about this, but the admin 
> >> option with revoke doesn't appear to work as expected.
> >>
> >> Here is my sample SQL for 8.2.4
> >>
> >> create table test (x integer);
> >> \z
> >> create role test1 noinherit;
> >> create role test2 noinherit;
> >> grant select on test to test1 with grant option;
> >> grant select on test to test2;
> >> \z test
> >> set role test1;
> >> revoke select on test from test2;
> >> \z test
> >> set role test2;
> >> select * from test;
> >> reset role;
> >> revoke all on test from test2;
> >> revoke all on test from test1;
> >> drop role test2;
> >> drop role test1;
> >> drop table test;
> >> \q
> >>
> >>
> >> The privilege doesn't appear to be revoked by test1 from test2.  I'm not 
> >> sure if this is related, but I wanted to bring it up in light of the 
> >> options we have for grantor.
> >> 
> >
> > Humm, but the privilege was not granted by test1, but by the user you
> > were using initially.  The docs state in a note that
> >
> > A user can only revoke privileges that were granted directly by
> > that user.
> >
> > I understand that this would apply to the grantor stuff being discussed
> > in this thread as well, but I haven't seen anyone arguing that we should
> > implement that for GRANT ROLE (and I asked three times if people felt it
> > was important and nobody answered).
> >
> >   
> Well, I would vote for implementing this in GRANT ROLE.  I wish to use 
> it in my security model.  I don't think the spec is brain dead when you 
> understand what it's trying to achieve.
> 
> Example:
> 
> 2 Groups of administrators who are allowed to grant a role to users of 
> the system
> 
> App_Admin_G1
> App_Admin_G2
> App_User
> 
> SET ROLE App_Admin_G1
> GRANT App_User TO "Fred";
> SET ROLE App_Admin_G2
> GRANT App_User TO "John";
> SET ROLE App_Admin_G1
> REVOKE App_User FROM "John";
> 
> As App_Admin_G1 did not grant App_User rights to John, he should not be 
> able to take them away.
> 
> I currently have a situation where I would like to be able to do the 
> above.  I have two separate departments who might grant privileges for 
> the same application to the same user.  One department administrator 
> should not be able to revoke the privileges set by the other one.
> 
> I would expect superusers to be able to revoke from anybody, or the 
> "owner".  I'm not sure what the owner is when we talk about granting roles.
> 
> Regards
> 
> Russell Smith
> 
> 
> ---(end of broadcast)---
> TIP 5: don't forget to increase your free space map settings

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

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

Re: [HACKERS] [BUGS] Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped)

[Alvaro Herrera]

Bruce Momjian wrote:
> 
> Is there a TODO here?

Yes, I think so:

* Implement the SQL standard mechanism whereby REVOKE ROLE only revokes
  the privilege as granted by the invoking role, and not those granted
  by other roles


-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [BUGS] BUG #3266: SSL broken pipes kill the machine and fill the disk

[Bruce Momjian]

Added to TODO:

* Fix problem with excessive logging during SSL disconnection

  http://archives.postgresql.org/pgsql-bugs/2006-12/msg00122.php
  http://archives.postgresql.org/pgsql-bugs/2007-05/msg00065.php



---

Peter Koczan wrote:
> Yes, #2829 seems quite similar to my plight. I did take a look through 
> the code tree and there appear to be checks for an EINTR status within 
> loops in src/backend/libpq/pqcomm.c (line 725 in function pq_recvbuf and 
> line 1057 in function internal_flush), that could point to the problem. 
> I don't know enough about OpenSSL and it took me a long time to find out 
> as much as I did.
> 
> FYI, I compiled against OpenSSL 0.9.8d, if that makes any difference.
> 
> Peter
> 
> Magnus Hagander wrote:
> > This looks a lot like bug #2829 (excep that one is Windows), as I
> > mentioned here:
> > http://archives.postgresql.org/pgsql-hackers/2007-05/msg00461.php
> >
> > Haven't looked into the actual code, though, but Tom had a suggestion in
> > the original bug, but AFAIK nobody has done that yet (at least not me.:)
> >
> > //Magnus
> >
> > Bruce Momjian wrote:
> >   
> >> I didn't see any comment on this.  Seems like a problem.
> >>
> >> ---
> >>
> >> Peter Koczan wrote:
> >> 
> >>> The following bug has been logged online:
> >>>
> >>> Bug reference:  3266
> >>> Logged by:  Peter Koczan
> >>> Email address:  [EMAIL PROTECTED]
> >>> PostgreSQL version: 8.2.4
> >>> Operating system:   CentOS Linux 4.4 (RHEL 4) running on Pentium 4
> >>> Description:SSL broken pipes kill the machine and fill the disk
> >>> Details: 
> >>>
> >>> If a connection using SSL is terminated on the client side before a query
> >>> completes, postgres keeps trying to write to the broken connection, 
> >>> shooting
> >>> CPU and load very high and filling the postgres syslog (I have that 
> >>> pointed
> >>> to /var/log/pglog) with ~2000 of the following messages per second.
> >>>
> >>> May 10 14:45:01 mitchell postgres[10340]: [15729-1] LOG:  SSL SYSCALL 
> >>> error:
> >>> Broken pipe
> >>>
> >>> This quickly fills up the /var partition on the server.
> >>>
> >>> To replicate the problem:
> >>> 1. Connect to an running server using an SSL connection. Using psql is
> >>> fine.
> >>> 2. Begin a query on any table. For full effect the query should be 
> >>> expensive
> >>> and large.
> >>> 3. Kill psql *on the client side* BEFORE the query finishes (don't do
> >>> anything to the server side connection).
> >>> 4. 'tail -f' wherever the postgres server output and error is going to.
> >>> 5. Wait a few seconds while the server gets all of its data.
> >>> 6. See thousands of error messages fill up your terminal on the server.
> >>>
> >>> This has also happened when people stop web browsers in the middle of
> >>> serving up a postgresql-driven web page, but this is harder to replicate.
> >>>
> >>> This usually terminates, but after 3 hours for a query that usually takes 
> >>> 20
> >>> seconds. During this time, the server is slow to the point of unusable.
> >>>
> >>> ---(end of broadcast)---
> >>> TIP 6: explain analyze is your friend
> >>>   
> >
> >
> >   

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

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

   http://archives.postgresql.org

Re: [HACKERS] [BUGS] Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped)

[Bruce Momjian]

Added to TODO:

---

Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > 
> > Is there a TODO here?
> 
> Yes, I think so:
> 
> * Implement the SQL standard mechanism whereby REVOKE ROLE only revokes
>   the privilege as granted by the invoking role, and not those granted
>   by other roles
> 
> 
> -- 
> Alvaro Herrerahttp://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 1: 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] strange problem with ip6

[Tom Lane]

Andrew Sullivan <[EMAIL PROTECTED]> writes:
> On Thu, May 17, 2007 at 02:39:55PM -0400, Tom Lane wrote:
>> It seems the correct solution here is to extend the inet type to support
>> RFC4007 "zone_id" strings.  Yech.  Not going to happen as a bug fix,
>> but we should probably put it on the TODO list.
>> 
>> As a temporary workaround, should we hack the server to suppress any
>> %-foo found in the result of getnameinfo()?

> Well, Christian's point about scoped versus global addresses is a
> good one, so there might be an argument for leaving it alone, on the
> grounds that you ought not to be able to come from there.  On the
> other hand, since people are tripping over the feature right now,
> they obviously _are_ able to come from there.  So maybe just hacking
> it up is the best answer for the time being.

Agreed, and done.  I found btw that "fe80::something%lo0" works
perfectly well in pg_hba.conf ... so there are parts of the code
able to handle this already.

> (I'm slightly more
> concerned that the inet datatype apparently has this issue too,
> because it would seem that it's rejecting perfectly well-formed
> input, which is surely bad.)

Well, let's be clear: this is entirely the fault of the inet type not
accepting what we now know to be RFC-compliant address specifications.
So we ought to put fixing that on the TODO list.  It's not happening
for 8.3 though, let alone in existing release branches, so we'd best
put in a workaround until it's there.

regards, tom lane

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [BUGS] strange problem with ip6

[Bruce Momjian]

Tom Lane wrote:
> Well, let's be clear: this is entirely the fault of the inet type not
> accepting what we now know to be RFC-compliant address specifications.
> So we ought to put fixing that on the TODO list.  It's not happening
> for 8.3 though, let alone in existing release branches, so we'd best
> put in a workaround until it's there.

Already added to TODO.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [BUGS] BUG #3266: SSL broken pipes kill the machine and fill the disk

[Tom Lane]

Magnus Hagander <[EMAIL PROTECTED]> writes:
> This looks a lot like bug #2829 (excep that one is Windows), as I
> mentioned here:
> http://archives.postgresql.org/pgsql-hackers/2007-05/msg00461.php
> Haven't looked into the actual code, though, but Tom had a suggestion in
> the original bug, but AFAIK nobody has done that yet (at least not me.:)

I reproduced this on my own machine, and basically the problem seems to
be that secure_write() has been coded to bleat on every failure.  This
behavior overrides the intelligence that was put into pqcomm.c's
internal_flush() a long time ago to not report consecutive write
failures ... which worked fine at the time it was written, because it
was just calling send() not secure_write().  secure_write is obviously
inconsistent anyway, since it doesn't elog anything in the non-SSL path.

Proposed fix:

1. For cases where errno conveys all the useful info (ie,
SSL_ERROR_SYSCALL), secure_write should elog nothing and just let
its caller do it, same as the plain send() path.

2. For SSL protocol errors (SSL_ERROR_SSL), we do want to print the
error at least once.  It is not clear whether repeated calls would
be likely to produce the same failure, and we don't have any cheap
way to tell whether the messages are duplicate.  I'm inclined to leave
that path alone until/unless we get reports of many duplicate messages
from it.

regards, tom lane

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq