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 amp; Win32
Description:
Attempting to prepare a CREATE TABLE statement fails with a
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
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
ags...@gmail.com 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
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
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
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 coup
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 $$
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
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
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
dep...@depesz.com wrote:
On Wed, Jan 04, 2012 at 07:17:17PM +, pram...@cleverelephant.ca wrote:
The following bug
2012/1/4 Paul Ramsey pram...@cleverelephant.ca:
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
dep...@depesz.com wrote:
On Wed, Jan 04, 2012 at
Hi,
On Sat, Aug 6, 2011 at 12:18 AM, Noah Misch n...@2ndquadrant.com 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 t...@sss.pgh.pa.us wrote:
OK, applied to HEAD and
Paul Ramsey pram...@cleverelephant.ca 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
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.org)
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.
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
Ryan P. Kelly rpkell...@gmail.com 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
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
19 matches
Mail list logo
