2009/7/15 Frank van Vugt :
> Hi Tom,
> Yep, after applying it yesterday evening, we didn't see this problem at all
> today, so it definitely looks as if this patch nailed it.
> Thanks for the [great|quick] support !
I confirm that too - no errors after applying the patch. Great work
Tom, thanks
Hi Tom,
Op dinsdag 14 juli 2009, schreef Tom Lane:
> I think the attached patch will fix it for you.
Yep, after applying it yesterday evening, we didn't see this problem at all
today, so it definitely looks as if this patch nailed it.
Thanks for the [great|quick] support !
--
Best,
Fra
2009/7/14 Tom Lane :
> Tom Lane wrote:
I've applied the patch - I hope it will fix our problem. I will ask
users of our application to do those things they did when the error
was thrown. Thanks a lot Tom.
ML
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
Heikki Linnakangas writes:
> Tom Lane wrote:
>> [ looks at CVS logs ... ] Another case that will cause plan
>> invalidation in 8.4 and not 8.3 is creating or dropping a schema.
>> Do you do a lot of that?
> Hmm, he says he uses temporary tables. Does creating/dropping a
> temporary namespace tri
Alvaro Herrera writes:
> Tom Lane wrote:
>> I'm convinced that 8.3 has the same bug, in the sense that it could fail
>> this way if it had to revalidate a cached plan. Probably the reason you
>> didn't see it before is that 8.4 has more conditions in which it will
>> invalidate cached plans. In
Frank van Vugt writes:
> I'd also like to mention still our C-trigger. :
> - it starts of with three plan variables containing '0' and it uses
> SPI_saveplan() to fill these with a cached plan
> - the three underlying tables will never change structure during such a
> session, so I expecte
Tom Lane wrote:
> [ looks at CVS logs ... ] Another case that will cause plan
> invalidation in 8.4 and not 8.3 is creating or dropping a schema.
> Do you do a lot of that?
Hmm, he says he uses temporary tables. Does creating/dropping a
temporary namespace trigger plan cache invalidation?
--
Tom Lane wrote:
> I'm convinced that 8.3 has the same bug, in the sense that it could fail
> this way if it had to revalidate a cached plan. Probably the reason you
> didn't see it before is that 8.4 has more conditions in which it will
> invalidate cached plans. In particular, is it possible th
Hi,
> I think the attached patch will fix it for you.
Great, thanks!
I'll apply this tonight, will get back with results tomorrow.
--
Best,
Frank.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
Hi,
> I'm convinced that 8.3 has the same bug, in the sense that it could fail
> this way if it had to revalidate a cached plan. Probably the reason you
> didn't see it before is that 8.4 has more conditions in which it will
> invalidate cached plans.
Ok
> In particular, is it possible that thi
I think the attached patch will fix it for you.
regards, tom lane
Index: src/backend/utils/cache/plancache.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/cache/plancache.c,v
retrieving revision 1.27
diff -c
Frank van Vugt writes:
>> Hmph. So evidently the unexpected recursion into SPI is happening when
>> a cached plan has to be recomputed. I suspected something of the sort,
>> but now the question is why you didn't see the same problem in 8.3 ...
> Just as an additional confirmation: nothing else
Hi,
> Hmph. So evidently the unexpected recursion into SPI is happening when
> a cached plan has to be recomputed. I suspected something of the sort,
> but now the question is why you didn't see the same problem in 8.3 ...
Just as an additional confirmation: nothing else but the db changed when
Frank van Vugt writes:
> [ backtrace ]
Hmph. So evidently the unexpected recursion into SPI is happening when
a cached plan has to be recomputed. I suspected something of the sort,
but now the question is why you didn't see the same problem in 8.3 ...
regards, tom lane
2009/7/14 Frank van Vugt :
> Basically the flow is as follows:
> You can quit gdb by a plain -c, just confirm when it asks you to detach.
> The backend will continue to run, your app should now show the error.
Thanks.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make change
2009/7/14 Frank van Vugt :
> Hi,
>
>> This is a normal interbackend communication signal. You need to
>> configure gdb to ignore SIGUSR2 (ie, pass it on and not stop execution).
>> Probably SIGUSR1 too.
Frank,
thanks for letting me know about your post - I didn't have time yet to
read yesterday po
Hi Marek,
> Could you please send me gdb
> commands - I could also provide the backtrace
Basically the flow is as follows:
- identify the backend that you expect to run in to this error by pid
- start gdb with the option "-p " to attach to this backend
- set a conditional breakpoint:
b
Hi,
> This is a normal interbackend communication signal. You need to
> configure gdb to ignore SIGUSR2 (ie, pass it on and not stop execution).
> Probably SIGUSR1 too.
Done.
Here's the result:
Breakpoint 1, 0x0054aec0 in SPI_connect ()
(gdb) bt
#0 0x0054aec0 in SPI_connect ()
Frank van Vugt writes:
> Just fyi, a breakpoint at SPI_connect with condition
> _SPI_curid != _SPI_connected
Right, that's what to look for.
> produced the following backtrace:
> Program received signal SIGUSR2, User defined signal 2.
> 0x2b539af2b5f5 in recv () from /lib64/libc.so.6
Hi Tom,
Op maandag 13 juli 2009, schreef Tom Lane:
> Frank van Vugt writes:
> > Any clues as to how to gather additional information that might bring us
> > closer to a solution is appreciated also.
>
> A stack trace from the point of the error would probably tell us a great
> deal. Maybe you co
Frank van Vugt writes:
> Any clues as to how to gather additional information that might bring us
> closer to a solution is appreciated also.
A stack trace from the point of the error would probably tell us a great
deal. Maybe you could attach to a backend with gdb, set a breakpoint
at the fail
21 matches
Mail list logo
