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
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
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
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 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
> --
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
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, 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
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
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 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
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
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
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
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
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 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_
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
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 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.
-
20 matches
Mail list logo
