(2013/06/12 0:03), Tom Lane wrote:
> Hiroshi Inoue 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.
1. Implement
Hiroshi Inoue 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 subscription:
h
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 has
| 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 12GB
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
On 2013-04-10 19:29:06 -0400, Tom Lane wrote:
> Andres Freund 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
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 ,
rStartup = 0x459550 ,
rShutdown = 0x458a20 ,
rDestroy = 0x458a10 , mydest = DestRemoteExec
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
Andres Freund 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)
>> created to e
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
> 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) p
Andres Freund 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 time, right?
It loo
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
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,
> i
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
Andres Freund 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 PreCommit_Portals() got rid of it when
> 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,
complet
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
> save_co
Hi Andres!
On Wed, Apr 10, 2013 at 4:49 PM, Andres Freund wrote:
> 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 < owner->maxcatrefs)
(gdb) bt
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: som
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 ResourceOwnerEnla
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 12
22 matches
Mail list logo
