I don't have an independent reproduction yet (though make test in [1]
should reproduce this). I haven't actually been able to reproduce by
hand yet, but pgtap has something to do with this. This is affecting at
least 9.4 and a fairly recent HEAD.
-- Bits from top of test/sql/base.sql
\i
Tim Bunce tim.bu...@pobox.com writes:
The attached patch fixes the problem by changing the SvTYPE check to use
SvROK instead. Although I only tripped over one case, the patch changes
all four uses of SvTYPE(sv) == SVt_RV. The remaining uses of SvTYPE are ok.
Applied back to 8.0. 7.4 seems not
On Sun, Mar 07, 2010 at 12:11:26PM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com writes:
I encountered a core dump running PL/Perl installcheck with a very
recent git HEAD of PostgreSQL and a not quite so recent git HEAD of perl.
The cause is a subtle difference between SvTYPE(sv)
Tim Bunce tim.bu...@pobox.com writes:
I encountered a core dump running PL/Perl installcheck with a very
recent git HEAD of PostgreSQL and a not quite so recent git HEAD of perl.
The cause is a subtle difference between SvTYPE(sv) == SVt_RV and
SvROK(sv). The former is checking a low-level
I encountered a core dump running PL/Perl installcheck with a very
recent git HEAD of PostgreSQL and a not quite so recent git HEAD of perl.
The cause is a subtle difference between SvTYPE(sv) == SVt_RV and
SvROK(sv). The former is checking a low-level implementation detail
while the later is
one of our customers here found a bug in PL/pgSQL.
this is how you can create this one:
CREATE OR REPLACE FUNCTION public.make_victim_history () RETURNS
trigger AS $body$ DECLARE
schemarec RECORD;
exec_schemaselect text;
curs2 refcursor;
BEGIN
exec_schemaselect := 'SELECT nspname
Hans-Juergen Schoenig wrote:
[...]
a quick fix is to prevent the language from freeing the tuple twice -
this should safely prevent the core dump here.
we still have to make sure that the tuple if freed properly. stay tuned.
here is the patch ...
this seems to be already fixed with:
oh sorry, i think i missed that one ...
many thanks,
hans
On Dec 19, 2006, at 3:42 PM, Stefan Kaltenbrunner wrote:
Hans-Juergen Schoenig wrote:
[...]
a quick fix is to prevent the language from freeing the tuple
twice - this should safely prevent the core dump here.
we still
I reproduced the problem by loading this dump to 8.1.0.
I think that the problem is the same as this:
http://archives.postgresql.org/pgsql-hackers/2005-11/msg01016.php
I saw heap_tuple_toast_attrs() overwrites a new tuple. And, backend
crashed while executing ExecInsertIndexTuples().
The problem
Atsushi Ogawa [EMAIL PROTECTED] writes:
I reproduced the problem by loading this dump to 8.1.0.
I think that the problem is the same as this:
http://archives.postgresql.org/pgsql-hackers/2005-11/msg01016.php
Good catch --- I agree that bug probably explains it.
initdb -E KOI8-R --locale ru_RU.KOI8-R -D $DIR
In HEAD I get
HEAD and REL8_1STABLE works fine, 8.1 release not (I don't test REL8_1_0, just
take a source package)
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
Hi!
Attached dump cause core on 8.1 release and works fine on REL8_1_STABLE and
HEAD.
Am I missed some fixes/commits?
PS dump in KOI8, db should be initialized as
initdb -E KOI8-R --locale ru_RU.KOI8-R -D $DIR
and it should be installed ltree and tsearch2 modules.
PPS gdb output:
Program
Teodor Sigaev [EMAIL PROTECTED] writes:
Attached dump cause core on 8.1 release and works fine on REL8_1_STABLE and
HEAD.
Am I missed some fixes/commits?
In HEAD I get
\i tsearch2.sql
...
\i ltree.sql
...
\i tsearch2_crash.dump
CREATE TABLE
ALTER TABLE
psql:tsearch2_crash.dump:86: ERROR:
On Wed, 23 Nov 2005, Tom Lane wrote:
Teodor Sigaev [EMAIL PROTECTED] writes:
Attached dump cause core on 8.1 release and works fine on REL8_1_STABLE and
HEAD.
Am I missed some fixes/commits?
In HEAD I get
\i tsearch2.sql
...
\i ltree.sql
...
\i tsearch2_crash.dump
CREATE TABLE
ALTER TABLE
Hi there,
following query cause postmaster to fail.
tp=# select query from rquery('newyorkhotel') as query;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was
Oleg Bartunov oleg@sai.msu.su writes:
following query cause postmaster to fail.
You haven't shown us your own code, but I'd guess that you are doing
something you shouldn't with memory contexts.
regards, tom lane
---(end of
Hi, folks;
We're running Postgres 7.3.2 and we have a core dump on HP-11.
This does not seem reproducible on Solaris or Linux.
Working with debugger we get this stack:
#0 0xc0185a20 in mallinfo+0x2144 () from /usr/lib/libc.2
(gdb) where
#0 0xc0185a20 in mallinfo+0x2144 () from /usr/lib/libc.2
#1
Hi, folks;
We're running Postgres 7.3.2.
At the end of some procedure we get a core dump on HP-11.
This does not seem reproducible on Solaris or Linux.
Working with debugger we get this stack:
#0 0xc0185a20 in mallinfo+0x2144 () from /usr/lib/libc.2
(gdb) where
#0 0xc0185a20 in mallinfo+0x2144
An obscure series of events seems to cause a core dump and OID
corruption:
-- tolower function for varchar
create function varchar_lower(varchar) returns varchar
as '/usr/local/lib/pgcontains.so', 'pglower'
language 'c';
create index ztables_title_ndx on ztitles (
mlw [EMAIL PROTECTED] writes:
[ drop function on which a functional index is based ]
and strange things start to happen.
All I get is messages like
ERROR: fmgr_info: function 402432: cache lookup failed
which is about what I'd expect. If you've seen a coredump in
this situation,
* Dan Moschuk [EMAIL PROTECTED] [001012 09:47] wrote:
Sparc solaris 2.7 with postgres 7.0.2
It seems to be reproducable, the server crashes on us at a rate of about
every few hours.
Any ideas?
GNU gdb 4.17
Copyright 1998 Free Software Foundation, Inc.
[snip]
#78 0x1dd210 in elog
| % uname -sr
| SunOS 5.7
|
| from sys/signal.h:
|
| #define SIGUSR1 16 /* user defined signal 1 */
|
| Are you sure you don't have any application running amok sending
| signals to processes it shouldn't? Getting a superfolous signal
| seems out of place, this doesn't look like a crash
| Sparc solaris 2.7 with postgres 7.0.2
| It seems to be reproducable, the server crashes on us at a rate of about
| every few hours.
|
| That's a very bizarre backtrace. Why the multiple levels of recursive
| entry to the quickdie() signal handler? I wonder if you aren't looking
| at some
Dan Moschuk [EMAIL PROTECTED] writes:
It would appear from that very rough test program that solaris doesn't mind
system calls from within a signal handler.
Still, it's a mighty peculiar backtrace.
After looking at postmaster.c, I see that the postmaster will issue
SIGUSR1 to all remaining
Dan Moschuk [EMAIL PROTECTED] writes:
| We should probably tweak the postmaster to be less enthusiastic about
| signaling its children repeatedly.
Perhaps have postgres ignore SIGUSR1 after it has already received one?
Now that you mention it, it tries to do exactly that:
void
I said:
BlockSig includes SIGUSR1.
Oh, wait, I take that back. It's initialized that way, but then
postmaster.c removes SIGUSR1 from the set.
regards, tom lane
| I said:
| BlockSig includes SIGUSR1.
|
| Oh, wait, I take that back. It's initialized that way, but then
| postmaster.c removes SIGUSR1 from the set.
|
| regards, tom lane
So, back to my initial question, why not make each postmaster SIG_IGN
SIGUSR1 after it
27 matches
Mail list logo
