The following bug has been logged on the website:
Bug reference: 7827
Logged by: Badiu Razvan
Email address: electricbo...@yahoo.com
PostgreSQL version: 8.4.1
Operating system: Windows 7 ultimate
Description:
I have a problem with posgresql 8.4, yesterday when I tried
Alvaro Herrera writes:
> I disagree with this assessment, and propose the attached patch instead.
+1 for this approach in HEAD ...
> This is the patch for the master branch; I have not tried to backpatch
> it yet. Conflicts are expected due to the refactoring of ALTER commands
> by KaiGai.
...
Andres Freund writes:
> On 2013-01-25 17:07:59 -0500, Tom Lane wrote:
>> Neither version of gcc I tried complained about this, and I assume yours
>> didn't either, which is a bit annoying/scary. I wonder whether the
>> "volatile" marker prevents that?
> I think the control flow is just to comple
On 2013-01-25 17:07:59 -0500, Tom Lane wrote:
> Andres Freund writes:
> > The bug got introduced in 46211da1b84bc3537e799ee1126098e71c2428e8 which
> > interestingly says "Using HTABs instead of Python dictionaries makes
> > error recovery easier, and allows for procedures to be cached based on
> >
On Fri, Jan 25, 2013 at 2:01 PM, Peter Eisentraut wrote:
> On 1/25/13 1:35 AM, Kevin Grittner wrote:
>> Peter, do you have a version that works with 9.3?
>
> I don't, but it shouldn't be hard for someone more up to date with the
> internal WAL addressing changes.
I've been thinking about that. S
Andres Freund writes:
> The bug got introduced in 46211da1b84bc3537e799ee1126098e71c2428e8 which
> interestingly says "Using HTABs instead of Python dictionaries makes
> error recovery easier, and allows for procedures to be cached based on
> their OIDs, not their names." - but the caching seems t
On 1/25/13 1:35 AM, Kevin Grittner wrote:
> Peter, do you have a version that works with 9.3?
I don't, but it shouldn't be hard for someone more up to date with the
internal WAL addressing changes.
> Given that we're past the start of the last CF, do we still want to
> consider including it? If y
On 2013-01-25 15:40:46 -0500, Tom Lane wrote:
> Andres Freund writes:
> > quite possibly doesn't work if copied from here but for quicker viewing:
>
> > CREATE OR REPLACE FUNCTION "foo():
> > pass
>
> > import os
> > os._exit(1)
> > def "() RETURNS void LANGUAGE plpythonu AS $$pass$$;
>
> >
Andres Freund writes:
> quite possibly doesn't work if copied from here but for quicker viewing:
> CREATE OR REPLACE FUNCTION "foo():
> pass
> import os
> os._exit(1)
> def "() RETURNS void LANGUAGE plpythonu AS $$pass$$;
> Yep:
> LOG: server process (PID 29317) exited with exit code 1
On 2013-01-25 21:07:51 +0100, Andres Freund wrote:
> On 2013-01-25 14:51:39 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > Its slightly more complex than just making it one hash table with an
> > > extended key. When validating a trigger function we don't have a
> > > relation to do the ca
Alvaro Herrera escribió:
> On the other hand, running REASSIGN OWNED means to reassign ownership of
> objects to some other user. There is no reason this cannot be done to
> shared objects as well as local objects. I note, though, that REASSIGN
> OWNED's documentation mentions "objects in the cu
On 2013-01-25 14:51:39 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Its slightly more complex than just making it one hash table with an
> > extended key. When validating a trigger function we don't have a
> > relation to do the cache lookup. I chose to handle that case by not
> > doing a ca
Jeff Janes escribió:
> Since back-branch releases are coming up, I think fe3b5eb08 and it's
> analogues in all branches should be reverted.
>
> The issue it was intended to solve was not really a bug in the first place,
> and this patch didn't solve it anyway. But it introduced new behavior (into
Andres Freund writes:
> Its slightly more complex than just making it one hash table with an
> extended key. When validating a trigger function we don't have a
> relation to do the cache lookup. I chose to handle that case by not
> doing a cache lookup at all in that case which imo is a sensible
>
On 2013-01-24 11:40:33 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-01-24 15:03:36 +0100, Sandro Santilli wrote:
> > ISTM the caching code for plpythonu trigger functions has been broken
> > for some time. The bug seem to be that PLy_procedure_get looks up the
> > function in a separ
On Sun, Jan 20, 2013 at 4:59 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> + PGresult *res = ExecuteSqlQueryForSingleRow(fout, "SELECT
>> pg_is_in_recovery()");
>
> That function call needs to be schema-qualified for security.
Applied and backpatched, with that fix and a sentence
16 matches
Mail list logo
