On Mon, Dec 20, 2010 at 00:39, Alex Hunsaker wrote:
> In further review over caffeine this morning I noticed there are a few
> places I missed: plperl_build_tuple_result(), plperl_modify_tuple()
> and Util.XS.
And here is v3, fixes the above and also makes sure to properly
encode/d
On Wed, Dec 22, 2010 at 11:24, David E. Wheeler wrote:
> On Dec 21, 2010, at 8:19 PM, Alex Hunsaker wrote:
>
>> And here is v3, [ ...]
> Awesome. Would you add it to
> https://commitfest.postgresql.org/action/commitfest_view?id=9 please?
Nah, I was willing to spend a coupl
On Wed, Jan 12, 2011 at 06:34, Alexey Klyukin wrote:
>
> On Jan 12, 2011, at 4:06 AM, Robert Haas wrote:
>> By the same token, I'm not convinced it's a good idea for this
>> behavior to be off by default. Surely many people will altogether
>> fail to notice that it's an option? If we're going to
On Wed, Jan 12, 2011 at 22:12, Tom Lane wrote:
> "David E. Wheeler" writes:
>> On Jan 12, 2011, at 5:14 AM, Alexey Klyukin wrote:
>>> You mean packing both a string representation and a reference to a single
>>> SV * value?
>
>> Dunno, I'm not a guts guy.
>
>> I haven't considered that (lack of
; If I'm wrong about that, then by all means let's use some perl Magic
> (that's a technical term) to achieve this. IIRC Alex recently posted some
> code that might be instructive about this.
There might be a more gutsy way to do this so that 'ref' gives you
back
On Thu, Jan 13, 2011 at 01:06, Martijn van Oosterhout wrote:
> On Thu, Jan 13, 2011 at 12:06:33AM -0700, Alex Hunsaker wrote:
>> > I had supposed that it would be possible to do the string conversion
>> > lazily, ie, only if the string value was actually demanded.
>>
&
On Tue, Dec 7, 2010 at 07:24, Tim Bunce wrote:
> Changes:
>
> Sets the local $_TD via C instead of passing an extra argument.
> So functions no longer start with "our $_TD; local $_TD = shift;"
>
> Pre-extend stack for trigger arguments for slight performance gain.
>
> Passes installcheck
On Wed, Jan 12, 2011 at 13:04, Alexey Klyukin wrote:
>
> On Jan 12, 2011, at 8:52 PM, David E. Wheeler wrote:
>
>> On Jan 12, 2011, at 5:14 AM, Alexey Klyukin wrote:
>>
>>> You mean packing both a string representation and a reference to a single
>>> SV * value?
>>
>> Dunno, I'm not a guts guy.
>
On Sat, Jan 15, 2011 at 14:20, Andy Colson wrote:
>
> This is a review of "plperl encoding issues"
>
> https://commitfest.postgresql.org/action/patch_view?id=452
Thanks for taking the time to review!
[...]
>
> The Patch:
> ==
> Applies clean to git head as of January 15 2011. PG built
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, 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
(They come from
the "use Opcode" at the top and unless you somehow installed a different
Opcode module than what your perl has...).
Im running a non threaded 5.16.0 and I don't see OP_SETSTATE anywhere:
$ pwd
/home/alex/src/postgresql/src/pl/plperl
$ grep -RI 'OP_SETSTATE'
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 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
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, Feb 1, 2010 at 03:58, Tim Bunce wrote:
> On Sat, Jan 30, 2010 at 06:38:59PM -0700, Alex Hunsaker wrote:
>
>> plc_safe_ok.pl seems to loose its CVS $PostgreSQL$ keyword.
>Probably a slip-up when I merged the changes from HEAD up through my
>chain of branches.
Can you sen
On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
> This is an update the fourth of the patches to be split out from the
> former 'plperl feature patch 1'.
>
> Changes in this patch:
>
> - Adds plperl.on_trusted_init and plperl.on_untrusted_init GUCs
> on_trusted_init is PGC_USERSET, on_untrusted
On Tue, Feb 2, 2010 at 20:46, Robert Haas wrote:
> On Tue, Feb 2, 2010 at 10:46 PM, Robert Haas wrote:
>> On Tue, Feb 2, 2010 at 10:42 PM, Alex Hunsaker wrote:
>>> On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
>>>> This is an update the fourth of the pa
On Tue, Feb 2, 2010 at 21:38, Tom Lane wrote:
> Alex Hunsaker writes:
>> Yeah the both is gross. How about:
>> plperl.on_plperl_init
>> plperl.on_plperlu_init
>> plperl.on_init ?
>
> I like the first two. The problem of selecting a good name for the
> third
On Tue, Feb 2, 2010 at 22:50, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Tue, Feb 2, 2010 at 21:38, Tom Lane wrote:
>>> Alex Hunsaker writes:
>>>> Yeah the both is gross. How about:
>>>> plperl.on_plperl_init
>>>> plperl.on_plpe
On Wed, Feb 3, 2010 at 00:46, Alex Hunsaker wrote:
> On Tue, Feb 2, 2010 at 22:50, Tom Lane wrote:
>> Alex Hunsaker writes:
>>> On Tue, Feb 2, 2010 at 21:38, Tom Lane wrote:
>>>> Alex Hunsaker writes:
>>>>> Yeah the both is g
On Wed, Feb 3, 2010 at 06:41, Andrew Dunstan wrote:
>
>
> Alex Hunsaker wrote:
>>>>>
>>>>> Well its already in.
>>>>>
>>>>
>>>> Well *that's* easily fixed. I think it's a bad idea, because it's
>>
On Wed, Feb 3, 2010 at 09:31, Tim Bunce wrote:
> On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
>> On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
>>
>> > SPI functions are not available when the code is run.
>>
>> Hrm, we might want to s
On Wed, Feb 3, 2010 at 10:18, Alex Hunsaker wrote:
> On Wed, Feb 3, 2010 at 09:31, Tim Bunce wrote:
>> On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
>> If we're going to bikeshed the names, I'd suggest:
>>
>> plperl.on_init
On Wed, Feb 3, 2010 at 10:56, Tim Bunce wrote:
> On Wed, Feb 03, 2010 at 10:18:51AM -0700, Alex Hunsaker wrote:
>> On Wed, Feb 3, 2010 at 09:31, Tim Bunce wrote:
>> > On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
>> >> On Sat, Jan 30, 2
On Wed, Feb 3, 2010 at 11:28, Tom Lane wrote:
> Tim Bunce writes:
>> I do see a need for a GRANT check and I'm adding one now (based on
>> the code in CreateFunction() in functioncmds.c - thanks to RhodiumToad
>> on IRC for the pointer).
>
> What exactly are you proposing to check, and where, and
On Wed, Feb 3, 2010 at 11:43, Alex Hunsaker wrote:
> On Wed, Feb 3, 2010 at 11:28, Tom Lane wrote:
>> Tim Bunce writes:
>>> I do see a need for a GRANT check and I'm adding one now (based on
>>> the code in CreateFunction() in functioncmds.c - thanks to Rhodiu
On Wed, Feb 3, 2010 at 12:04, Tom Lane wrote:
> Andrew Dunstan writes:
>> %_SHARED has been around for several years now, and if there are genuine
>> security concerns about it ISTM they would apply today, regardless of
>> these patches.
>
> Yes. I am not at all happy about inserting nonstandard
On Fri, Feb 5, 2010 at 06:40, Tim Bunce wrote:
> This is the third update to the fourth of the patches to be split out
> from the former 'plperl feature patch 1'.
>
> Changes in this patch:
>
> - Added plperl.on_plperl_init and plperl.on_plperlu_init GUCs
> Both are PGC_SUSET
> SPI functions
On Fri, Feb 12, 2010 at 13:42, Andrew Dunstan wrote:
>
>
> Alex Hunsaker wrote:
>>>>
>>>> in plc_safe_ok.pl
>>>> +use vars qw($PLContainer $SafeClass @EvalInSafe @ShareIntoSafe);
>>>> ...the *_init gucs to be able to stick things into
&g
On Fri, Feb 12, 2010 at 17:57, Andrew Dunstan wrote:
> Another objection is that discussion on this facility has been pretty scant.
> I think that's putting it mildly.
Well I can certainly attest to that seeing as how I spotted it purely
by review...
--
Sent via pgsql-hackers mailing list (pgsq
On Fri, Feb 12, 2010 at 17:57, Andrew Dunstan wrote:
>r
>
> Alex Hunsaker wrote:
>>
>> Yes it could allow people who
>> can set the plperl.*_init functions to muck with the safe.
>
> It's quite easy to subvert Safe.pm today, sadly. ...
If anything that so
On Fri, Feb 12, 2010 at 19:14, Robert Haas wrote:
> Sounds like it would considerably simplify
> the patch, too.
I overstated that. The way its done now we could just change the
decelerations to 'my' and drop an if block. Id be in favor of more or
less keeping the internals as implemented in th
On Wed, Feb 24, 2010 at 14:35, Richard Huxton wrote:
> With plperl.on_init allowing the loading of modules, might there be some
> merit (and little cost) in allowing the same style of function-mapping as
> with C functions?
>
> CREATE FUNCTION add_one(integer) RETURNS integer
> AS 'DIRECTORY/f
On Thu, Feb 25, 2010 at 20:40, Tom Lane wrote:
> It's not going to be easier to implement. Yeah, it would be easy to
> provide a global switch via a GUC setting, but that's not going to be
> helpful, because this is the sort of thing that really needs to be
> managed per-query. Almost any nontri
On Thu, Feb 25, 2010 at 21:28, Alex Hunsaker wrote:
> Not to mention you can already do this more or less client side with a
> nice driver.
> [ uninformed noise ... ]
I did seem to miss the part where everyone thinks this is a crock...
But I don't remember seeing numbers on par
On Thu, Feb 25, 2010 at 22:11, Tom Lane wrote:
> Alex Hunsaker writes:
> Uh, no, this isn't about saving either parse time or bandwidth.
> The discussion is about when to expend more planning time in hopes
> of getting better plans.
This is what im tripping over:
> > Bru
On Fri, Feb 26, 2010 at 08:07, Tom Lane wrote:
> Alex Hunsaker writes:
>> Let me see if I can sum up what I was trying to say:
>> [ this can be solved by using or avoiding prepared statements ]
>
> Not really. The place where that argument really fails is inside
> se
On Fri, Feb 26, 2010 at 09:50, Robert Haas wrote:
> On Fri, Feb 26, 2010 at 1:29 AM, Alex Hunsaker wrote:
>> Prepared plans + exec plan (new guc/ protocol thing):
>> Use: not quite sure
>> Problems: slow because it would replan every time
>> Solutions: use a prepare
On Mon, Mar 8, 2010 at 09:03, Tom Lane wrote:
> Tim Bunce writes:
>> 3. requires Safe 2.25 (which has assorted fixes, including security).
> #3 is still an absolute nonstarter, especially for a patch that we'd
> wish to backpatch.
FWIW I think its a given you probably always want the latest ver
On Mon, Mar 8, 2010 at 10:14, Tom Lane wrote:
> "David E. Wheeler" writes:
>> On Mar 8, 2010, at 8:03 AM, Tom Lane wrote:
>>> #3 is still an absolute nonstarter, especially for a patch that we'd
>>> wish to backpatch.
>
>> You're at least going to want to exclude Safe 2.20 - 2.23, IIUC.
>
> If th
On Thu, Mar 18, 2010 at 15:07, Jeff Davis wrote:
> On Thu, 2010-03-18 at 16:50 -0400, Tom Lane wrote:
>> The VM is (a) not compressed and (b) not correctness-critical.
>> Wrong bit values don't do any serious damage.
>
> The VM cause wrong results if a bit is set that's not supposed to be --
> rig
On Mon, Mar 29, 2010 at 12:17, Simon Riggs wrote:
> You're not addressing the original point. I have been asked how would
> users know which tables have been removed and whether there is a way of
> checking that.
Uhh... they wont be in the explain output... Seems simple enough.
--
Sent via pgs
On Mon, Mar 29, 2010 at 13:41, Simon Riggs wrote:
>> Uhh... they wont be in the explain output... Seems simple enough.
>
> That is exactly what I replied, though nobody felt that was a great
> answer.
Maybe I missed it, but why exactly do they care? About the only
reason I can think *i* would c
If you do:
# DO $do$ 1; $do$ LANGUAGE plperlu;
# DO $do$ 1; $do$ LANGUAGE plperl;
You get a segfault as we try to SvREFCNT_dec(...); for the wrong
interpreter. To fix push down the restore_context() so that we do the
above on the correct perl interpreter.
--
*** a/src/pl/plperl/plperl.c
--- b/s
On Sun, Apr 18, 2010 at 13:17, Tom Lane wrote:
> Alex Hunsaker writes:
>> You get a segfault as we try to SvREFCNT_dec(...);
>
> Hmm. I don't see a segfault on my machine, but I agree that this looks
> bogus. I changed it to this order instead:
> [ ... ]
> so
On Mon, May 3, 2010 at 14:04, Andrew Dunstan wrote:
>
> [ Awesome work getting buildfarm support for git ]
> Note, this is running from my test git repo, not the community's repo.
BTW +1 for gitting (heh, git puns are fun) a good git repo published.
Ive given up trying to trust it for back branc
On Tue, May 18, 2010 at 14:54, Jesper Krogh wrote:
> Hi.
>
> I'm trying to do a test move of one of our applications onto 9.0beta1.
> We use storable and serializes data into a bytea column in the database.
> [ snip insert/select using bytea ]
> 8.4
> id | t
On Tue, May 18, 2010 at 15:20, Jesper Krogh wrote:
> On 2010-05-18 23:12, Alex Hunsaker wrote:
>>
>> set bytea_output 'escape';
>
> That was it. Knowing what the problem was I had no problem finding it in the
> release notes.
>
> May I ask whats the rea
On Wed, May 19, 2010 at 09:05, Robert Haas wrote:
> On Wed, May 19, 2010 at 11:00 AM, Kenneth Marshall wrote:
>> Changing something like that within the minor release arc is
>> not a good idea. It would be better to have it on by default and
>> if the driver developers are not up to use it, they
t.
Surely you can throw in some captcha plugins to try to reduce the spam
posted from the web UI.
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
mns-of-radio-buttons approach as MediaWiki. If the goal is a
> tool to reduce friction and increase involvement, you want a smoother
> UX.
Nothing that could not be tweaked with a plugin or core code
modification here either. Not sure about the magnitude of the effort
required, though.
ybe there's something fundamentally wrong with every existing bug
tracker (e.g. they don't fix bugs for you?) Well, just kidding. ;-)
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alex writes:
> Peter Eisentraut writes:
>
>> I have been reviewing how our new libpq URL syntax compares against
>> existing implementations of URL syntaxes in other drivers or
>> higher-level access libraries. In the case of SQLAlchemy, there is an
>> incompatibi
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, 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 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
Dave Page writes:
> On Tue, Jun 19, 2012 at 4:43 AM, Robert Haas wrote:
>>
>>
>> Please add this patch here so that it doesn't get lost in the shuffle:
>>
>> https://commitfest.postgresql.org/action/commitfest_view/open
>
> Hmm, that raises an interesting question (though maybe I've just
> miss
Dave Page writes:
> On Tue, Jun 19, 2012 at 11:04 AM, Alex Shulgin wrote:
>>
>> In a real bug-tracking system we would create a new bug/ticket and set
>> it's target version to 'candidate for next minor release' or something
>> like that. This way, if
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.
&
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.
>
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 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 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 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 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 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 Sun, Oct 31, 2010 at 12:00, Andrew Dunstan wrote:
> On 10/31/2010 11:44 AM, Tom Lane wrote:
>> Good catch, patch reverted (and regression test added).
>
> Well, I guess that answers the question of why we needed it, which nobody
> could answer before. I'm not sure I exactly understand what's go
On Sun, Oct 31, 2010 at 15:17, Andrew Dunstan wrote:
> On 10/31/2010 04:40 PM, Alex Hunsaker wrote:
>> And with the change we get the same
>> proc_desc for triggers and non triggers, so if the trigger function
>> gets called first, any call to the direct function will use
On Mon, Nov 1, 2010 at 09:28, Tom Lane wrote:
> I think the crash is dependent on the fact that the function is created
> and called in the same session. That means the validator gets called on
> it first, and the validator not unreasonably assumes istrigger = true,
> and then it calls compile_pl
On Mon, Nov 1, 2010 at 15:24, Alex Hunsaker wrote:
houldn't cache any of the setup but just redo it all every time.
>
> Huh? I might try and argue that if the new test was more complex than
> 2 compares :P. In-fact the way it stands now we uselessly grab the
> functions pg_
On Mon, Nov 1, 2010 at 16:59, Tom Lane wrote:
> Alex Hunsaker writes:
>> Speaking of which, pltcl stores the trigger reloid instead of a flag
>> (it also uses tg_reloid in the internal proname). It seems a tad
>> excessive to have one function *per* trigger table.
>
On Wed, Nov 3, 2010 at 10:28, Tom Lane wrote:
> OK, applied.
Thanks!
> I notice that plpython is also using the trigger relation's OID, but I
> don't know that language well enough to tell whether it really needs to.
This thread was started by someone working a plpython a validator, I
figured t
On Wed, Nov 3, 2010 at 14:43, Jan Urbański wrote:
> By the way, I'm leaning in the direction of not using a Python
> dictionary for the cache, but a standard Postgres HTAB instead. It's
> more like other pls this way, and you can get rid of PyCObjects (which
> are deprecated BTW) and messing aroun
On Thu, Nov 4, 2010 at 03:54, Hannu Krosing wrote:
>> > try:
>> > plpy.execute("insert into foo values(1)")
>> > except plpy.UniqueViolation, e:
>> > plpy.notice("Ooops, you got yourself a SQLSTATE %d", e.sqlstate)
>>
>> Are you sure that having each try/except use a subtransaction is the
On Thu, Nov 4, 2010 at 13:43, Hannu Krosing wrote:
> So your plan was to have some savepoint before each execute ?
>
> How would one rollback the latest transaction ?
It is always rolled back. Its how plperl works today:
create or replace function foo() returns int as $$
eval {
spi_exec_quer
On Thu, Nov 4, 2010 at 14:29, Alex Hunsaker wrote:
> On Thu, Nov 4, 2010 at 13:43, Hannu Krosing wrote:
>> So your plan was to have some savepoint before each execute ?
>>
>> How would one rollback the latest transaction ?
>
> It is always rolled back. Its how plpe
it will still get killed first:
$ ps ax -o rss,pid,size,vsize,args | sort -n
...
2416 1680 588 46548 /usr/lib/postfix/master
2424 1696 640 46748 qmgr -l -t fifo -u
2956 3395 2416 244644 postgres: autovacuum launcher process
3116 2216 720 65464 sshd: alex [priv]
4096 3393 108
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
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 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
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 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 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 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 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?
>>
>>
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 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
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 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 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 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 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 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 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
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 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
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 Sat, Jan 15, 2011 at 15:48, Alex Hunsaker wrote:
> On Wed, Jan 12, 2011 at 13:04, Alexey Klyukin wrote:
>>
>> On Jan 12, 2011, at 8:52 PM, David E. Wheeler wrote:
>>
>>> On Jan 12, 2011, at 5:14 AM, Alexey Klyukin wrote:
>>>
>>>> You mean p
On Wed, Jan 26, 2011 at 12:44, Alexey Klyukin wrote:
> Hi,
>
> On Jan 26, 2011, at 8:45 PM, Alex Hunsaker wrote:
>
>> On Sat, Jan 15, 2011 at 15:48, Alex Hunsaker wrote:
>>> On Wed, Jan 12, 2011 at 13:04, Alexey Klyukin
>>> wrote:
>>>>
>>
101 - 200 of 654 matches
Mail list logo
