Stefan Kaltenbrunner wrote:
Hi all!
While hacking on some C-level functions I noticed that everytime I
replaced the .so file and used CREATE OR REPLACE FUNCTION the backend
immediatly crashed.
To test that it was not caused by something my function does (or one of
the libaries it links in)
Frank van Vugt <[EMAIL PROTECTED]> writes:
>>> Ok, so for patch-sake, when I change BeginInternalSubTransaction() in
>>> xact.c by moving these two cases to the upper set
>>> (TBLOCK_STARTED/INPROGRESS/SUBINPROGRESS), then I should be ok?
>> Try it and see ...
> Been there, done that, seems to wo
> > Ok, so for patch-sake, when I change BeginInternalSubTransaction() in
> > xact.c by moving these two cases to the upper set
> > (TBLOCK_STARTED/INPROGRESS/SUBINPROGRESS), then I should be ok?
> Try it and see ...
Been there, done that, seems to work (both the example as well as my usecase).
Frank van Vugt <[EMAIL PROTECTED]> writes:
> Ok, so for patch-sake, when I change BeginInternalSubTransaction() in xact.c
> by moving these two cases to the upper set
> (TBLOCK_STARTED/INPROGRESS/SUBINPROGRESS), then I should be ok?
Try it and see ...
regards, tom lane
> Hmm, do you get the impression that user-written constraint triggers
> aren't very well tested ;-) ?
Well, we users are here to serve ;)
> It looks to me like BeginInternalSubTransaction simply needs to allow
> TBLOCK_END (and TBLOCK_PREPARE too) as acceptable initial states
Ok, so for patch-s
Frank van Vugt <[EMAIL PROTECTED]> writes:
> FATAL: BeginInternalSubTransaction: unexpected state END
Hmm, do you get the impression that user-written constraint triggers
aren't very well tested ;-) ?
It looks to me like BeginInternalSubTransaction simply needs to allow
TBLOCK_END (and TBLOCK_PR
On Thu, 2007-03-15 at 01:40 -0400, Tom Lane wrote:
> SM <[EMAIL PROTECTED]> writes:
> > I got a backend crash in Postgresql 8.2.3 with the plpgsql function.
> > The following statement in psql causes a signal 11:
> > psql=# create function testpl() returns void as 'begin return;
> > end;'language
SM wrote:
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /usr/libexec/ld.so...done.
> Reading symbols from /usr/lib/libm.so.1.0...done.
> Reading symbols from /usr/lib/libc.so.29.0...done.
> Reading symbols from /usr/local/pgsql/lib/plpgsql.so...done.
> #0 0x234c2
SM <[EMAIL PROTECTED]> writes:
> I got a backend crash in Postgresql 8.2.3 with the plpgsql function.
> The following statement in psql causes a signal 11:
> psql=# create function testpl() returns void as 'begin return;
> end;'language 'plpgsql';
Worksforme ...
regards,
Jeff Bohmer <[EMAIL PROTECTED]> writes:
Great! I'd like to try out the patch when it's ready.
Here ya go.
Works for me on OS X and Linux.
Thank you very much!
- Jeff
--
Jeff Bohmer
VisionLink, Inc.
_
303.402.0170
www.visionlink.org
_
Jeff Bohmer <[EMAIL PROTECTED]> writes:
> Great! I'd like to try out the patch when it's ready.
Here ya go.
regards, tom lane
Index: src/backend/executor/execAmi.c
===
RCS file: /cvsroot/pgsql-server/src/bac
I should have a patch later today.
Great! I'd like to try out the patch when it's ready.
Thanks,
- Jeff
--
Jeff Bohmer
VisionLink, Inc.
_
303.402.0170
www.visionlink.org
_
People. Tools. Change. Community.
---
Jeff Bohmer <[EMAIL PROTECTED]> writes:
> Running any of these statements on my database causes the backend to
> crash (example from PG log below):
Crash confirmed here. Seems to be a side-effect of the 7.4 optimization
that tries to avoid "unnecessary" projection steps. In the "SELECT *
FROM f
Tom Lane ([EMAIL PROTECTED]) wrote:
> I get
>
> FATAL 1: btree: failed to add item to the page in _bt_sort (2)
> pqReadData() -- backend closed the channel unexpectedly.
> This probably means the backend terminated abnormally
> before or while processing the request.
>
> Is that
[EMAIL PROTECTED] writes:
> The attached sql crashed Postgres 7.0.2 on a debian linux system
> (intel), using the packages 7.0.2-6.
I get
FATAL 1: btree: failed to add item to the page in _bt_sort (2)
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backe
[EMAIL PROTECTED] writes:
> There are two nearly identical tables, differ from each other by the
> length of corresponding fields of type CHARACTER (one has
> CHARACTER(20) field, other has CHARACTER(30) field).
> when i do "select * from table1 union select * from table2" backend
> crashes with m
This is a known bug. Current sources will not crash, but will
instead fail the query (since they are still referencing the name).
By 7.2, the ri triggers should probably be following the oid
of the tables and columns and will be safe from renames.
Stephan Szabo
[EMAIL PROTECTED]
On Sat, 9 Sep
>> Backend crashes at some queries involving views of aggregate queries.
> 7.0beta3 is fixed in this area.
The particular query shown here may work in 7.0, but it's important to
know that views using grouping or aggregates are still not implemented
right in 7.0. It's not going to be possible to
7.0beta3 is fixed in this area.
>
> POSTGRESQL BUG REPORT TEMPLATE
>
>
>
> Your name : Marinos J. Y
19 matches
Mail list logo
