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
> prerequisite for t
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 anything, so I'm a bit at a
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&dt=2016-03-08%2004%3A22%3A00
> 2016-03-08 05:56:05.566 UTC [56de6971.723:5] LOG: statement: select
> plperl_sum_array('{}');
> ==1827== In
On Sat, Jun 6, 2015 at 7:03 PM, Peter Eisentraut 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 symbol
On Tue, Mar 10, 2015 at 10:11 AM, Tom Lane 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 that is happe
On Wed, Mar 5, 2014 at 12:55 PM, Alex Hunsaker wrote:
> On Wed, Mar 5, 2014 at 12:22 PM, Alvaro Herrera
> 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
>>
On Wed, Mar 5, 2014 at 12:22 PM, Alvaro Herrera
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 bugging at all. I'll d
On Tue, Feb 25, 2014 at 6:56 AM, Sergey Burladyan 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 plperl_call_perl_func() but after it,
On Fri, Mar 1, 2013 at 7:38 PM, Tom Lane wrote:
>
> Alex Hunsaker 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
> spi_pre
On Tue, Feb 26, 2013 at 3:56 PM, Tom Lane 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 top of the func
On Fri, Aug 24, 2012 at 4:10 PM, Andres Freund 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 pqsignal(SIGFPE, Fl
On Mon, Aug 20, 2012 at 10:14 AM, Alvaro Herrera
wrote:
> 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 wrote:
> >
> > > After upgrading from 8.4 to 9.1, one of my plperl functions stopped
> > > working properly.
>
> I
On Sun, Aug 19, 2012 at 2:26 PM, Joel Jacobson 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 to a varia
On Sun, Aug 12, 2012 at 9:57 PM, Peter Eisentraut 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 (first use i
On Wed, Jul 11, 2012 at 1:42 PM, Alvaro Herrera
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 story hasn't ende
On Wed, Jul 11, 2012 at 9:54 AM, Tom Lane wrote:
> Marco Nenciarini 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 is multi-dimensional then removing some ele
On Tue, Jul 3, 2012 at 2:59 AM, Kyotaro HORIGUCHI
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
> - plperl_sql_ascii_regress-1.pat
On Sat, Jun 30, 2012 at 3:28 PM, Marco Nenciarini
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
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 pa
On Thu, Jun 21, 2012 at 5:22 AM, Kyotaro HORIGUCHI
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
> at first?
Yeah :-).
> V
On Wed, Jun 20, 2012 at 1:15 PM, Alvaro Herrera
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.
>
> So I played a bi
On Mon, Jun 18, 2012 at 1:30 PM, Alvaro Herrera
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, this patch belongs i
On Thu, May 24, 2012 at 12:03 PM, Peter Eisentraut 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
On Thu, May 24, 2012 at 11:31 AM, Alex Hunsaker wrote:
> On Thu, May 24, 2012 at 11:19 AM, Peter Eisentraut 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 fi
On Thu, May 24, 2012 at 11:19 AM, Peter Eisentraut 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 seems easy to fi
On Thu, Feb 9, 2012 at 11:30, Tom Lane wrote:
> Alvaro Herrera 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
>> /pgsql/source/HEAD/src/tools/check_keywords.pl line 19.
>
On Thu, Feb 9, 2012 at 03:21, Christoph Berg 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, utf_e2u does
On Fri, Jan 13, 2012 at 16:07, Andrew Dunstan 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&#
On Fri, Jan 6, 2012 at 14:05, Tom Lane wrote:
> Alex Hunsaker 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 i
On Fri, Jan 6, 2012 at 06:34, Andrew Dunstan 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? I imagine
On Thu, Jan 5, 2012 at 16:59, Andrew Dunstan wrote:
>
>
> On 01/05/2012 06:31 PM, Alex Hunsaker wrote:
>>
>> On Thu, Jan 5, 2012 at 16:02, Andrew Dunstan wrote:
>>>
>>> Fix breakage from earlier plperl fix.
>> I can't help but think this seems
On Thu, Jan 5, 2012 at 16:02, Andrew Dunstan 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 this seems a bit in
On Wed, Jan 4, 2012 at 13:13, Andrew Dunstan 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 you're right,
On Fri, Dec 16, 2011 at 14:01, Alvaro Herrera
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
>> wrote:
>>
>> > Yeah. Nikhil, Alex, this is the merged patch. Have a look that it
>> > still works for you (par
On Fri, Dec 16, 2011 at 12:06, Alvaro Herrera
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 seem to be off by one loo
On Wed, Nov 2, 2011 at 17:12, Andrew Dunstan 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.
>>
>> Added.
On Thu, Oct 13, 2011 at 16:05, Tom Lane 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 mailing list (pg
On Wed, Oct 12, 2011 at 15:33, Alex Hunsaker wrote:
> On Wed, Oct 12, 2011 at 15:00, Tom Lane 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 whether the
On Wed, Oct 12, 2011 at 17:53, David E. Wheeler 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 no
On Wed, Oct 12, 2011 at 15:00, Tom Lane wrote:
> "David E. Wheeler" 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 changed
>>> since previous ve
On Sun, Oct 9, 2011 at 09:17, Greg Stark wrote:
> On Fri, Oct 7, 2011 at 5:45 PM, Alex Hunsaker 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
On Fri, Oct 7, 2011 at 21:30, Nikhil Sontakke 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 other comme
On Wed, Oct 5, 2011 at 20:36, Robert Haas wrote:
> On Wed, Oct 5, 2011 at 5:03 PM, Alex Hunsaker wrote:
>> On Wed, Oct 5, 2011 at 08:18, Robert Haas wrote:
>>> On Wed, Oct 5, 2011 at 3:58 AM, Amit Khandekar
>>> wrote:
>>>> I have no more issues with the p
On Fri, Oct 7, 2011 at 09:50, Robert Haas wrote:
> On Fri, Oct 7, 2011 at 11:19 AM, Alex Hunsaker 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,
>>
On Fri, Oct 7, 2011 at 07:53, Robert Haas 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), and then visit th
On Fri, Oct 7, 2011 at 00:28, Nikhil Sontakke 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 the SQ
On Thu, Oct 6, 2011 at 07:24, Robert Haas wrote:
> On Wed, Oct 5, 2011 at 10:29 PM, Robert Haas wrote:
>> On Wed, Oct 5, 2011 at 5:53 PM, Alex Hunsaker wrote:
>>> tldr:
>>>
>>> Seems to be broken by
>>> http://git.postg
On Thu, Oct 6, 2011 at 02:42, Nikhil Sontakke 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 patch
tldr:
Seems to be broken by
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=4da99ea4231e3d8bbf28b666748c1028e7b7d665
:
commit 4da99ea4231e3d8bbf28b666748c1028e7b7d665
Author: Robert Haas
Date: Mon Jun 27 10:27:17 2011 -0400
Avoid having two copies of the HOT-chain search logi
On Wed, Oct 5, 2011 at 08:18, Robert Haas wrote:
> On Wed, Oct 5, 2011 at 3:58 AM, Amit Khandekar
> 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, and marked Ready for Committer.
The open co
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 AddRelationNewCo
On Wed, Oct 5, 2011 at 00:30, Alex Hunsaker wrote:
> On Tue, Oct 4, 2011 at 23:46, Amit Khandekar
> wrote:
>> You mean the final changes in plperl_helpers.h would look like
>> something like this right? :
>>
>> static inline char *
>> utf_
On Tue, Oct 4, 2011 at 23:46, Amit Khandekar
wrote:
> On 4 October 2011 22:57, Alex Hunsaker wrote:
>> On Tue, Oct 4, 2011 at 03:09, Amit Khandekar
>> wrote:
>>> On 4 October 2011 14:04, Alex Hunsaker wrote:
>>>> On Mon, Oct 3, 2011 at 23:35, Amit Kh
On Tue, Oct 4, 2011 at 03:09, Amit Khandekar
wrote:
> On 4 October 2011 14:04, Alex Hunsaker wrote:
>> On Mon, Oct 3, 2011 at 23:35, Amit Khandekar
>> wrote:
>>
>>> WHen GetDatabaseEncoding() != PG_UTF8 case, ret will not be equal to
>>> utf8_str, so pg
On Mon, Oct 3, 2011 at 23:35, Amit Khandekar
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.
Consider a latin1 database
On Mon, Oct 3, 2011 at 04:20, Amit Khandekar
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 function zerob() returns text as $
On Fri, Sep 16, 2011 at 10:37, Tom Lane wrote:
> Greg Stark writes:
>> On Fri, Sep 16, 2011 at 3:57 PM, Tom Lane wrote:
>>> Does anyone want
>>> to argue for doing something more complicated, and if so what exactly?
>
>> Well there's no harm trying to write to oom_score_adj and if that
>> fails
On Thu, Sep 15, 2011 at 15:53, David E. Wheeler 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 be
On Thu, Sep 15, 2011 at 10:44, David E. Wheeler 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 in an error duri
On Wed, Aug 17, 2011 at 10:06, Andrew Dunstan 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
On Fri, Aug 12, 2011 at 18:00, David E. Wheeler 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 that? I
On Sun, Aug 7, 2011 at 17:06, Tim Bunce 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&qu
On Fri, Aug 5, 2011 at 08:53, Andrew Dunstan 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
On Thu, Aug 4, 2011 at 19:40, Andrew Dunstan 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
> plperlu considera
On Thu, Aug 4, 2011 at 17:52, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Thu, Aug 4, 2011 at 16:34, David E. Wheeler wrote:
>>> On Aug 4, 2011, at 3:09 PM, Alex Hunsaker wrote:
>>>> 3) local %SIG before we call their trigger function. This lets signals
>>&
On Thu, Aug 4, 2011 at 16:34, David E. Wheeler 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
On Thu, Aug 4, 2011 at 09:11, Andrew Dunstan 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 the process
On Wed, Jul 27, 2011 at 14:08, Tom Lane 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 whether pg_dump will
On Tue, Jul 12, 2011 at 12:45, David E. Wheeler 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 seems
> inconsistent
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 b
On Thu, Jun 30, 2011 at 16:35, Stephen Frost 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
rework the logging in
On Tue, Jun 28, 2011 at 09:15, Robert Haas 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 that up as a sepa
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:
http://archives.postg
On Fri, Jun 10, 2011 at 14:24, Tom Lane wrote:
> Alex Hunsaker 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 c
On Fri, Jun 10, 2011 at 12:38, Tom Lane 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-- then
I tried com
On Fri, Jun 10, 2011 at 00:53, Greg Smith 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
&g
On Thu, Jun 9, 2011 at 22:02, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Thu, Jun 9, 2011 at 21:05, Tom Lane 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
>&
On Thu, Jun 9, 2011 at 21:05, Tom Lane 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 there already
>
On Wed, Jun 8, 2011 at 16:20, Mark Kirkwood
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, probabl
On Wed, Jun 8, 2011 at 12:49, Tom Lane wrote:
> Alex Hunsaker 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
>&g
On Wed, Jun 8, 2011 at 12:12, Alex Hunsaker 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:0
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:
On Tue, Jun 7, 2011 at 12:42, Alex Hunsaker wrote:
> On Tue, Jun 7, 2011 at 12:22, Tom Lane wrote:
>> Alex Hunsaker writes:
>>> Im looking at the "raw" perl 5.10.0 source... I wonder if apple is
>>> shipping a modified version?
>>
>>
On Tue, Jun 7, 2011 at 12:22, Tom Lane wrote:
> Alex Hunsaker 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/
> pol
On Tue, Jun 7, 2011 at 11:48, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Mon, Jun 6, 2011 at 21:16, Robert Creager
>> wrote:
>>> (gdb) bt
>>> #0 0x000100a505e4 in Perl_get_hash_seed ()
>>> #1 0x000100a69b94 in perl_parse ()
>
>> I
On Mon, Jun 6, 2011 at 21:16, Robert Creager 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 gdb-1518) (Sat Feb 12 02:52
On Sat, Apr 23, 2011 at 07:00, Andrew Dunstan 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 Devel::PPPort guy said patches
On Sat, Apr 23, 2011 at 07:00, Andrew Dunstan 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
>> ...
&g
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
http://s
On Mon, Apr 18, 2011 at 19:50, Josh Berkus 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 have a hard enoug
On Thu, Feb 17, 2011 at 16:18, Alvaro Herrera
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, yes.
--
Sent via
On Wed, Feb 16, 2011 at 12:21, Alvaro Herrera
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 me.
--
Sent via pgsql
On Tue, Feb 15, 2011 at 14:12, Robert Haas wrote:
> On Tue, Feb 15, 2011 at 3:26 PM, marcin mank 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 duplicate the dash, i.e.:
>> uuid--ossp-1.0
On Mon, Feb 14, 2011 at 09:49, Stephen Frost 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. :)
>
>> So t
On Sun, Feb 6, 2011 at 15:31, Andrew Dunstan 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 a consistent vi
On Sat, Feb 12, 2011 at 01:50, Jan Urbański 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
On Fri, Feb 11, 2011 at 17:17, Alexey Klyukin wrote:
> So, here is the v8. Instead of rewriting the encode_array_literal I've added
> another function, encode_type_literal (could use a better name).
> ...
> I can easily convert the encode_array_literal to just call this function, but
> not encode_
On Wed, Feb 9, 2011 at 02:10, Jan Urbański wrote:
> On 06/02/11 20:12, Jan Urbański wrote:
>> On 27/01/11 22:58, Jan Urbański wrote:
>>> On 23/12/10 14:56, Jan Urbański wrote:
Here's a patch implementing traceback support for PL/Python mentioned in
http://archives.postgresql.org/pgsql-ha
On Fri, Feb 11, 2011 at 16:42, David E. Wheeler wrote:
> On Feb 11, 2011, at 12:57 PM, Alex Hunsaker wrote:
>
>> Yay! 1
>
> Yes, this is all good. But it still seems to me that:
>
> * If your database is neither utf-8 no sql_ascii
You mean... we have been talking past ea
On Fri, Feb 11, 2011 at 11:07, David E. Wheeler wrote:
> I don't understand where the bug is. If a string is encoded in utf-8 Perl
> will not treat it as such unless the utf-8 flag is set.
Ok so I think we agreed this is right:
$ perl -E 'use URI::Escape; my $str = uri_unescape("%C3%A9"); say
s
1 - 100 of 340 matches
Mail list logo
