Hi,
(2013/05/09 1:39), Joshua Berry wrote:
| I'm using PG 9.1.9 with a client application using various versions of
the
| pgsqlODBC driver on Windows. Cursors are used heavily, as well as some
pretty
| heavy trigger queries on db writes which update several materialized
views.
|
| The server
Hiroshi Inoue in...@tpf.co.jp writes:
It's also better to fix the crash at backend side.
Yeah, definitely. Do we have a self-contained test case for this?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
(2013/06/12 0:03), Tom Lane wrote:
Hiroshi Inoue in...@tpf.co.jp writes:
It's also better to fix the crash at backend side.
Yeah, definitely. Do we have a self-contained test case for this?
Unfortunately no. I'm testing with a modified psqlodbc driver.
The simplest way may be as follows.
| I'm using PG 9.1.9 with a client application using various versions of
the
| pgsqlODBC driver on Windows. Cursors are used heavily, as well as some
pretty
| heavy trigger queries on db writes which update several materialized
views.
|
| The server has 48GB RAM installed, PG is configured for
On 2013-04-10 19:06:12 -0400, Tom Lane wrote:
I wrote:
(Wanders away wondering just how much the regression tests exercise
holdable cursors.)
And the answer is they're not testing this code path at all, because if
you do
DECLARE c CURSOR WITH HOLD FOR ...
FETCH ALL FROM c;
Hi Group,
I'm using PG 9.1.9 with a client application using various versions of the
pgsqlODBC driver on Windows. Cursors are used heavily, as well as some
pretty heavy trigger queries on db writes which update several materialized
views.
The server has 48GB RAM installed, PG is configured for
Joshua Berry escribió:
gdb /usr/pgsql-9.1/bin/postmaster -c core.17356
[...loading/reading symbols...]
Core was generated by `postgres: [username] [databasename]
[client_ipaddress](1500) SELECT '.
Program terminated with signal 11, Segmentation fault.
#0
Hi,
On 2013-04-10 16:34:40 -0500, Joshua Berry wrote:
Below are the relevant details. I'm not terribly savvy with gdb, so please
let me know what else I could/should examine from the core dump, as well as
anything else about the system/configuration.
Kind Regards,
-Joshua
#NB: some info
Hi Andres!
On Wed, Apr 10, 2013 at 4:49 PM, Andres Freund and...@2ndquadrant.comwrote:
Could you show the output of 'bt full'?
Program terminated with signal 11, Segmentation fault.
#0 ResourceOwnerEnlargeCatCacheRefs (owner=0x0) at resowner.c:605
605 if (owner-ncatrefs
On 2013-04-10 16:53:12 -0500, Joshua Berry wrote:
#7 0x00638c78 in PortalRun (portal=0x2aa9360, count=10,
isTopLevel=1 '\001', dest=0x2a50c40, altdest=0x2a50c40,
completionTag=0x7fffd193d0f0 ) at pquery.c:787
save_exception_stack = 0x7fffd193cfe0
Ok, so while we have a valid resource owner up to here, portal-resonwer
is NULL.
Could you 'up' until youre in this frame and then do 'print *portal'?
#7 0x00638c78 in PortalRun (portal=0x2aa9360, count=10,
isTopLevel=1 '\001', dest=0x2a50c40, altdest=0x2a50c40,
Andres Freund and...@2ndquadrant.com writes:
Ok, so while we have a valid resource owner up to here, portal-resonwer
is NULL.
Yeah, that's what I'm guessing. Given the exposed reference to a cursor
WITH HOLD, it seems likely that the reason the portal has no resowner
is that
I wrote:
(Wanders away wondering just how much the regression tests exercise
holdable cursors.)
And the answer is they're not testing this code path at all, because if
you do
DECLARE c CURSOR WITH HOLD FOR ...
FETCH ALL FROM c;
then the second query executes with a portal (and
On 2013-04-10 17:31:09 -0500, Joshua Berry wrote:
Ok, so while we have a valid resource owner up to here, portal-resonwer
is NULL.
Could you 'up' until youre in this frame and then do 'print *portal'?
#7 0x00638c78 in PortalRun (portal=0x2aa9360, count=10,
isTopLevel=1
On 2013-04-10 19:06:12 -0400, Tom Lane wrote:
I wrote:
(Wanders away wondering just how much the regression tests exercise
holdable cursors.)
And the answer is they're not testing this code path at all, because if
you do
DECLARE c CURSOR WITH HOLD FOR ...
FETCH ALL FROM c;
Andres Freund and...@2ndquadrant.com writes:
Tom: It looks to me like printtup_prepare_info won't normally be called
in an held cursor. But if some concurrent DDL changed the number of
columns in typeinfo vs thaose in the the receiver that could explain the
issue and why its not seen all the
Ok, I might be seeing whats going on here. Could you go to 'printtup'
and print *myState, *myState-attrinfo, *typpeinfo?
#4 0x004593c4 in printtup (slot=0x2d14618, self=0x2a50c40)
at printtup.c:297
297 printtup_prepare_info(myState, typeinfo, natts);
(gdb)
On 2013-04-10 18:25:24 -0500, Joshua Berry wrote:
Ok, I might be seeing whats going on here. Could you go to 'printtup'
and print *myState, *myState-attrinfo, *typpeinfo?
#4 0x004593c4 in printtup (slot=0x2d14618, self=0x2a50c40)
at printtup.c:297
297
Andres Freund and...@2ndquadrant.com writes:
On 2013-04-10 19:06:12 -0400, Tom Lane wrote:
And the answer is they're not testing this code path at all, because if
you do
DECLARE c CURSOR WITH HOLD FOR ...
FETCH ALL FROM c;
then the second query executes with a portal (and resource owner)
On 2013-04-10 19:06:12 -0400, Tom Lane wrote:
I wrote:
(Wanders away wondering just how much the regression tests exercise
holdable cursors.)
And the answer is they're not testing this code path at all, because if
you do
DECLARE c CURSOR WITH HOLD FOR ...
FETCH ALL FROM c;
Hm. Make that a
print *(DR_printtup *) self
print *((DR_printtup *) self)-attrinfo
print *slot-tts_tupleDescriptor
(gdb) print *(DR_printtup *) self
$2 = {pub = {receiveSlot = 0x459390 printtup,
rStartup = 0x459550 printtup_startup,
rShutdown = 0x458a20 printtup_shutdown,
rDestroy
On 2013-04-10 19:29:06 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-04-10 19:06:12 -0400, Tom Lane wrote:
And the answer is they're not testing this code path at all, because if
you do
DECLARE c CURSOR WITH HOLD FOR ...
FETCH ALL FROM c;
then the second
22 matches
Mail list logo
