Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

On Wed, Dec 7, 2016 at 3:42 PM, Tom Lane wrote: > > > Hmm ... after further experimentation, I still can't get this version of > systemd (231) to do anything evil. It turns out that Fedora ships it with > KillUserProcesses turned off by default, and maybe having that on is a

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

On Wed, Dec 7, 2016 at 1:12 PM, Tom Lane wrote: > But this is all kind of moot if Peter is right that systemd will zap > POSIX shmem along with SysV semaphores. I've been trying to reproduce > the issue on a Fedora 25 installation, and so far I can't get it to > zap

Re: [HACKERS] empty array case in plperl_ref_from_pg_array not handled correctly

On Mon, Mar 7, 2016 at 11:32 PM, Andres Freund wrote: > Hi, > > Per the new valgrind animal we get: > > > http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=skink=2016-03-08%2004%3A22%3A00 > 2016-03-08 05:56:05.566 UTC [56de6971.723:5] LOG: statement: select >

Re: [HACKERS] error message diff with Perl 5.22.0

On Sat, Jun 6, 2015 at 7:03 PM, Peter Eisentraut pete...@gmx.net wrote: With the recently released Perl 5.22.0, the tests fail thus: -ERROR: Global symbol $global requires explicit package name at line 3. -Global symbol $other_global requires explicit package name at line 4. +ERROR: Global

Re: [HACKERS] Precedence of standard comparison operators

On Tue, Mar 10, 2015 at 10:11 AM, Tom Lane t...@sss.pgh.pa.us wrote: I wrote: This thread seems to have died off without any clear resolution. I'd hoped somebody would try the patch on some nontrivial application to see if it broke anything or caused any warnings, but it doesn't seem like

Re: [HACKERS] [BUGS] BUG #9223: plperlu result memory leak

On Wed, Mar 5, 2014 at 12:22 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Can I bug you into verifying what supported releases need this patch, and to which does it backpatch cleanly? And if there's any to which it doesn't, can I further bug you into providing one that does? Sure! Not

Re: [HACKERS] [BUGS] BUG #9223: plperlu result memory leak

On Wed, Mar 5, 2014 at 12:55 PM, Alex Hunsaker bada...@gmail.com wrote: On Wed, Mar 5, 2014 at 12:22 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Can I bug you into verifying what supported releases need this patch, and to which does it backpatch cleanly? And if there's any to which

Re: [HACKERS] [BUGS] BUG #9223: plperlu result memory leak

On Tue, Feb 25, 2014 at 6:56 AM, Sergey Burladyan eshkin...@gmail.com wrote: It looks like I found the problem, Perl use reference count and something that is called Mortal for memory management. As I understand it, mortal is free after FREETMPS. Plperl call FREETMPS in

Re: [HACKERS] Memory leakage associated with plperl spi_prepare/spi_freeplan

