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
Lauris Ulmanis wrote:
> The following bug has been logged online:
>
> Bug reference: 4919
> Logged by: Lauris Ulmanis
> Email address: lauris.ulma...@mykoob.com
> PostgreSQL version: 8.3.7, 8.4.0
> Operating system: Any
> Description:CREATE USER command slows down syst
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
On Tuesday 14 July 2009 15:37:31 Joshua Tolley wrote:
> On Tue, Jul 14, 2009 at 01:28:30PM +, Michael Gould wrote:
> > I can see why people use case sensitive searches but it would be nice if
> > there was either a setup option in the init program or a encoding and
> > locale that would allow f
The following bug has been logged online:
Bug reference: 4919
Logged by: Lauris Ulmanis
Email address: lauris.ulma...@mykoob.com
PostgreSQL version: 8.3.7, 8.4.0
Operating system: Any
Description:CREATE USER command slows down system performance
Details:
When user c
Hi Tom,
you are right, it's an RC I was running on.
Sorry...
Frank
www.biotronik.com
BIOTRONIK GmbH & Co. KG
Woermannkehre 1, 12359 Berlin, Germany
Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRA 6501
Vertreten durch ihre Komplementärin:
BIOTRONIK Mess- und Therapiegeräte Gm
On Tue, Jul 14, 2009 at 01:28:30PM +, Michael Gould wrote:
> I can see why people use case sensitive searches but it would be nice if
> there was either a setup option in the init program or a encoding and locale
> that would allow for case insenstive searches without having to use a
> non-stan
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
Dnia 13-07-2009 o 19:58:50 Craig Ringer
napisał(a):
(Please reply to the list, not just to me)
I'm sorry.
I'd still like to know how you're setting your client encoding. You
can't just run "SET client_encoding='win1250'" - you must tell the
client program, or the terminal it runs in, to
The following bug has been logged online:
Bug reference: 4920
Logged by: Michael Gould
Email address: mgo...@intermodalsoftwaresolutions.net
PostgreSQL version: all
Operating system: Windows 2008 Server
Description:need case-insensitive searches
Details:
I can see w
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 ()
22 matches
Mail list logo
