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 lo
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 reques
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" 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
> keyword in 8.4 b)
Tom Lane wrote:
> Bruce Momjian 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 an error
"Hartmut Goebel" 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 version's
pg_dump.
>
>Hartmut Goebel 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 (pgsql-bugs@postgresql.o
Bruce Momjian wrote:
> Robert Haas wrote:
> > On Mon, May 31, 2010 at 10:11 AM, Bruce Momjian wrote:
> > > Robert Haas wrote:
> > >> On Sat, May 29, 2010 at 5:00 PM, Bruce Momjian wrote:
> > >> > I have updated the patch, attached, to clarify that this returns text
> > >> > arrays, and that you c
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 accessin
On 03.06.2010 05:05, Bruce Momjian wrote:
> The schema containing the citext operators must be
> in the current search_path (typically public);
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 search_path isn't
enough. "pu
Markus Wichitill wrote:
> On 03.06.2010 05:05, Bruce Momjian wrote:
> > The schema containing the citext operators must be
> > in the current search_path (typically public);
>
> It's been a while, but the way I read my own example is that the schema
> containing the citext operators being in the c
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
---
P
Gurjeet Singh 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 catalogs...
On Thu, Jun 3, 2010 at 1:02 PM, Tom Lane wrote:
> Gurjeet Singh 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 thi
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
Gurjeet Singh 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 pgsql-bugs mailing list (pgs
Claudio Freire 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 precisely matche
Hartmut Goebel 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 provide some
way to instal
On Fri, 2010-04-30 at 11:50 -0400, Tom Lane wrote:
> "Kevin Grittner" writes:
> > Eliminating null columns and mangling column headers for length, I
> > get this:
>
> > locktype| tranid | virtualx | pid | mode | gr
> > transactionid | 39773877 | 63/15761 | 11157 | ShareLock
On Thu, 2010-06-03 at 13:42 -0400, Tom Lane wrote:
> Claudio Freire 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
"Kevin Grittner" writes:
> Hartmut Goebel 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 pac
Claudio Freire wrote:
> On Thu, 2010-06-03 at 13:42 -0400, Tom Lane wrote:
>> Claudio Freire 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
>>
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 ver
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 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 power fail
27 matches
Mail list logo