On Fri, Mar 1, 2013 at 7:38 PM, Tom Lane t...@sss.pgh.pa.us wrote: Alex Hunsaker bada...@gmail.com writes: Applied with some fixes. Thanks! Your version looks much better than mine. One annonce is it still leaks :-(. I fixed that, at least for the function-lifespan leakage from

Re: [HACKERS] Memory leakage associated with plperl spi_prepare/spi_freeplan

On Tue, Feb 26, 2013 at 3:56 PM, Tom Lane t...@sss.pgh.pa.us wrote: I'm inclined to think the right fix is to make a small memory context for each prepared plan made by plperl_spi_prepare(). The qdesc for it could be made right in the context (getting rid of the unchecked malloc's near the

Re: [HACKERS] plperl sigfpe reset can crash the server

On Fri, Aug 24, 2012 at 4:10 PM, Andres Freund and...@2ndquadrant.com wrote: We probably should workaround that bug anyway given that its a pretty trivial DOS using only a trusted language and it will take quite some time to push out newer perl versions even if that bug gets fixed. Doing a

Re: [HACKERS] Unexpected plperl difference between 8.4 and 9.1

On Mon, Aug 20, 2012 at 10:14 AM, Alvaro Herrera alvhe...@2ndquadrant.comwrote: Excerpts from Alex Hunsaker's message of lun ago 20 12:03:11 -0400 2012: On Sun, Aug 19, 2012 at 2:26 PM, Joel Jacobson j...@trustly.com wrote: After upgrading from 8.4 to 9.1, one of my plperl functions

Re: [HACKERS] Unexpected plperl difference between 8.4 and 9.1

On Sun, Aug 19, 2012 at 2:26 PM, Joel Jacobson j...@trustly.com wrote: After upgrading from 8.4 to 9.1, one of my plperl functions stopped working properly. For some reason, when matching a string using a regex, the $1 variable cannot be returned directly using return_next() but must be set

[HACKERS] Re: [HACKERS] PL/Perl build problem: error: ‘OP_SETSTATE’ undeclared

On Sun, Aug 12, 2012 at 9:57 PM, Peter Eisentraut pete...@gmx.net wrote: It appears that a recent Perl version (I have 5.14.2) has eliminated OP_SETSTATE, which causes the current PostgreSQL build to fail: plperl.c: In function ‘_PG_init’: plperl.c:442:5645: error: ‘OP_SETSTATE’ undeclared

Re: [HACKERS] Support for array_remove and array_replace functions

On Wed, Jul 11, 2012 at 9:54 AM, Tom Lane t...@sss.pgh.pa.us wrote: Marco Nenciarini marco.nenciar...@2ndquadrant.it writes: Patch v3 attached. I'm looking at this patch now. The restriction of array_remove to one-dimensional arrays seems a bit annoying. I see the difficulty: if the input

Re: [SPAM] [MessageLimit][lowlimit] Re: [HACKERS] pl/perl and utf-8 in sql_ascii databases

On Wed, Jul 11, 2012 at 1:42 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: I have pushed these changes to HEAD, 9.2 and 9.1. Instead of the games with plperl_lc_*.out being copied around, I just used the ASCII version as plperl_lc_1.out and the UTF8 one as plperl_lc.out. ... and this

Re: [HACKERS] pl/perl and utf-8 in sql_ascii databases

On Tue, Jul 3, 2012 at 2:59 AM, Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp wrote: Hello, Here is regression test runs on pg's also built with cygwin-gcc and VC++. Thank you! The patches attached following, - plperl_sql_ascii-4.patch : fix for pl/perl utf8 vs sql_ascii -

Re: [HACKERS] Support for array_remove and array_replace functions

On Sat, Jun 30, 2012 at 3:28 PM, Marco Nenciarini marco.nenciar...@2ndquadrant.it wrote: On 30/06/2012 04:16, Alex Hunsaker wrote: Hi, I've been reviewing this patch. Good documentation, and regression tests. The code looked fine but I didn't care for the code duplication between

Re: [HACKERS] Support for array_remove and array_replace functions

On Thu, Jun 14, 2012 at 4:41 AM, Marco Nenciarini marco.nenciar...@2ndquadrant.it wrote: Hi, following Gabriele's email regarding our previous patch on Foreign Key Arrays[1], I am sending a subset of that patch which includes only two array functions which will be needed in that patch:

Re: [HACKERS] pl/perl and utf-8 in sql_ascii databases

On Wed, Jun 20, 2012 at 1:15 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Alex Hunsaker's message of vie feb 10 16:53:05 -0300 2012: Seems like we missed the fact that we still did SvUTF8_on() in sv2cstr and SvPVUTF8() when turning a perl string into a cstring. Right.

Re: [HACKERS] pl/perl and utf-8 in sql_ascii databases

On Thu, Jun 21, 2012 at 5:22 AM, Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp wrote: So I played a bit with this patch, and touched it a bit mainly [...] functions in Util.xs might leak some memory, so I made an attempt to Ok, Is it ok to look into the newer patch including fix of leaks

Re: [HACKERS] pl/perl and utf-8 in sql_ascii databases

On Mon, Jun 18, 2012 at 1:30 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Alex Hunsaker's message of vie feb 10 16:53:05 -0300 2012: Seems like we missed the fact that we still did SvUTF8_on() in sv2cstr and SvPVUTF8() when turning a perl string into a cstring. Hmm,

Re: [HACKERS] plperl_helpers.h fix for clang

On Thu, May 24, 2012 at 11:19 AM, Peter Eisentraut pete...@gmx.net wrote: clang warns about that newish SvREFCNT_inc(sv) call in plperl_helpers.h about an unused return value, because the macro expansion of SvREFCNT_inc(sv) returns sv.  The merit of that warning might be debatable, but it

Re: [HACKERS] plperl_helpers.h fix for clang

On Thu, May 24, 2012 at 11:31 AM, Alex Hunsaker bada...@gmail.com wrote: On Thu, May 24, 2012 at 11:19 AM, Peter Eisentraut pete...@gmx.net wrote: And we could use SvREFCNT_inc_simple_void(sv), since sv doesn't have any side effects, but that's optional. Hrm I can't seem to find either

Re: [HACKERS] plperl_helpers.h fix for clang

On Thu, May 24, 2012 at 12:03 PM, Peter Eisentraut pete...@gmx.net wrote: On tor, 2012-05-24 at 11:36 -0600, Alex Hunsaker wrote: Doh, it is indeed there in 5.16.0, looks like it got added in 5.10 :-(. (I was on the wrong branch...). It's in ppport.h. Don't see any reason not to then. +1

Re: [HACKERS] [COMMITTERS] pgsql: Add new keywords SNAPSHOT and TYPES to the keyword list in gram.

On Thu, Feb 9, 2012 at 11:30, Tom Lane t...@sss.pgh.pa.us wrote: Alvaro Herrera alvhe...@commandprompt.com writes: Excerpts from Tom Lane's message of jue feb 09 12:17:59 -0300 2012: FWIW that script is throwing a warning here: Use of assignment to $[ is deprecated at

Re: [HACKERS] pl/perl and utf-8 in sql_ascii databases

On Thu, Feb 9, 2012 at 03:21, Christoph Berg c...@df7cb.de wrote: Hi, we have a database that is storing strings in various encodings (and non-encodings, namely the arbitrary byte soup [ ... ] For this reason, the database uses sql_ascii encoding ...snip... In sql_ascii databases,

Re: [HACKERS] [COMMITTERS] pgsql: Fix breakage from earlier plperl fix.

On Fri, Jan 13, 2012 at 16:07, Andrew Dunstan and...@dunslane.net wrote: On 01/12/2012 09:28 PM, Alex Hunsaker wrote: Util.c/o not depending on plperl_helpers.h was also throwing me for a loop so I fixed it and SPI.c... Thoughts? Basically looks good, but I'm confused by this:   do

Re: [HACKERS] [COMMITTERS] pgsql: Fix breakage from earlier plperl fix.

On Fri, Jan 6, 2012 at 14:05, Tom Lane t...@sss.pgh.pa.us wrote: Alex Hunsaker bada...@gmail.com writes: Oh my... I dunno exactly what I was smoking last night, but its a good thing I didn't share :-). Uh so my test program was also completely wrong, Ill have to redo it all. I've narrowed

Re: [HACKERS] [COMMITTERS] pgsql: Fix breakage from earlier plperl fix.

On Fri, Jan 6, 2012 at 06:34, Andrew Dunstan and...@dunslane.net wrote: PFA that copies if its readonly and its not a scalar. I didn't bother adding regression tests-- should I have? I have several questions. 1. How much are we actually saving here? newSVsv() ought to be pretty cheap, no?

Re: [HACKERS] [COMMITTERS] pgsql: Fix breakage from earlier plperl fix.

On Thu, Jan 5, 2012 at 16:02, Andrew Dunstan and...@dunslane.net wrote: Fix breakage from earlier plperl fix. Apparently the perl garbage collector was a bit too eager, so here we control when the new SV is garbage collected. I know im a little late to the party... I can't help but think

Re: [HACKERS] [COMMITTERS] pgsql: Fix breakage from earlier plperl fix.

On Thu, Jan 5, 2012 at 16:59, Andrew Dunstan and...@dunslane.net wrote: On 01/05/2012 06:31 PM, Alex Hunsaker wrote: On Thu, Jan 5, 2012 at 16:02, Andrew Dunstanand...@dunslane.net  wrote: Fix breakage from earlier plperl fix. I can't help but think this seems a bit inefficient So, yes

Re: [HACKERS] PL/Perl Does not Like vstrings

On Wed, Jan 4, 2012 at 13:13, Andrew Dunstan and...@dunslane.net wrote: On 01/04/2012 12:56 PM, Tom Lane wrote: I looked at that last night but it appeared that SvOK would be perfectly happy.  (Didn't actually try it, though, I was just eyeballing the flags in gdb.) I tested it and

Re: [HACKERS] Review: Non-inheritable check constraints

On Fri, Dec 16, 2011 at 12:06, Alvaro Herrera alvhe...@commandprompt.com wrote: Yeah.  Nikhil, Alex, this is the merged patch.  Have a look that it still works for you (particularly the pg_dump bits) and I'll commit it. I adjusted the regression test a bit too. Other than the version checks

Re: [HACKERS] Review: Non-inheritable check constraints

On Fri, Dec 16, 2011 at 14:01, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Alex Hunsaker's message of vie dic 16 17:50:12 -0300 2011: On Fri, Dec 16, 2011 at 12:06, Alvaro Herrera alvhe...@commandprompt.com wrote: Yeah.  Nikhil, Alex, this is the merged patch.  Have a

Re: [HACKERS] Re: [COMMITTERS] pgsql: Force strings passed to and from plperl to be in UTF8 encoding.

On Wed, Nov 2, 2011 at 17:12, Andrew Dunstan and...@dunslane.net wrote: Considering that the issue appears to have been ignored from mid-February until early October, I don't see why it should now get to jump to the head of the queue.  Other people may have different opinions, of course.

Re: [HACKERS] pl/perl example in the doc no longer works in 9.1

On Thu, Oct 13, 2011 at 16:05, Tom Lane t...@sss.pgh.pa.us wrote: Applied with some further hacking of my own to clean up memory leaks and grotty coding. Thanks! BTW after seeing it I agree passing in fcinfo (and the other fixes) to plperl_sv_to_datum() is better. -- Sent via pgsql-hackers

Re: [HACKERS] pl/perl example in the doc no longer works in 9.1

On Wed, Oct 12, 2011 at 15:00, Tom Lane t...@sss.pgh.pa.us wrote: David E. Wheeler da...@kineticode.com writes: On Oct 12, 2011, at 9:15 AM, Tom Lane wrote: Well, the real question is why a function declared to return VOID cares at all about what the last command in its body is.  If this has

Re: [HACKERS] Patch: Perl xsubpp

On Wed, Oct 12, 2011 at 17:53, David E. Wheeler da...@kineticode.com wrote: On Sep 15, 2011, at 3:04 PM, Alex Hunsaker wrote: Close, seems I was wrong about the typemap ExtUtils::ParseXS does not install a new one so we still need to point to the one in privlib. Also xsubpp is not executable

Re: [HACKERS] pl/perl example in the doc no longer works in 9.1

On Wed, Oct 12, 2011 at 15:33, Alex Hunsaker bada...@gmail.com wrote: On Wed, Oct 12, 2011 at 15:00, Tom Lane t...@sss.pgh.pa.us wrote:  The core of the problem seems to be that if SvROK(sv) then the code assumes that it must be intended to convert that to an array or composite, no matter

Re: [HACKERS] Review: Non-inheritable check constraints

On Fri, Oct 7, 2011 at 21:30, Nikhil Sontakke nikkh...@gmail.com wrote: Hi Alex, I guess we both are in agreement with each other :) After sleeping over it, I think that check is indeed dead code with this new non-inheritable check constraints functionality in place. So unless you have some

Re: [HACKERS] alter table only ... drop constraint broken in HEAD

On Sun, Oct 9, 2011 at 09:17, Greg Stark st...@mit.edu wrote: On Fri, Oct 7, 2011 at 5:45 PM, Alex Hunsaker bada...@gmail.com wrote: If I find the time maybe Ill submit something along these lines for the next commit fest. So i just picked up the non-inherited constraints patch and quickly

Re: [HACKERS] Review: Non-inheritable check constraints

On Fri, Oct 7, 2011 at 00:28, Nikhil Sontakke nikkh...@gmail.com wrote: Hi Alex, So with it all spelled out now I see the constraint must be added to child tables too check is dead code. Thanks the above step-wise explanation helps. But AFAICS, the default inhOpt value can be governed by

Re: [HACKERS] alter table only ... drop constraint broken in HEAD

On Fri, Oct 7, 2011 at 07:53, Robert Haas robertmh...@gmail.com wrote:  The only way we could trip up in that case is if there were two identically named constraints.  We'd have to visit the first tuple, update it, then visit the second tuple, recurse (thus incrementing the command counter),

Re: [HACKERS] alter table only ... drop constraint broken in HEAD

On Fri, Oct 7, 2011 at 09:50, Robert Haas robertmh...@gmail.com wrote: On Fri, Oct 7, 2011 at 11:19 AM, Alex Hunsaker bada...@gmail.com wrote: My only thought is perhaps we should add that missing unique index on (conrelid, conname). If we are not going to support duplicate names in the code

Re: [HACKERS] Re: [COMMITTERS] pgsql: Force strings passed to and from plperl to be in UTF8 encoding.

On Wed, Oct 5, 2011 at 20:36, Robert Haas robertmh...@gmail.com wrote: On Wed, Oct 5, 2011 at 5:03 PM, Alex Hunsaker bada...@gmail.com wrote: On Wed, Oct 5, 2011 at 08:18, Robert Haas robertmh...@gmail.com wrote: On Wed, Oct 5, 2011 at 3:58 AM, Amit Khandekar amit.khande...@enterprisedb.com

Re: [HACKERS] Review: Non-inheritable check constraints

On Thu, Oct 6, 2011 at 02:42, Nikhil Sontakke nikkh...@gmail.com wrote: Hi Alex, I didn't care for the changes to gram.y so I reworked it a bit so we now pass is_only to AddRelationNewConstraint() (like we do with is_local). Seemed simpler but maybe I missed something. Comments? Hmmm, your

Re: [HACKERS] alter table only ... drop constraint broken in HEAD

On Thu, Oct 6, 2011 at 07:24, Robert Haas robertmh...@gmail.com wrote: On Wed, Oct 5, 2011 at 10:29 PM, Robert Haas robertmh...@gmail.com wrote: On Wed, Oct 5, 2011 at 5:53 PM, Alex Hunsaker bada...@gmail.com wrote: tldr: Seems to be broken by http://git.postgresql.org/gitweb/?p

Re: [HACKERS] Re: [COMMITTERS] pgsql: Force strings passed to and from plperl to be in UTF8 encoding.

On Tue, Oct 4, 2011 at 23:46, Amit Khandekar amit.khande...@enterprisedb.com wrote: On 4 October 2011 22:57, Alex Hunsaker bada...@gmail.com wrote: On Tue, Oct 4, 2011 at 03:09, Amit Khandekar amit.khande...@enterprisedb.com wrote: On 4 October 2011 14:04, Alex Hunsaker bada...@gmail.com wrote

Re: [HACKERS] Re: [COMMITTERS] pgsql: Force strings passed to and from plperl to be in UTF8 encoding.

On Wed, Oct 5, 2011 at 00:30, Alex Hunsaker bada...@gmail.com wrote: On Tue, Oct 4, 2011 at 23:46, Amit Khandekar amit.khande...@enterprisedb.com wrote: You mean the final changes in plperl_helpers.h would look like something like this right? :  static inline char *  utf_u2e(const char

[HACKERS] Review: Non-inheritable check constraints

Hi! *Waves* First off, it all seems to work as described: - regressions pass - domains work - tried various inherit options (merging constraints, alter table no inherit etc) - pg_dump/restore I didn't care for the changes to gram.y so I reworked it a bit so we now pass is_only to

Re: [HACKERS] Re: [COMMITTERS] pgsql: Force strings passed to and from plperl to be in UTF8 encoding.

On Wed, Oct 5, 2011 at 08:18, Robert Haas robertmh...@gmail.com wrote: On Wed, Oct 5, 2011 at 3:58 AM, Amit Khandekar amit.khande...@enterprisedb.com wrote: I have no more issues with the patch. Thanks! I think this patch needs to be added to the open CommitFest, with links to the reviews,

[HACKERS] alter table only ... drop constraint broken in HEAD

tldr: Seems to be broken by http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=4da99ea4231e3d8bbf28b666748c1028e7b7d665 : commit 4da99ea4231e3d8bbf28b666748c1028e7b7d665 Author: Robert Haas rh...@postgresql.org Date: Mon Jun 27 10:27:17 2011 -0400 Avoid having two copies of the

Re: [HACKERS] Re: [COMMITTERS] pgsql: Force strings passed to and from plperl to be in UTF8 encoding.

On Mon, Oct 3, 2011 at 23:35, Amit Khandekar amit.khande...@enterprisedb.com wrote: WHen GetDatabaseEncoding() != PG_UTF8 case, ret will not be equal to utf8_str, so pg_verify_mbstr_len() will not get called. That's the reason, pg_verify_mbstr_len() is under the ( ret == utf8_str ) condition.

Re: [HACKERS] Re: [COMMITTERS] pgsql: Force strings passed to and from plperl to be in UTF8 encoding.

On Tue, Oct 4, 2011 at 03:09, Amit Khandekar amit.khande...@enterprisedb.com wrote: On 4 October 2011 14:04, Alex Hunsaker bada...@gmail.com wrote: On Mon, Oct 3, 2011 at 23:35, Amit Khandekar amit.khande...@enterprisedb.com wrote: WHen GetDatabaseEncoding() != PG_UTF8 case, ret

Re: [HACKERS] Re: [COMMITTERS] pgsql: Force strings passed to and from plperl to be in UTF8 encoding.

On Mon, Oct 3, 2011 at 04:20, Amit Khandekar amit.khande...@enterprisedb.com wrote: Is there a plan to commit this issue? I am still seeing this issue on PG 9.1 STABLE branch. Attached is a small patch that targets only the specific issue in the described testcase : create or replace

Re: [HACKERS] /proc/self/oom_adj is deprecated in newer Linux kernels

On Fri, Sep 16, 2011 at 10:37, Tom Lane t...@sss.pgh.pa.us wrote: Greg Stark st...@mit.edu writes: On Fri, Sep 16, 2011 at 3:57 PM, Tom Lane t...@sss.pgh.pa.us wrote: Does anyone want to argue for doing something more complicated, and if so what exactly? Well there's no harm trying to write

Re: [HACKERS] Patch: Perl xsubpp

On Thu, Sep 15, 2011 at 10:44, David E. Wheeler da...@kineticode.com wrote: Hackers, Since installing Perl 5.14.1, I installed newer version of ExtUtils::ParseXS from CPAN. I installed it with `make install UNINST=1`, which removes the copy of xsubpp that ships with core Perl. This results

Re: [HACKERS] Patch: Perl xsubpp

On Thu, Sep 15, 2011 at 15:53, David E. Wheeler da...@kineticode.com wrote: On Sep 15, 2011, at 4:41 PM, Alex Hunsaker wrote: ExtUtils searches @INC, privlibexp maybe we should do that? Yes, I just got an email from David Golden to that effect. So perhaps the attached patch is better

Re: [HACKERS] PL/Perl Returned Array

On Wed, Aug 17, 2011 at 10:06, Andrew Dunstan and...@dunslane.net wrote: On 08/12/2011 09:17 PM, Alex Hunsaker wrote: [empty arrays returned are not handled correctly] Anyway, the attached patch fixes it for me. That is when we don't have an array state, just return an empty array.  (Also

Re: [HACKERS] PL/Perl Returned Array

On Fri, Aug 12, 2011 at 18:00, David E. Wheeler da...@kineticode.com wrote: Hackers, Given this script on 9.1beta3:    BEGIN;    CREATE EXTENSION plperl;    CREATE OR REPLACE FUNCTION wtf(    ) RETURNS TEXT[] LANGUAGE plperl AS $$ return []; $$;    SELECT wtf() = '{}'::TEXT[]; Why is

Re: [HACKERS] plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https

On Sun, Aug 7, 2011 at 17:06, Tim Bunce tim.bu...@pobox.com wrote: On Sat, Aug 06, 2011 at 12:37:28PM -0600, Alex Hunsaker wrote: ... Find attached a version that does the equivalent of local %SIG for each pl/perl(u) call. +     gv = gv_fetchpv(SIG, 0, SVt_PVHV); +     save_hash(gv

Re: [HACKERS] plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https

On Fri, Aug 5, 2011 at 08:53, Andrew Dunstan and...@dunslane.net wrote: On 08/04/2011 11:23 PM, Alex Hunsaker wrote: [ ... don't let people set signal handlers postgres sets ] This whole thing is a massive over-reaction to a problem we almost certainly know how to fix fairly simply

Re: [HACKERS] plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https

On Thu, Aug 4, 2011 at 09:11, Andrew Dunstan and...@dunslane.net wrote: What *I'd* like is a way to prevent libperl from touching the host application's signal handlers at all.  Sadly, Perl does not actually think of itself as an embedded library, and therefore thinks it owns all resources of

Re: [HACKERS] plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https

On Thu, Aug 4, 2011 at 16:34, David E. Wheeler da...@kineticode.com wrote: On Aug 4, 2011, at 3:09 PM, Alex Hunsaker wrote: Mainly the options im thinking about are: 1) if anyone touches %SIG die 2) turn %SIG into a regular hash so people can set/play with %SIG, but it has no real effect

Re: [HACKERS] plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https

On Thu, Aug 4, 2011 at 17:52, Tom Lane t...@sss.pgh.pa.us wrote: Alex Hunsaker bada...@gmail.com writes: On Thu, Aug 4, 2011 at 16:34, David E. Wheeler da...@kineticode.com wrote: On Aug 4, 2011, at 3:09 PM, Alex Hunsaker wrote: 3) local %SIG before we call their trigger function. This lets

Re: [HACKERS] plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https

On Thu, Aug 4, 2011 at 19:40, Andrew Dunstan and...@dunslane.net wrote: Let's slow down a bit. Nobody that we know of has encountered the problem Tom's referring to, over all the years plperlu has been available. The changes you're proposing have the potential to downgrade the usefulness of

Re: [HACKERS] Check constraints on partition parents only?

On Wed, Jul 27, 2011 at 14:08, Tom Lane t...@sss.pgh.pa.us wrote: Yeah.  If we're going to allow this then we should just have a concept of a non-inherited constraint, full stop.  This might just be a matter of removing the error thrown in ATAddCheckConstraint, but I'd be worried about

Re: [HACKERS] Arrays of Records in PL/Perl

On Tue, Jul 12, 2011 at 12:45, David E. Wheeler da...@kineticode.com wrote: Hackers, That is, if a record is passed to a PL/Perl function, it's correctly converted into a hash. If, however, an array of records are passed, the record are stringified, rather than turned into hashes. This

[HACKERS] csvlog_fields review

It bit rotted a bit find a new version attached that includes the following fixes: - show_session_authorization() no longer exists, instead access the session_authorization_guc directly (like we do for show_role in commands/variable.c). I find it quite ugly tho... - it changed %u to %U and %U to

Re: [HACKERS] add support for logging current role (what to review?)

On Thu, Jun 30, 2011 at 16:35, Stephen Frost sfr...@snowman.net wrote: I do want to rework the logging infrastructure (as discussed in the dev meeting), but I see that whole thing as rather orthogonal to this change. *Shrug* Fine by me, im not going to argue that you should or shouldn't

Re: [HACKERS] add support for logging current role (what to review?)

On Tue, Jun 28, 2011 at 09:15, Robert Haas robertmh...@gmail.com wrote: Anyway, if we are going to insist on rewriting substantial chunks of the logging infrastructure before doing this, we at least need to reach some agreement on what would be an acceptable outcome - and then let Stephen code

[HACKERS] add support for logging current role (what to review?)

Ive been holding off because its marked as Waiting on Author, am now thinking thats a mistake. =) It links to this patch: http://archives.postgresql.org/message-id/20110215135131.gx4...@tamriel.snowman.net Which is older than the latest patch in that thread posted by Robert:

Re: [HACKERS] Creating new remote branch in git?

On Fri, Jun 10, 2011 at 00:53, Greg Smith g...@2ndquadrant.com wrote: On 06/10/2011 12:19 AM, Alex Hunsaker wrote: It looks like if you push the remote branch first everything should work nicely: git checkout master git push origin origin:refs/heads/REL9_1_STABLE git fetch # fetch the new

Re: [HACKERS] gcc 4.6 and hot standby

On Fri, Jun 10, 2011 at 12:38, Tom Lane t...@sss.pgh.pa.us wrote: I've been able to reproduce this on released Fedora 15, and sure enough it is a compiler bug.  The problem comes from these fragments of ReadRecord(): [ ... ] Whoa, awesome. I spent a few more hours comparing the assembly--

Re: [HACKERS] gcc 4.6 and hot standby

On Fri, Jun 10, 2011 at 14:24, Tom Lane t...@sss.pgh.pa.us wrote: Alex Hunsaker bada...@gmail.com writes: Hrm, Couldn't we change all the references to tmpRecPtr to use RecPtr instead? (Except of course where we assign RecPtr = tmpRecPtr); I think that would make the code look a lot less

Re: [HACKERS] Creating new remote branch in git?

On Thu, Jun 9, 2011 at 21:05, Tom Lane t...@sss.pgh.pa.us wrote: In the next couple of days it's going to be time to branch off REL9_1_STABLE from master, and I realized that I am pretty foggy on how to do that in git.  I suppose it's some variant of git checkout master             # if not

Re: [HACKERS] Creating new remote branch in git?

On Thu, Jun 9, 2011 at 22:02, Tom Lane t...@sss.pgh.pa.us wrote: Alex Hunsaker bada...@gmail.com writes: On Thu, Jun 9, 2011 at 21:05, Tom Lane t...@sss.pgh.pa.us wrote: In the next couple of days it's going to be time to branch off REL9_1_STABLE from master, and I realized that I am pretty

Re: [HACKERS] [Pgbuildfarm-members] CREATE FUNCTION hang on test machine polecat on HEAD

On Tue, Jun 7, 2011 at 12:42, Alex Hunsaker bada...@gmail.com wrote: On Tue, Jun 7, 2011 at 12:22, Tom Lane t...@sss.pgh.pa.us wrote: Alex Hunsaker bada...@gmail.com writes: Im looking at the raw perl 5.10.0 source... I wonder if apple is shipping a modified version? You could find out

[HACKERS] gcc 4.6 and hot standby

So I've been delaying moving some production boxes over to 9.0.4 from 9.0.2 because hot standby fails with: (this is on the hot standby machine that connects to the master) 2011-06-08 11:40:48 MDT [6072]: [2-1] user= LOG: entering standby mode 2011-06-08 11:40:48 MDT [6072]: [3-1] user= DEBUG:

Re: [HACKERS] gcc 4.6 and hot standby

On Wed, Jun 8, 2011 at 12:12, Alex Hunsaker bada...@gmail.com wrote: So I've been delaying moving some production boxes over to 9.0.4 from 9.0.2 because hot standby fails with: (this is on the hot standby machine that connects to the master) [ ...] 2011-06-08 11:41:03 MDT [6072]: [18-1] user

Re: [HACKERS] gcc 4.6 and hot standby

On Wed, Jun 8, 2011 at 12:49, Tom Lane t...@sss.pgh.pa.us wrote: Alex Hunsaker bada...@gmail.com writes: So I've been delaying moving some production boxes over to 9.0.4 from 2011-06-08 11:41:03 MDT [6078]: [1-1] user= FATAL:  terminating walreceiver process due to administrator command

Re: [HACKERS] gcc 4.6 and hot standby

On Wed, Jun 8, 2011 at 16:20, Mark Kirkwood mark.kirkw...@catalyst.net.nz wrote: On 09/06/11 06:58, Alex Hunsaker wrote: Yeah :-). However ill note it looks like its the default compiler for fedora 15, ubuntu natty and debian sid. FWIW Ubuntu natty uses gcc 4.5.2, probably just as as well

Re: [HACKERS] [Pgbuildfarm-members] CREATE FUNCTION hang on test machine polecat on HEAD

On Mon, Jun 6, 2011 at 21:16, Robert Creager robert.crea...@oracle.com wrote: That's weird. Why it should hang there I have no idea. Did it hang at the same spot both times? Can you get a backtrace? I think so, but I didn't pay much attention :-( GNU gdb 6.3.50-20050815 (Apple version

Re: [HACKERS] [Pgbuildfarm-members] CREATE FUNCTION hang on test machine polecat on HEAD

On Tue, Jun 7, 2011 at 11:48, Tom Lane t...@sss.pgh.pa.us wrote: Alex Hunsaker bada...@gmail.com writes: On Mon, Jun 6, 2011 at 21:16, Robert Creager robert.crea...@oracle.com wrote: (gdb) bt #0  0x000100a505e4 in Perl_get_hash_seed () #1  0x000100a69b94 in perl_parse () I don't

Re: [HACKERS] [Pgbuildfarm-members] CREATE FUNCTION hang on test machine polecat on HEAD

On Tue, Jun 7, 2011 at 12:22, Tom Lane t...@sss.pgh.pa.us wrote: Alex Hunsaker bada...@gmail.com writes: Im looking at the raw perl 5.10.0 source... I wonder if apple is shipping a modified version? You could find out by digging around at http://www.opensource.apple.com/ polecat appears

Re: [HACKERS] Fix for Perl 5.14

On Sat, Apr 23, 2011 at 07:00, Andrew Dunstan and...@dunslane.net wrote: This looks OK, but I think we need to wait until they remove the RC tag. 5.14.0 is out now, Ive retested with 5.14.0 (x86-64), 5.12.3 (x86-64) and 5.10.1 (i386). No changes are needed. [ if you missed it ] The

[HACKERS] Fix for Perl 5.14

Perl 5.14.0-RC1 came out a few days ago... There is a minor compile time error due to the API changing a bit: plperl.c:929:3: error: lvalue required as left operand of assignment This is due to GvCV() no longer returning an lvalue, instead they want us to use the new GvCV_set macro. (see

Re: [HACKERS] Fix for Perl 5.14

On Sat, Apr 23, 2011 at 07:00, Andrew Dunstan and...@dunslane.net wrote: On 04/23/2011 03:02 AM, Alex Hunsaker wrote: ... There is a minor compile time error due to the API changing a bit: plperl.c:929:3: error: lvalue required as left operand of assignment ... Unfortunately  that macro

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Mon, Apr 18, 2011 at 19:50, Josh Berkus j...@agliodbs.com wrote: You'll notice that this has been a complaint of veteran contributors as well; WIP patches either get no review, or get reviewed as if they were expected to be committable. I don't see this changing anytime in the future. We

Re: [HACKERS] arrays as pl/perl input arguments [PATCH]

On Thu, Feb 17, 2011 at 16:18, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Alex Hunsaker's message of sáb feb 12 04:53:14 -0300 2011: - make plperl.o depend on plperl_helpers.h (should have been done in the utf8 patch) Incidentally, I think this bit was lost, no? It was,

Re: [HACKERS] arrays as pl/perl input arguments [PATCH]

On Wed, Feb 16, 2011 at 12:21, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Tim Bunce's message of mié feb 16 14:08:11 -0300 2011: I'd suggest encode_typed_literal() as a better name. FYI I'm looking at this patch (v10), and I'll incorporate Tim's suggestion. Looks good to

Re: [HACKERS] CommitFest 2011-01 as of 2011-02-04

On Mon, Feb 14, 2011 at 09:49, Stephen Frost sfr...@snowman.net wrote: * Robert Haas (robertmh...@gmail.com) wrote: Here's where I think we are with this CommitFest.  Subject: Re: [HACKERS] CommitFest 2011-01 as of 2011-02-04 I'm gonna go out on a limb and hope you meant '2011-02-14' there.

Re: [HACKERS] why two dashes in extension load files

On Tue, Feb 15, 2011 at 14:12, Robert Haas robertmh...@gmail.com wrote: On Tue, Feb 15, 2011 at 3:26 PM, marcin mank marcin.m...@gmail.com wrote: how about : we use a single dash as the separator, and if the extension author insists on having a dash in the name, as a punishment he must

Re: [HACKERS] pl/python tracebacks

On Sat, Feb 12, 2011 at 01:50, Jan Urbański wulc...@wulczer.org wrote: On 12/02/11 04:12, Alex Hunsaker wrote: In PLy_traceback fname and prname look like they will leak (well as much as a palloc() in an error path can leak I suppose). But they're no palloc'd, no? fname is either a static

[HACKERS] Re: [COMMITTERS] pgsql: Force strings passed to and from plperl to be in UTF8 encoding.

On Sun, Feb 6, 2011 at 15:31, Andrew Dunstan and...@dunslane.net wrote: Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl

Re: [HACKERS] pl/python invalidate functions with composite arguments

On Fri, Feb 11, 2011 at 08:47, Robert Haas robertmh...@gmail.com wrote: On Thu, Feb 10, 2011 at 9:06 PM, Alex Hunsaker bada...@gmail.com wrote: On Wed, Feb 9, 2011 at 02:09, Jan Urbański wulc...@wulczer.org wrote: On 27/01/11 22:42, Jan Urbański wrote: On 23/12/10 14:50, Jan Urbański wrote

Re: [HACKERS] pl/python tracebacks

traceback support for PL/Python mentioned in http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's an incremental patch on top of the plpython-refactor patch sent eariler. Updated to master. Updated to master again. Once more. Alex Hunsaker is listed as the reviewer

Re: [HACKERS] Careful PL/Perl Release Not Required

On Fri, Feb 11, 2011 at 10:16, David E. Wheeler da...@kineticode.com wrote: On Feb 10, 2011, at 11:43 PM, Alex Hunsaker wrote: Like I said, the terminology is awful. Yeah I use encode and decode to mean the same thing frequently :-(. In the the cited case he was passing %C3%A9

Re: [HACKERS] Careful PL/Perl Release Not Required

On Fri, Feb 11, 2011 at 10:44, Alex Hunsaker bada...@gmail.com wrote: On Fri, Feb 11, 2011 at 10:16, David E. Wheeler da...@kineticode.com wrote: That *looks* like it is decoding the input string, which it is, but actually that will double utf8 encode your string. It does not seem

  1   2   3   4   >