[COMMITTERS] pgsql: Use .NOTPARALLEL in ecpg/Makefile to avoid a gmake parallelism b
Use .NOTPARALLEL in ecpg/Makefile to avoid a gmake parallelism bug. Investigation shows that some intermittent build failures in ecpg are the result of a gmake bug that was reported quite some time ago: http://savannah.gnu.org/bugs/?30653 Preventing parallel builds of the ecpg subdirectories seems to dodge the bug. Per yesterday's pgsql-hackers discussion, there are some other things in the subdirectory makefiles that seem rather unsafe for parallel builds too, but there's little point in fixing them as long as we have to work around a make bug. Back-patch to 9.1; parallel builds weren't very well supported before that anyway. Branch -- REL9_1_STABLE Details --- http://git.postgresql.org/pg/commitdiff/1e214507e5b5d604ea8d8d4e7e564b673df8c8e0 Modified Files -- src/interfaces/ecpg/Makefile |8 1 files changed, 8 insertions(+), 0 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Use .NOTPARALLEL in ecpg/Makefile to avoid a gmake parallelism b
Use .NOTPARALLEL in ecpg/Makefile to avoid a gmake parallelism bug. Investigation shows that some intermittent build failures in ecpg are the result of a gmake bug that was reported quite some time ago: http://savannah.gnu.org/bugs/?30653 Preventing parallel builds of the ecpg subdirectories seems to dodge the bug. Per yesterday's pgsql-hackers discussion, there are some other things in the subdirectory makefiles that seem rather unsafe for parallel builds too, but there's little point in fixing them as long as we have to work around a make bug. Back-patch to 9.1; parallel builds weren't very well supported before that anyway. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/843363b8d59e685b57a2f88c864a7041d44ffc06 Modified Files -- src/interfaces/ecpg/Makefile |8 1 files changed, 8 insertions(+), 0 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Use .NOTPARALLEL in ecpg/Makefile to avoid a gmake parallelism b
Use .NOTPARALLEL in ecpg/Makefile to avoid a gmake parallelism bug. Investigation shows that some intermittent build failures in ecpg are the result of a gmake bug that was reported quite some time ago: http://savannah.gnu.org/bugs/?30653 Preventing parallel builds of the ecpg subdirectories seems to dodge the bug. Per yesterday's pgsql-hackers discussion, there are some other things in the subdirectory makefiles that seem rather unsafe for parallel builds too, but there's little point in fixing them as long as we have to work around a make bug. Back-patch to 9.1; parallel builds weren't very well supported before that anyway. Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/af3de2d19ec65216737192b8cdd948331c3f2e80 Modified Files -- src/interfaces/ecpg/Makefile |8 1 files changed, 8 insertions(+), 0 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Make plperl safe against functions that are redefined while runn
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/59f23fe8d4eb0b95f029eaffdbcadc59d51f45cc Modified Files -- src/pl/plperl/expected/plperl.out | 18 ++ src/pl/plperl/plperl.c| 104 + src/pl/plperl/sql/plperl.sql | 10 3 files changed, 99 insertions(+), 33 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Make plperl safe against functions that are redefined while runn
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches. Branch -- REL8_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/4da51c25a505b09b2e312953da97502111a8c69e Modified Files -- src/pl/plperl/expected/plperl.out | 18 +++ src/pl/plperl/plperl.c| 95 +--- src/pl/plperl/sql/plperl.sql | 10 3 files changed, 94 insertions(+), 29 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Make plperl safe against functions that are redefined while runn
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches. Branch -- REL9_0_STABLE Details --- http://git.postgresql.org/pg/commitdiff/0952811c86ad64d016d91ced0d8f2a78ce3acda2 Modified Files -- src/pl/plperl/expected/plperl.out | 18 ++ src/pl/plperl/plperl.c| 104 + src/pl/plperl/sql/plperl.sql |9 +++ 3 files changed, 98 insertions(+), 33 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Make plperl safe against functions that are redefined while runn
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches. Branch -- REL8_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/dc447e1515941c8edc51fabcd318f7b1311dd1e8 Modified Files -- src/pl/plperl/expected/plperl.out | 18 +++ src/pl/plperl/plperl.c| 95 +--- src/pl/plperl/sql/plperl.sql | 10 3 files changed, 94 insertions(+), 29 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Make plperl safe against functions that are redefined while runn
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches. Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/81ead89ee152e5381aec0cf7352e5fa131a6c336 Modified Files -- src/pl/plperl/expected/plperl.out | 18 ++ src/pl/plperl/plperl.c| 104 + src/pl/plperl/sql/plperl.sql | 10 3 files changed, 99 insertions(+), 33 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Make plperl safe against functions that are redefined while runn
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches. Branch -- REL9_1_STABLE Details --- http://git.postgresql.org/pg/commitdiff/ef06dca97504cda3cff852314532338c86d3ccc5 Modified Files -- src/pl/plperl/expected/plperl.out | 18 ++ src/pl/plperl/plperl.c| 104 + src/pl/plperl/sql/plperl.sql | 10 3 files changed, 99 insertions(+), 33 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
