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 th
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
On May 22, 2007, at 14:57 , ;John D. Tiedeman wrote:
The following bug has been logged online:
Bug reference: 3297
Logged by: ;John D. Tiedeman
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.4
Operating system: Linux (Kubuntu 7.4)
Description:psql won't ope
The following bug has been logged online:
Bug reference: 3258
Logged by: Phil Criley
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1 and 8.2
Operating system: Fedora Core 5
Description:Password fails, RPM installs in wrong directory
Details:
We run FC5 on
Hrm...I haven't used windows for a while now, but isn't there an
option on all shortcuts to command-line programs to make the shell
pause on exit? It is something like, right click on shortcut, select
'properties', uncheck 'close shell on exit'. It would seem this would
solve the problem of
Great, this seems to solve the problem. Thanks for the prompt attention.
On Feb 15, 2007, at 10:52 PM, Tom Lane wrote:
Phil Frost <[EMAIL PROTECTED]> writes:
I rebuilt my pg with the attached patch and it did indeed resolve the
assertion failure the previous test produced. I tinkere
Yeah, maybe I am the only one doing this to the planner. The
optimizations which caused this error will be greatly appreciated
when I stop getting segfaults, however :)
I rebuilt my pg with the attached patch and it did indeed resolve the
assertion failure the previous test produced. I tink
Hi Tom,
Tom Lane wrote:
"Phil Endecott" <[EMAIL PROTECTED]> writes:
I understand that PQexecParams may only be used for SELECT, INSERT, DELETE
and UPDATE commands, but not for other commands where parameter substitution
might be useful such as CREATE VIEW and CREATE TABLE AS
I'm resending this as the first attempt didn't make it to the list.
Phil.
Phil Endecott wrote:
Hi Tom,
Tom Lane wrote:
"Phil Endecott" <[EMAIL PROTECTED]> writes:
I understand that PQexecParams may only be used for SELECT, INSERT, DELETE
and UPDATE commands,
o it couldn't be
blamed. I'll explore the problem more today and see if I can get a
backtrace with a debug version and debug_assertions off.
On Feb 14, 2007, at 5:49 PM, Tom Lane wrote:
Phil Frost <[EMAIL PROTECTED]> writes:
I have been attempting to migrate my application from 8.
I have been attempting to migrate my application from 8.1 to 8.2.3.
In doing so, I found some queries would always cause the postgres
backend to die with a segfault. I was advised to rebuild with --
enable-debug --enable-cassert, and so I did. The same query would now
cause an assertion fail
The following bug has been logged online:
Bug reference: 3002
Logged by: Phil Endecott
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.0
Operating system: All?
Description:PQexecParams only supports some commands; needs improved
error reporting, documenting
Things were crusing along just fine as I can tell, and then all the
postgresql processes terminated. This is all I see in the logs:
LOG: autovacuum: processing database "dew"
LOG: autovacuum: processing database "postgres"
LOG: autovacuum: processing database "template1"
LOG: autovacuum: proce
The following bug has been logged online:
Bug reference: 2512
Logged by: Phil Frost
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system: Mac OS 10.4.7
Description:pg_dump produces unrestorable output when table and
serial sequence are not in
The following bug has been logged online:
Bug reference: 1403
Logged by: Phil
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8
Operating system: windows
Description:Failed to create process: 2
Details:
Running the msi installer gave thie above message
t. I think
that time switches in EST/EDT are supposed to happen at 2am, not midnight,
to help avoid this kind of thing.
Phil
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
act same query works fine when we remove a
default on a column on the table which isn't being referenced.
I'm not sure if this is a bug, a poorly written error message, or my
ignorance. :') We are using Postgresql 7.0.3 release under Linux:
phil=# select version();
Ah, I think I understand the trouble now. It's good it's fixed for
the next release. And, as predicted, I'm running in a DST zone
(/etc/localtime -> ../usr/share/zoneinfo/US/Pacific)
Thanks for the quick diagnosis!
Phil
On Wed, Jan 17, 2001 at 09:07:34PM -0500, Tom La
Thanks for the reply Tom Lane, and Tom Lockhart. On my 7.0.3:
phil=# select '4/1/2001'::date::timestamp;
?column?
2001-03-31 23:00:00-08
(1 row)
This was built from source downloaded from the primary FTP site link
on www.postgresql.org.
5
21 22 23 24 25 26 27 18 19 20 21 22 23 24 16 17 18 19 20 21 22
28 29 30 3125 26 27 28 29 30 23 24 25 26 27 28 29
30 31
Otherwise, I love PostgreSQL! An awesome backend, and knocks the
socks off MySQL for anything SQL worthy. ;
38 matches
Mail list logo
