Do you have openldap installed? I believe that is a library within that
package.
Or try custom building postgresql without ldap support.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
"Ryan P. Kelly" writes:
> The signal handler installed by setup_cancel_handler() will ignore
> attempts to exit psql should a host be unreachable.
Hm. That may be worth doing something about, but the proposed patch
seems more like a quick-and-dirty hack than a solution. The main
thing I don't l
The following bug has been logged on the website:
Bug reference: 6380
Logged by: Dean Schulze
Email address: dean.w.schu...@gmail.com
PostgreSQL version: 9.1.2
Operating system: CENTOS 6
Description:
I've tried both the .rpm from openscg and the .linux.run installer f
The signal handler installed by setup_cancel_handler() will ignore
attempts to exit psql should a host be unreachable. Since the
functionality it provides won't be used until later, it doesn't make
sense to set it up so early. Therefore, move the signal handler closer
to where it is first needed.
-
I wrote:
> Perhaps the intoRel stuff should be
> saving/restoring the original destreceiver instead of just blindly
> overwriting it.
I concluded that was the best fix, and have committed it.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.or
Paul Ramsey writes:
> Further notes, from Andrew (RhodiumToad) on IRC about the cause of this
> crasher:
> [12:31pm] RhodiumToad: there's no trivial fix
IMO the main bug here is that functions.c isn't expecting qd->dest to be
overwritten, so we could work around it by keeping a separate private
Hi,
On Sat, Aug 6, 2011 at 12:18 AM, Noah Misch wrote:
> A PG_SYSLOG_LIMIT value that loses data to truncation on nearly every default
> GNU/Linux installation makes for a poor default.
On Sat, Aug 6, 2011 at 3:03 AM, Tom Lane wrote:
> OK, applied to HEAD and 9.1.
We hit this problem a few day
Further notes, from Andrew (RhodiumToad) on IRC about the cause of this crasher:
[12:03pm] RhodiumToad: what happens is this
[12:04pm] RhodiumToad: postquel_start know this statement doesn't
return the result, so it supplies None_Receiver as the dest-receiver
for the query
[12:04pm] RhodiumToad: h
2012/1/4 Paul Ramsey :
> One extra detail, my PostgreSQL is compiled with --enable-cassert.
> This seems to be what sets off the killer function.
me too
Pavel
>
> On Wed, Jan 4, 2012 at 11:25 AM, hubert depesz lubaczewski
> wrote:
>> On Wed, Jan 04, 2012 at 07:17:17PM +, pram...@cleverelep
One extra detail, my PostgreSQL is compiled with --enable-cassert.
This seems to be what sets off the killer function.
On Wed, Jan 4, 2012 at 11:25 AM, hubert depesz lubaczewski
wrote:
> On Wed, Jan 04, 2012 at 07:17:17PM +, pram...@cleverelephant.ca wrote:
>> The following bug has been logge
Hello
I can replicate it
postgres=# select kill_backend();
NOTICE: table "foo" does not exist, skipping
CONTEXT: SQL function "kill_backend" statement 1
The connection to the server was lost. Attempting reset: Failed.
!>
bash-4.2$ uname -a
Linux nemesis 2.6.41.4-1.fc15.x86_64 #1 SMP Tue Nov 29
On Wed, Jan 04, 2012 at 07:17:17PM +, pram...@cleverelephant.ca wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6379
> Logged by: Paul Ramsey
> Email address: pram...@cleverelephant.ca
> PostgreSQL version: 9.1.2
> Operating system: OSX 10.6.8
The following bug has been logged on the website:
Bug reference: 6379
Logged by: Paul Ramsey
Email address: pram...@cleverelephant.ca
PostgreSQL version: 9.1.2
Operating system: OSX 10.6.8
Description:
CREATE OR REPLACE FUNCTION kill_backend()
RETURNS VOID
AS $$
DRO
Bonjour
Je rencontre un problème depuis le 3 janvier 2012 sur La base de Données
IWSS qui est apparemment corrompu
Message Lorsque je veux accéder à la base
[root@srv-proxy bin]# ./psql -U sa -d iwss
Message = psql: FATAL: could not open relation
"pg_trigger":
Et du cou
b...@openit.de writes:
> When creating an index on an inet column the postmaster process tries to
> allocate much more memory than it should in version 9.1.2.
Yeah, a memory leak was accidentally introduced into inet/cidr index
operations in 9.1.2. It will be fixed in 9.1.3, or if you're in a hur
This has been fixed since 9.1.2. If you browse the history and/or this mailing
list you should find a reference.
I just have my mobile here, so its a bit too hard to search for a reference
Greetings,
Andres
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to
wrote:
> postgres=# prepare foo as create table bar (c integer);
> ERROR: syntax error at or near "create"
> LINE 1: prepare foo as create table bar (c integer);
>^
>
> This error message does not in any way indicate that one cannot
> prepare a create table statement.
>
The following bug has been logged on the website:
Bug reference: 6378
Logged by: Julian v. Bock
Email address: b...@openit.de
PostgreSQL version: 9.1.2
Operating system: Linux x86_64
Description:
When creating an index on an inet column the postmaster process tries to
The following bug has been logged on the website:
Bug reference: 6377
Logged by: Igor
Email address: moiseev.i...@gmail.com
PostgreSQL version: 8.4.10
Operating system: any
Description:
On the page of "Appendix A. PostgreSQL Error Codes"
(http://www.postgresql.org/doc
The following bug has been logged on the website:
Bug reference: 6376
Logged by: Ansel Sermersheim
Email address: ags...@gmail.com
PostgreSQL version: 9.1.2
Operating system: Linux & Win32
Description:
Attempting to prepare a CREATE TABLE statement fails with a syntax
20 matches
Mail list logo
