Hi,
Server crash while trying to read expression(wrong) using pg_get_expr().
postgres=# SELECT pg_get_expr('{FUNCEXPR', 1255);
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was
On 03/06/10 10:21, Rushabh Lathia wrote:
Server crash while trying to read expression(wrong) using pg_get_expr().
postgres=# SELECT pg_get_expr('{FUNCEXPR', 1255);
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the
The following bug has been logged online:
Bug reference: 5488
Logged by: Hartmut Goebel
Email address: h.goe...@goebel-consult.de
PostgreSQL version: 8.3 / 8.4
Operating system: all
Description:pg_dump does not quote column names - pg_restore may
fail when upgrading
Hartmut Goebel h.goe...@goebel-consult.de wrote:
Description:pg_dump does not quote column names -
pg_restore may fail when upgrading
If a 8.3 table contains a column named window, the dump can not
be restored into a 8.4 database. Reasons: a) window is a new
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I have documented this citext limitation with the attached, applied
patch.
Are you planning to insert similar verbiage into every other contrib
module's docs?
Uh, do they all have this odd behavior? Most people assume they would
get
Hartmut Goebel h.goe...@goebel-consult.de writes:
If a 8.3 table contains a column named window, the dump can not be
restored into a 8.4 database. Reasons: a) window is a new keyword in 8.4
b) pg_dump does not quote column names.
This is one of the cases where it's helpful to use the newer
Hartmut Goebel h.goe...@goebel-consult.de wrote:
I dumped with the executable form 8.3.
That's not expected to work for an upgrade to 8.4.
8.4 did not allow accessing the 8.3 database
What do you mean? (What did you try and what happened?)
-Kevin
--
Sent via pgsql-bugs mailing list
Bruce Momjian wrote:
Robert Haas wrote:
On Mon, May 31, 2010 at 10:11 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Sat, May 29, 2010 at 5:00 PM, Bruce Momjian br...@momjian.us wrote:
I have updated the patch, attached, to clarify that this returns text
arrays,
Am 03.06.2010 15:43, schrieb Kevin Grittner:
Note that the documentation recommends always running pg_dump using
the executable from the target version, not the source version. Are
you using the pg_dump executable from 8.4?
I dumped with the executable form 8.3.
8.4 did not allow accessing
On 03.06.2010 05:05, Bruce Momjian wrote:
The schema containing the typecitext/ operators must be
in the current varnamesearch_path/ (typically literalpublic/);
It's been a while, but the way I read my own example is that the schema
containing the citext operators being in the current
Markus Wichitill wrote:
On 03.06.2010 05:05, Bruce Momjian wrote:
The schema containing the typecitext/ operators must be
in the current varnamesearch_path/ (typically literalpublic/);
It's been a while, but the way I read my own example is that the schema
containing the citext operators
On PG 8.4.4 I am unable to set per-table autovacuum setting for the
pg_listener table. Being a superuser, I'd expect Postgres to allow me to do
that.
postgres=# select version();
version
---
Gurjeet Singh singh.gurj...@gmail.com writes:
On PG 8.4.4 I am unable to set per-table autovacuum setting for the
pg_listener table. Being a superuser, I'd expect Postgres to allow me to do
that.
See allow_system_table_mods. Even superusers should think twice before
fooling with system
On Thu, Jun 3, 2010 at 1:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Gurjeet Singh singh.gurj...@gmail.com writes:
On PG 8.4.4 I am unable to set per-table autovacuum setting for the
pg_listener table. Being a superuser, I'd expect Postgres to allow me to
do
that.
See
Am 03.06.2010 16:16, schrieb Kevin Grittner:
8.4 did not allow accessing the 8.3 database
What do you mean? (What did you try and what happened?)
If upgraded the rpm-packages from 8.3 to 8.4. Then postgres failed
starting (something like Database version mismatch). So I downgraded
to 8.3,
Gurjeet Singh singh.gurj...@gmail.com writes:
allow_system_table_mods needs a restart :( .Yet another parameter I wish was
changeable on the fly.
I'm not sure there's any compelling reason why it couldn't be SUSET.
Maybe a TODO ...
regards, tom lane
--
Sent via
Claudio Freire clau...@livra.com writes:
What I did do is analyze server load during the events, and as I
suspected, disk activity during the deadlocks seems to suggest a
vacuuming taking place. Although there was no autovacuum entry in
pg_stat_activity every time I checked, disk activity
Hartmut Goebel h.goe...@goebel-consult.de wrote:
If upgraded the rpm-packages from 8.3 to 8.4. Then postgres failed
starting (something like Database version mismatch).
You need to be running the old server using 8.3 software and while
using pg_dump from 8.4 software. Does your packager
On Thu, 2010-06-03 at 13:42 -0400, Tom Lane wrote:
Claudio Freire clau...@livra.com writes:
What I did do is analyze server load during the events, and as I
suspected, disk activity during the deadlocks seems to suggest a
vacuuming taking place. Although there was no autovacuum entry in
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Hartmut Goebel h.goe...@goebel-consult.de wrote:
If upgraded the rpm-packages from 8.3 to 8.4. Then postgres failed
starting (something like Database version mismatch).
You need to be running the old server using 8.3 software and while
Claudio Freire clau...@livra.com wrote:
On Thu, 2010-06-03 at 13:42 -0400, Tom Lane wrote:
Claudio Freire clau...@livra.com writes:
What I did do is analyze server load during the events, and as
I suspected, disk activity during the deadlocks seems to
suggest a vacuuming taking place.
On Thu, 2010-06-03 at 13:11 -0500, Kevin Grittner wrote:
Based on what I've heard so far, I wouldn't entirely
rule out some sort of bloat being a factor, either.
-Kevin
Index/table bloat is the first thing I suspected, and both table and
indices look all the right size. Knowing how
The following bug has been logged online:
Bug reference: 5489
Logged by: Alexander
Email address: goa...@gmail.com
PostgreSQL version: 8.3.11
Operating system: CentOS 5.4
Description:SELECT ... RETURNING INTO ... in ecpg
Details:
I've been using PostgreSQL since
On 27/05/10 13:37, Mark Kirkwood wrote:
On 25/05/10 16:43, Mark Kirkwood wrote:
Today I ran into some interesting consequences of the xml data type
being without an = operator. One I thought I'd post here because it
has a *possible* planner impact. I'm not sure it is actually a bug as
such,
On Thu, Jun 03, 2010 at 06:04:16PM +0200, Hartmut Goebel wrote:
If upgraded the rpm-packages from 8.3 to 8.4. Then postgres failed
starting (something like Database version mismatch). So I downgraded
to 8.3, pg_dump'ed there, upgraded and pg_restore'd.
pg_dump will complain if its version
On Wed, Jun 2, 2010 at 9:38 AM, botak bota...@gmail.com wrote:
Dear sirs,
Referring to the matter above.
For your information, we are a government agency and been hosting a
management system since 2006. The system was developed with Postgres Sql and
PHP in Centos Platform. Recently, after a
26 matches
Mail list logo
