[BUGS] Substring auto trim
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 automatically. This causes incorrect results when comparing to a value that may contain trailing spaces. select * from bar where substr(foo, 1, 4) = 'AB ' I should mention that we normally run Oracle and DB2 (and have done for many years), but I have been pushing for Postgres as an alternative. Fortunately this is all handled through Hibernate, and so for now I have wrapped the substr command in rpad which seems to do the trick. Any light you can shed on this issue would be much appreciated. Cheers, Charles O'Farrell PostgreSQL 8.4.2 on i486-pc-linux-gnu, compiled by GCC gcc-4.4.real (Ubuntu 4.4.1-4ubuntu8) 4.4.1, 32-bit
Re: [BUGS] Substring auto trim
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 values whose trailing spaces have been trimmed > automatically. This causes incorrect results when comparing to a value that > may contain trailing spaces. > > select * from bar where substr(foo, 1, 4) = 'AB ' > You have to write C function substr for type "any" :( Because "char" and char(n) are two different types, and you cannot to write function for char(n) > I should mention that we normally run Oracle and DB2 (and have done for many > years), but I have been pushing for Postgres as an alternative. > Fortunately this is all handled through Hibernate, and so for now I have > wrapped the substr command in rpad which seems to do the trick. > > Any light you can shed on this issue would be much appreciated. > Function substr has first parameter of type "text". When pg call this function, then it does conversion from char(x) to text. Regards Pavel Stehule > Cheers, > > Charles O'Farrell > > PostgreSQL 8.4.2 on i486-pc-linux-gnu, compiled by GCC gcc-4.4.real (Ubuntu > 4.4.1-4ubuntu8) 4.4.1, 32-bit > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Substring auto trim
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
>>
>> 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 contain trailing spaces.
>>
>> select * from bar where substr(foo, 1, 4) = 'AB '
>>
>
> You have to write C function substr for type "any" :( Because "char"
> and char(n) are two different types, and you cannot to write function
> for char(n)
>
>
>> I should mention that we normally run Oracle and DB2 (and have done for many
>> years), but I have been pushing for Postgres as an alternative.
>> Fortunately this is all handled through Hibernate, and so for now I have
>> wrapped the substr command in rpad which seems to do the trick.
>>
>> Any light you can shed on this issue would be much appreciated.
>>
I thing, so there is workaround,
create or replace function substr(character, int, int) returns character as $$
select substr($1::cstring::text,$2,$3)
$$ language sql;
postgres=# create table f(a character(5));
CREATE TABLE
postgres=# insert into f values('a'),('ab'),('abc');
INSERT 0 3
postgres=# select * from f;
a
---
a
ab
abc
(3 rows)
postgres=# select * from f where substr(a,1,3) = 'a ';
a
---
a
(1 row)
postgres=# select * from f where substr(a,1,3) = 'ab ';
a
---
ab
(1 row)
Regards
Pavel Stehule
>
> Function substr has first parameter of type "text". When pg call this
> function, then it does conversion from char(x) to text.
>
> Regards
> Pavel Stehule
>
>
>> Cheers,
>>
>> Charles O'Farrell
>>
>> PostgreSQL 8.4.2 on i486-pc-linux-gnu, compiled by GCC gcc-4.4.real (Ubuntu
>> 4.4.1-4ubuntu8) 4.4.1, 32-bit
>>
>
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Substring auto trim
"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 contain trailing spaces.
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)
The actual value coming out of the substr() is indeed just 'ab',
but that ought to be considered equal to 'ab ' anyway in char(n)
semantics.
Postgres considers that trailing blanks in a char(n) value are
semantically insignificant, so it strips them when converting to a type
where they would be significant (ie, text or varchar). What's happening
in this scenario is that substr() is defined to take and return text,
so the stripping happens before substr ever sees it.
As Pavel noted, you could possibly work around this particular case by
defining a variant of substr() that takes and returns char(n), but on
the whole I'd strongly advise switching over to varchar/text if
possible. The semantics of char(n) are so weird/braindamaged that
it's best avoided.
BTW, if you do want to use the workaround, this seems sufficient:
create function substr(char,int,int) returns char
strict immutable language internal as 'text_substr' ;
It's the same C code, you're just avoiding the coercion on input.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Substring auto trim
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-standard behavior when people might be expecting
something consistent with other products and the explicit language
in the standard.
Quoting from section 5.3 of "WG3:HBA-003 H2-2003-305 August, 2003
(ISO-ANSI Working Draft) Foundation (SQL/Foundation)":
| 13) The declared type of a is
| fixed-length character string. The length of a is the number of s
| that it contains. Each contained in represents a single in both the value
| and the length of the . The two
| s contained in a shall not be separated
| by any .
|
| NOTE 72 * s are allowed to be
| zero-length strings (i.e., to contain no characters) even
| though it is not permitted to declare a that is
| CHARACTER with 0 (zero).
Based on that, the cast of the literals to char(4) in your example
should not be needed. I don't know if there's any reasonable fix
or if this should be handled with a doc change or FAQ entry.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #2197: PostgreSQL error- 'could not read block 0 of relation'
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 error- 'could not read block 0 of relation' > > I found this bug has nothing to do with hardware. I was attemping to copy > large amounts of data from text files into tables with a primary and many > foreign keys. I found that upon truncating the tables not all key > references had been cleaned up by the database asa they had been in prior > day successful runs. After truncating all tables with a truncate table > xx cascade and then loading back into the same table, my problem was > resolved. > > -Ted > -- greg -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5269: postgres backend terminates with SIGSEGV
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
===
RCS file: /cvsroot/pgsql/src/backend/utils/cache/plancache.c,v
retrieving revision 1.27.2.1
diff -c -r1.27.2.1 plancache.c
*** src/backend/utils/cache/plancache.c 14 Jul 2009 15:37:55 - 1.27.2.1
--- src/backend/utils/cache/plancache.c 13 Jan 2010 16:46:07 -
***
*** 1050,1063
void
ResetPlanCache(void)
{
! ListCell *lc;
! foreach(lc, cached_plans_list)
{
! CachedPlanSource *plansource = (CachedPlanSource *) lfirst(lc);
CachedPlan *plan = plansource->plan;
! if (plan)
! plan->dead = true;
}
}
--- 1050,1106
void
ResetPlanCache(void)
{
! ListCell *lc1;
! foreach(lc1, cached_plans_list)
{
! CachedPlanSource *plansource = (CachedPlanSource *) lfirst(lc1);
CachedPlan *plan = plansource->plan;
+ ListCell *lc2;
! /* No work if it's already invalidated */
! if (!plan || plan->dead)
! continue;
!
! /*
! * We *must not* mark transaction control statements as dead,
! * particularly not ROLLBACK, because they may need to be executed in
! * aborted transactions when we can't revalidate them (cf bug #5269).
! * In general there is no point in invalidating utility statements
! * since they have no plans anyway. So mark it dead only if it
! * contains at least one non-utility statement.
! */
! if (plan->fully_planned)
! {
! /* Search statement list for non-utility statements */
! foreach(lc2, plan->stmt_list)
! {
! PlannedStmt *plannedstmt = (PlannedStmt *) lfirst(lc2);
!
! Assert(!IsA(plannedstmt, Query));
! if (IsA(plannedstmt, PlannedStmt))
! {
! /* non-utility statement, so invalidate */
! plan->dead = true;
! break; /* out of stmt_list scan */
! }
! }
! }
! else
! {
! /* Search Query list for non-utility statements */
! foreach(lc2, plan->stmt_list)
! {
! Query *query = (Query *) lfirst(lc2);
!
! Assert(IsA(query, Query));
! if (query->commandType != CMD_UTILITY)
! {
! /* non-utility statement, so invalidate */
! plan->dead = true;
! break; /* out of stmt_list scan */
! }
! }
! }
}
}
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Substring auto trim
"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 behavior when people might be expecting
> something consistent with other products and the explicit language
> in the standard.
If we were to change that so that 'ab ' were implicitly typed as
char(4), then we'd start getting bug reports from people complaining
that "select 'ab' = 'ab '" yields true. I remain of the opinion that
char(n) is so hopelessly brain-damaged that we should be very careful
to NOT bring it into our mainstream behavior.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Substring auto trim
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 that so that 'ab ' were implicitly typed as > char(4), then we'd start getting bug reports from people > complaining that "select 'ab' = 'ab '" yields true. I remain of > the opinion that char(n) is so hopelessly brain-damaged that we > should be very careful to NOT bring it into our mainstream > behavior. I'm inclined to agree with you, but it does present a barrier to those migrating. Are there any "migration considerations" documents where we should mention this? Standards compliance notes in the docs? Some form of this question seems to be asked frequently -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Termination When Switching between PL/Perl and PL/PerlU
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):
postgres=# create or replace function wtf(text) returns text language plperl as
'shift';
CREATE FUNCTION
Time: 151.054 ms
postgres=# select wtf('hey');
ERROR: invalid byte sequence for encoding "UTF8": 0x00
CONTEXT: PL/Perl function "wtf"
postgres=# create or replace function wtf(text) returns text language plperlu
as 'shift';
CREATE FUNCTION
Time: 41.255 ms
postgres=# select wtf('hey');
wtf
-
hey
(1 row)
Time: 0.523 ms
postgres=# create or replace function wtf(text) returns text language plperl as
'shift';
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5274: [PL/PgSQL] EXECUTE ... USING variable expansion
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: ~ lsb_release -a LSB Version: :core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:desktop-3.1-a md64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch Distributor ID: Fedora Description:Fedora release 12 (Constantine) Release:12 Codename: Constantine If you try the following: CREATE TABLE test ( i INT ); CREATE OR REPLACE FUNCTION func() RETURNS void LANGUAGE plpgsql AS $function$ DECLARE e TEXT; t TEXT; i INT; BEGIN i := 42; t := 'answer'; EXECUTE 'SELECT $1' INTO e USING t; RAISE INFO '%',e; EXECUTE 'ALTER TABLE test ALTER COLUMN i SET DEFAULT $1' USING i; END; $function$; SELECT func(); The first EXECUTE...USING replaces the variable $1 with the value of the variable "t". The first output line reads: INFO: answer The second EXECUTE...USING doesn't do the replacement and triggers an error: ERROR: there is no parameter $1 CONTEXT: SQL statement "ALTER TABLE test ALTER COLUMN i SET DEFAULT $1" PL/pgSQL function "func" line 10 at EXECUTE statement -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5275: validate_exec in port/exec.c only reads u/g/o, not ACLs
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 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 purpose for this function. That said, currently, the reason it gives these errors is that it only checks user/group/other. Linux ACLs are not checked. If this function really needs to exist as is, this ought to be fixed. Thanks James -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5275: validate_exec in port/exec.c only reads u/g/o, not ACLs
"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 purpose for this function. Hmm. I wonder why we have all that complexity at all, rather than using access(2). The man page says it checks against real not effective uid, but since we don't run setuid I think there's no difference. [ pokes in CVS history ... ] Oh, this is interesting: this code looks like this clear back to the original Berkeley import, and back then it had this comment: * We use the effective uid here because the backend will not have * executed setuid() by the time it calls this routine. So once upon a time there was a reason to try to implement access() for ourselves, but it's long gone. Comments? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5269: postgres backend terminates with SIGSEGV
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
>> 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
> ===
> RCS file: /cvsroot/pgsql/src/backend/utils/cache/plancache.c,v
> retrieving revision 1.27.2.1
> diff -c -r1.27.2.1 plancache.c
> *** src/backend/utils/cache/plancache.c 14 Jul 2009 15:37:55 -
> 1.27.2.1
> --- src/backend/utils/cache/plancache.c 13 Jan 2010 16:46:07 -
> ***
> *** 1050,1063
> void
> ResetPlanCache(void)
> {
> ! ListCell *lc;
>
> ! foreach(lc, cached_plans_list)
> {
> ! CachedPlanSource *plansource = (CachedPlanSource *) lfirst(lc);
> CachedPlan *plan = plansource->plan;
>
> ! if (plan)
> ! plan->dead = true;
> }
> }
> --- 1050,1106
> void
> ResetPlanCache(void)
> {
> ! ListCell *lc1;
>
> ! foreach(lc1, cached_plans_list)
> {
> ! CachedPlanSource *plansource = (CachedPlanSource *) lfirst(lc1);
> CachedPlan *plan = plansource->plan;
> + ListCell *lc2;
>
> ! /* No work if it's already invalidated */
> ! if (!plan || plan->dead)
> ! continue;
> !
> ! /*
> ! * We *must not* mark transaction control statements as dead,
> ! * particularly not ROLLBACK, because they may need to be
> executed in
> ! * aborted transactions when we can't revalidate them (cf bug
> #5269).
> ! * In general there is no point in invalidating utility
> statements
> ! * since they have no plans anyway. So mark it dead only if it
> ! * contains at least one non-utility statement.
> ! */
> ! if (plan->fully_planned)
> ! {
> ! /* Search statement list for non-utility statements */
> ! foreach(lc2, plan->stmt_list)
> ! {
> ! PlannedStmt *plannedstmt = (PlannedStmt *)
> lfirst(lc2);
> !
> ! Assert(!IsA(plannedstmt, Query));
> ! if (IsA(plannedstmt, PlannedStmt))
> ! {
> ! /* non-utility statement, so invalidate
> */
> ! plan->dead = true;
> ! break; /* out of stmt_list
> scan */
> ! }
> ! }
> ! }
> ! else
> ! {
> ! /* Search Query list for non-utility statements */
> ! foreach(lc2, plan->stmt_list)
> ! {
> ! Query *query = (Query *) lfirst(lc2);
> !
> ! Assert(IsA(query, Query));
> ! if (query->commandType != CMD_UTILITY)
> ! {
> ! /* non-utility statement, so invalidate
> */
> ! plan->dead = true;
> ! break; /* out of stmt_list
> scan */
> ! }
> ! }
> ! }
> }
> }
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5275: validate_exec in port/exec.c only reads u/g/o, not ACLs
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 executables, etc. I can see no purpose for this function. > > Hmm. I wonder why we have all that complexity at all, rather than using > access(2). The man page says it checks against real not effective uid, > but since we don't run setuid I think there's no difference. > > [ pokes in CVS history ... ] Oh, this is interesting: this code looks > like this clear back to the original Berkeley import, and back then it > had this comment: > > * We use the effective uid here because the backend will not have > * executed setuid() by the time it calls this routine. > > So once upon a time there was a reason to try to implement access() > for ourselves, but it's long gone. Comments? I am not sure of its purpose either. I remember having to call it in the old postmaster code before /port was added, but again, I am not sure why we didn't use access(). 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 and effec- tive IDs, or group real and effective IDs, differ. At best, using access() in this situation can produce a misleading result, because the system call permission checks are based on effective IDs. Thus, access() might return that the file is accessible, when the corresponding open(2) or exec(2) call would fail, or vice-versa. In addition, the permissions on the file, or the path leading to the file, may change between the time access() makes its test and the eventual system call. This timing race applies to all uses of access(), so it is better to attempt the operation itself to see if it will succeed. (Processes designed to run setuid or setgid should call seteuid(2) or setegid(2) as needed to suspend their special privileges.) -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5275: validate_exec in port/exec.c only reads u/g/o, not ACLs
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 and effec- > tive IDs, or group real and effective IDs, differ. But we force those to be the same in main.c. Anyway there are several other uses of access() in the code ... regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5275: validate_exec in port/exec.c only reads u/g/o, not ACLs
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 by any program whose user real and effec- > > tive IDs, or group real and effective IDs, differ. > > 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. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5275: validate_exec in port/exec.c only reads u/g/o, not ACLs
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 untouched since Berkeley days, my bet is that we just never considered changing it at all. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Termination When Switching between PL/Perl and PL/PerlU
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. -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Termination When Switching between PL/Perl and PL/PerlU
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. Have a look at the archives. No, this is something different, because it still crashes even with the fix for that other issue. I see this in the postmaster log: panic: free from wrong pool. LOG: server process (PID 15697) exited with exit code 255 There's no core dump (thank you, perl). The lower-case panic message must be from libperl because PG has no such message. I guess that we probably need to fix this by changing the timing of interpreter switching relative to throwing away the old compiled function ... regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
