On Fri, Dec 28, 2012 at 5:30 PM, Heikki Linnakangas
wrote:
> A stack trace would be nice. If you didn't get a core dump this time, it
> would be good to configure the system so that you get one next time it
> happens.
>
> - Heikki
Sorry, no core. I will get it set up in case it happens again.
-
Postgres 9.0.11 running as a hot standby.
The master was restarted and the standby went into a segmentation
fault loop. A hard stop/start fixed it. Here are pertinent logs with
excess and identifying information removed:
2012-12-28 03:39:14 UTC [16850]: [2-1] FATAL: replication terminated
by pr
On Sun, Nov 18, 2012 at 2:33 AM, Tom Lane wrote:
> Phil Sorber writes:
>> An install of ours was having an issue with log files filling up the
>> disk rather quickly. After looking into it, the log was filling up
>> with NOTICE's caused by an ORM that was using a ve
On Nov 17, 2012 11:06 PM, "Gavin Flower"
wrote:
>
> On 18/11/12 16:49, Greg Sabino Mullane wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: RIPEMD160
>>
>>
>>> NOTICE: identifier
>>> "this_is_a_really_long_identifier_for_a_prepared_statement_name_ok"
>>> will be truncated to
>>> "this_is_
An install of ours was having an issue with log files filling up the
disk rather quickly. After looking into it, the log was filling up
with NOTICE's caused by an ORM that was using a very long identifier
as a name for a prepared statement. It was a concatenation of tables
in the query. The server
On Wed, Mar 7, 2012 at 1:46 PM, Tom Lane wrote:
> The attached proposed patch fixes the symptom Phil reported. However,
> I think we still have some work to do. I experimented with creating
> temp tables within an extension upgrade script, and found two
> interesting misbehaviors that the patch
On Tue, Mar 6, 2012 at 5:10 PM, Tom Lane wrote:
> Instead, I'm tempted to propose that dependency.c explicitly allow drops
> of objects that belong to the current extension, when an extension is
> being created or updated. (That is, if we come across a dependency
> reference to the active extensi
Running Postgres 9.1.3. As far as I can tell, when you do an 'alter
table' and add a new column with a new default value a temp table is
created and tracked by the extension as a new object, but when the
'alter table' statement tries to drop the temp table at the end, the
extension complains. I rec
http://www.postgresql.org/docs/devel/static/plpgsql-control-structures.html#PLPGSQL-UPSERT-EXAMPLE
This example can lead to an infinite loop if there is another column
that has a unique key constraint on it in addition to the primary key
and someone tries to execute the function with a unique prim
On Wed, Jan 25, 2012 at 5:13 PM, Tom Lane wrote:
> Phil Sorber writes:
>> That helped a lot. I now have a simple test case that I can reliably
>> re-produce the segfault and now also a patch that fixes it.
>
> [ pokes at that... ] Hmm. I think what this proves is that t
I screwed up cut and paste when putting the test case together. The
reference to table user_data should be t1.
On Wed, Jan 25, 2012 at 12:47 PM, Phil Sorber wrote:
> On Tue, Jan 24, 2012 at 4:03 PM, Tom Lane wrote:
>> Phil Sorber writes:
>>> On Tue, Jan 24, 2012 at 12:43 A
On Tue, Jan 24, 2012 at 4:03 PM, Tom Lane wrote:
> Phil Sorber writes:
>> On Tue, Jan 24, 2012 at 12:43 AM, Tom Lane wrote:
>>> How about a test case?
>
>> We are having trouble coming up with a test case that can reliably
>> reproduce this.
>
> The st
On Tue, Jan 24, 2012 at 12:43 AM, Tom Lane wrote:
> Phil Sorber writes:
>> I've attached a backtrace.
>
> How about a test case? I have no faith in the proposed patch without
> some evidence of what it's supposed to fix.
We are having trouble coming up with a
Running Postgres 9.1.2.
I've attached a backtrace. Looking at the backtrace it looks like
ExecGetResultType() gets called with a NULL planstate and causes the
segmentation fault:
https://github.com/postgres/postgres/blob/master/src/backend/executor/execUtils.c#L470
Following the stack I see that
On Tue, Dec 27, 2011 at 1:00 PM, Tom Lane wrote:
> Phil Sorber writes:
>> My search foo failed me. Someone just pointed me to a similar
>> conversation from some months ago:
>> http://archives.postgresql.org/pgsql-hackers/2011-07/msg00677.php
>
>> I would propos
On Tue, Dec 27, 2011 at 10:41 AM, Phil Sorber wrote:
> So first off some ground work:
>
> postgres=# select 'infinity'::timestamp;
> timestamp
> ---
> infinity
> (1 row)
>
> postgres=# select 'infinity'::float8;
> float8
> --
So first off some ground work:
postgres=# select 'infinity'::timestamp;
timestamp
---
infinity
(1 row)
postgres=# select 'infinity'::float8;
float8
--
Infinity
(1 row)
Establishing that we do in fact have an infinity value for both the
timestamp type and the double precision
On Mon, Nov 28, 2011 at 4:10 PM, Tom Lane wrote:
> Phil Sorber writes:
>> I am still able to reproduce the "ERROR: cache lookup failed for extension
>> x" if I use an explicit 'drop extension'. I am unsure how I can
>> reverse the state it is now
On Mon, Nov 28, 2011 at 3:12 PM, Tom Lane wrote:
> Phil Sorber writes:
>> I stumbled upon this situation when playing with extension upgrades.
>> The problem I was having was that auto-generated datatypes were also
>> being added to the extension and it wasn't obviou
I stumbled upon this situation when playing with extension upgrades.
The problem I was having was that auto-generated datatypes were also
being added to the extension and it wasn't obvious this was happening.
I know this has been changed in 9.1 stable and in master.
What happened was that I was ab
20 matches
Mail list logo
