Craig Ringer writes:
> David E. Wheeler wrote:
>> Found in 8.4.2, replicated in HEAD. Steps:
>>
>> 1. Create PL/Perl function.
>> 2. Run it.
>> 3. Create same function with PL/PerlU
>> 4. Run it.
>> 5. Create same function again with PL/Perl
>> 6. Boom.
> This was just discussed in -HACKERS. Hav
David E. Wheeler wrote:
> Found in 8.4.2, replicated in HEAD. Steps:
>
> 1. Create PL/Perl function.
> 2. Run it.
> 3. Create same function with PL/PerlU
> 4. Run it.
> 5. Create same function again with PL/Perl
> 6. Boom.
This was just discussed in -HACKERS. Have a look at the archives.
--
Crai
Bruce Momjian writes:
> Tom Lane wrote:
>> But we force those to be the same in main.c. Anyway there are several
>> other uses of access() in the code ...
> Yea, I am not saying the text is right, but rather why it was not
> considered for use in that case.
Actually, since that code has been un
Tom Lane wrote:
> Bruce Momjian writes:
> > I think access's reputation as something to avoid caused us not to look
> > at it. My old BSD manual says about access():
>
> > CAVEAT
> > The access() function should be used rarely, if ever. Specifically,
> > access() should never be used
Bruce Momjian writes:
> I think access's reputation as something to avoid caused us not to look
> at it. My old BSD manual says about access():
> CAVEAT
> The access() function should be used rarely, if ever. Specifically,
> access() should never be used by any program whose user real
Tom Lane wrote:
> "James Bellinger" writes:
> > I'm not certain of the actual *purpose* for this function even checking in
> > the first place, but the result is that, if Postgres gets its access via an
> > ACL, it will say 'invalid binary' here and there, will not be able to find
> > its own exec
Sorry for the delay.
I am attempting to construct a JDBC test case that reproduces the problem.
I have installed the patch and have not seen the crash since.
On Jan 13, 2010, at 11:58 AM, Tom Lane wrote:
> I wrote:
>> After puzzling over this for many hours, I have a theory that seems to
>> fi
"James Bellinger" writes:
> I'm not certain of the actual *purpose* for this function even checking in
> the first place, but the result is that, if Postgres gets its access via an
> ACL, it will say 'invalid binary' here and there, will not be able to find
> its own executables, etc. I can see no
The following bug has been logged online:
Bug reference: 5275
Logged by: James Bellinger
Email address: j...@zer7.com
PostgreSQL version: 8.4.2
Operating system: Ubuntu 9.10
Description:validate_exec in port/exec.c only reads u/g/o, not ACLs
Details:
Howdy,
I'm not
The following bug has been logged online:
Bug reference: 5274
Logged by: Vincenzo Romano
Email address: vincenzo.rom...@notorand.it
PostgreSQL version: 8.4.2
Operating system: Linux
Description:[PL/PgSQL] EXECUTE ... USING variable expansion
Details:
My system says:
Found in 8.4.2, replicated in HEAD. Steps:
1. Create PL/Perl function.
2. Run it.
3. Create same function with PL/PerlU
4. Run it.
5. Create same function again with PL/Perl
6. Boom.
Example on HEAD built today (ignore the error from the plperl version, that's
the issue I'm trying to fix locally
Tom Lane wrote:
> "Kevin Grittner" writes:
>> This looks like another situation where we're running into
>> trouble because of non-standard behavior when people might be
>> expecting something consistent with other products and the
>> explicit language in the standard.
>
> If we were to change
"Kevin Grittner" writes:
> Tom Lane wrote:
>> What's the data type of the value being compared to? I get, for
>> instance,
>>
>> postgres=# select substr('ab '::char(4), 1, 4) = 'ab '::char(4);
> This looks like another situation where we're running into trouble
> because of non-standard be
I wrote:
> After puzzling over this for many hours, I have a theory that seems to
> fit the facts.
I think the attached patch will fix it for you --- please test.
regards, tom lane
Index: src/backend/utils/cache/plancache.c
What postgres version?
In any case there is not enough information here to identify what
happened. What does "not all key references had been cleaned up" mean?
What commands did you run and what results did they have?
On Tue, Jan 12, 2010 at 4:26 PM, Ted Clark wrote:
> BUG #2197: PostgreSQL erro
Tom Lane wrote:
> What's the data type of the value being compared to? I get, for
> instance,
>
> postgres=# select substr('ab '::char(4), 1, 4) = 'ab '::char(4);
> ?column?
> --
> t
> (1 row)
This looks like another situation where we're running into trouble
because of non-stan
"Charles O'Farrell" writes:
> We have a column 'foo' which is of type character (not varying).
> select substr(foo, 1, 10) from bar
> The result of this query are values whose trailing spaces have been trimmed
> automatically. This causes incorrect results when comparing to a value that
> may co
2010/1/13 Pavel Stehule :
> Hello
>
> 2010/1/13 Charles O'Farrell :
>> Hi guys,
>>
>> I'm not sure whether this a really dumb question, but I'm curious as to what
>> might be the problem.
>>
>> We have a column 'foo' which is of type character (not varying).
>>
>> select substr(foo, 1, 10) from bar
Hello
2010/1/13 Charles O'Farrell :
> Hi guys,
>
> I'm not sure whether this a really dumb question, but I'm curious as to what
> might be the problem.
>
> We have a column 'foo' which is of type character (not varying).
>
> select substr(foo, 1, 10) from bar
>
> The result of this query are value
Hi guys,
I'm not sure whether this a really dumb question, but I'm curious as to what
might be the problem.
We have a column 'foo' which is of type character (not varying).
select substr(foo, 1, 10) from bar
The result of this query are values whose trailing spaces have been trimmed
automatical
20 matches
Mail list logo
