On ons, 2010-01-06 at 23:46 +0100, Arie Bikker wrote:
> Hope this is the right attachement type (I'm new at this)
> BTW. here a some nice examples:
>
> - Get the number of attributes of the first childnode:
>
> select ( xpath('count(@*)',(xpath('*[1]',' g="j"/>'))[1]))[1];
>
> - an alternative f
On sön, 2010-01-10 at 15:27 -0800, Josh Berkus wrote:
> On 1/10/10 2:34 PM, Peter Eisentraut wrote:
> > On tor, 2009-11-05 at 19:24 +0200, Peter Eisentraut wrote:
> >> I'm planning to work on typed tables support. The idea is that you
> >> create a table out of a composite type (as opposed to the
On mån, 2010-01-11 at 04:05 +, Greg Sabino Mullane wrote:
> On the one hand, I don't see the problem with ASCII here - the
> payload is meant as a quick shorthand convenience, not a literal payload
> of important information.
Is it not? The notify name itself is already a quick shorthand
conv
Robert,
we have benchmark for rbtree
http://www.sai.msu.su/~megera/wiki/2009-07-27
rbtree, actually, fix corner cases with ordered input, with little
overhead.
As you may see from knngist patch, rbtree used in gist code, so, please,
leave rbtree code as is.
Oleg
On Sun, 10 Jan 2010, Robert Haas
2010/1/11 Robert Haas :
> On Tue, Jan 5, 2010 at 8:23 AM, Pavel Stehule wrote:
>> 2010/1/5 Tom Lane :
>>> Robert Haas writes:
On Mon, Jan 4, 2010 at 2:51 PM, Pavel Stehule
wrote:
> I don't have a problem to write second and safe fmtId
> function (with technique used in dumputi
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>> Using DBI/DBD::Pg would raise another issue - what version of libpq
>> would it be using? Not the one in the build being tested, that's for
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>>> - do we need to limit the payload to pure ASCII ? I think yes, we need
>>> to. I also think we need to reject other payloads with elog(ERROR...).
>...[snip other followups]
On the one hand, I don't see the problem with ASCII here - the
pay
On Tue, Jan 5, 2010 at 8:23 AM, Pavel Stehule wrote:
> 2010/1/5 Tom Lane :
>> Robert Haas writes:
>>> On Mon, Jan 4, 2010 at 2:51 PM, Pavel Stehule
>>> wrote:
I don't have a problem to write second and safe fmtId
function (with technique used in dumputils don't need to modify
lib
On Sun, Jan 10, 2010 at 6:24 PM, Josh Berkus wrote:
>> Now the other approach we could take is that we'll ship *something*
>> on 7 Mar, even if it's less stable than what we've traditionally
>> considered to be beta quality. I don't think that really helps
>> much though; it just means we need mo
Magnus,
* Magnus Hagander (mag...@hagander.net) wrote:
> The attached patch implements RADIUS authentication (RFC2865-compatible).
Great! We have a few environments which use RADIUS auth, nice that PG
might be able to use that auth method in the future.
I'm not a fan of having the shared secr
On Mon, Jan 11, 2010 at 2:42 AM, Robert Haas wrote:
> The coding pattern that this patch uses also merits some discussion.
> Basically, rbtree.c is a generic implementation of red-black trees -
> from a textbook - which ginbulk.c then uses for GIN. One possible
> advantage of this implementation
On Thu, Dec 31, 2009 at 4:19 PM, Robert Haas wrote:
> My other question is as related to performance. Can you provide a
> test case that shows the performance improvement with this patch?
So, we still don't have a test case for this patch. During the
November CommitFest, Greg Smith griped a bit
On Sun, Jan 10, 2010 at 4:54 PM, Tom Lane wrote:
> Robert Haas writes:
>> I have looked this over a little bit and I guess I don't see why the
>> lack of a grand plan for how to organize all of our permissions checks
>> ought to keep us from removing this one on the grounds of redundancy.
>> We h
Tim Bunce writes:
> I didn't get any significant feedback from the earlier draft so here's
> the finished 'feature patch 1' for plperl. (This builds on my earlier
> plperl refactoring patch, and the follow-on ppport.h patch.)
Just looking over this patch, I don't think it's nearly robust enough
Dimitri Fontaine wrote:
> Andrew Dunstan writes:
> > That is assuming that the MUA gives you the option of specifying the
> > attachment MIME type. Many (including mine) do not. It would mean an extra
> > step - I'd have to gzip each patch or something like that. That would be
> > unfortunate,as w
Andrew Dunstan writes:
> Tom Lane wrote:
>> No, they have to all be PGC_POSTMASTER to answer that concern. Only
>> breaking things for superusers isn't really that big an improvement
>> over breaking them for everybody.
> Well, I don't know about Tim but I think I could live with that. And
> wh
I wrote:
> Basically I think we have to fix this by ensuring that an error escape
> can't occur while a relcache entry is in a partially rebuilt state.
Attached is a draft patch for this. In addition to fixing the stated
problem, it also takes care of a thinko that I found along the way:
Relation
On Jan 10, 2010, at 11:17 AM, Robert Haas wrote:
> It's nicer to write:
>
> plperl.on_perl_init='strict,warnings,LDAP,HTML::Parser,Archive::Zip'
>
> rather than:
>
> plperl.on_perl_init='use strict;use warnings;use LDAP;use
> HTML::Parser;use Archive::Zip;'
Well, no, because sometimes I just w
On 1/10/10 2:34 PM, Peter Eisentraut wrote:
> On tor, 2009-11-05 at 19:24 +0200, Peter Eisentraut wrote:
>> I'm planning to work on typed tables support. The idea is that you
>> create a table out of a composite type (as opposed to the other way
>> around, which is currently done automatically).
> Now the other approach we could take is that we'll ship *something*
> on 7 Mar, even if it's less stable than what we've traditionally
> considered to be beta quality. I don't think that really helps
> much though; it just means we need more time in beta.
Well, we're shipping an alpha, aren't
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
As an example, if people were using such functionality then the DBA
couldn't start preloading plperl for performance without breaking
behavior that some of his users might be depending on.
If we made plperl.on_perl_in
> Currently there is no way of knowing what the average/current transit
> time is on replication, no way of knowing what is happening if we go
> idle etc.. Those things need to be included because they are not
> otherwise accessible. Cars need windows, not just a finely tuned engine.
Like I said,
On tor, 2009-11-05 at 19:24 +0200, Peter Eisentraut wrote:
> I'm planning to work on typed tables support. The idea is that you
> create a table out of a composite type (as opposed to the other way
> around, which is currently done automatically).
>
> CREATE TYPE persons_type AS (name text, bdate
On Sun, 2010-01-10 at 12:10 -0800, Josh Berkus wrote:
> > We need monitoring anywhere we have a max_* parameter. Otherwise we
> > won't know how close we are to disaster until we hit the limit and
> > things break down. Otherwise we will have to set parameters by trial and
> > error, or set them so
Andrew Dunstan writes:
> Tom Lane wrote:
>> As an example, if people were using such functionality then the DBA
>> couldn't start preloading plperl for performance without breaking
>> behavior that some of his users might be depending on.
> If we made plperl.on_perl_init PGC_POSTMASTER and the ot
Robert Haas writes:
> I have looked this over a little bit and I guess I don't see why the
> lack of a grand plan for how to organize all of our permissions checks
> ought to keep us from removing this one on the grounds of redundancy.
> We have to attack this problem in small pieces if we're goin
On Sun, Jan 10, 2010 at 2:58 PM, Andrew Dunstan wrote:
> I don't know why you would do either of these things. I at least would load
> one module which would in turn load others. So I'd expect to see something
> like this:
>
> plperl.on_perl_init = 'use lib "/my/app"; use MyApp::Pg;'
>
> I think
On Sun, Dec 20, 2009 at 10:53 PM, I wrote:
> On Thu, Dec 17, 2009 at 7:19 PM, Tom Lane wrote:
>> KaiGai Kohei writes:
>>> [ patch to remove EnableDisableRule's permissions check ]
>>
>> I don't particularly like this patch, mainly because I disagree with
>> randomly removing permissions checks wi
Tom Lane wrote:
Robert Haas writes:
On Sun, Jan 10, 2010 at 1:49 PM, Tom Lane wrote:
What happens when the supplied code
has errors, takes an unreasonable amount of time to run, does something
unsafe, depends on the backend not being in an error state already, etc
etc?
On Sun, Jan 10, 2010 at 2:49 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jan 10, 2010 at 1:49 PM, Tom Lane wrote:
>>> What happens when the supplied code
>>> has errors, takes an unreasonable amount of time to run, does something
>>> unsafe, depends on the backend not being in an error
2010/1/10 Tom Lane :
>
> I've applied a patch along these lines.
>
Cool. Thanks, that works great.
Cheers,
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> We need monitoring anywhere we have a max_* parameter. Otherwise we
> won't know how close we are to disaster until we hit the limit and
> things break down. Otherwise we will have to set parameters by trial and
> error, or set them so high they are meaningless.
I agree.
Thing is, though, we h
Robert Haas wrote:
Anyway, I think you've put this pretty well here: the current
definition will make people WANT to use multi-line values for this,
and we don't support that. I think Tim's example is fairly contrived
- setting a global variable here does not seem likely to be useful to
very m
Robert Haas writes:
> On Sun, Jan 10, 2010 at 1:49 PM, Tom Lane wrote:
>> What happens when the supplied code
>> has errors, takes an unreasonable amount of time to run, does something
>> unsafe, depends on the backend not being in an error state already, etc
>> etc?
> Same thing that happens wh
On Sun, Jan 10, 2010 at 1:49 PM, Tom Lane wrote:
> Tim Bunce writes:
>> On Fri, Jan 08, 2010 at 10:36:43PM -0500, Robert Haas wrote:
>>> I kind of thought Tom said these were a bad idea, and I think I kind
>>> of agree.
>
>> Tom had some concerns which I believe I've addressed.
>
> You haven't ad
Tim Bunce writes:
> On Fri, Jan 08, 2010 at 10:36:43PM -0500, Robert Haas wrote:
>> I kind of thought Tom said these were a bad idea, and I think I kind
>> of agree.
> Tom had some concerns which I believe I've addressed.
You haven't addressed them, you've simply ignored them. For the record,
I
On Sun, Jan 10, 2010 at 05:16:48AM +0200, Devrim GUNDUZ wrote:
>
> Alvaro, one of our hackers and committers and my colleague more than 4
> years, had a new baby today.
>
> Congrats Alvaro for his second daughter !
In short, +1 from Alvaro and Sra. Herrera :)
> -committers, please commit your
Tom Lane írta:
> Boszormenyi Zoltan writes:
>
>> Tom Lane írta:
>>
>>> I think that the compiler has caught an actual mistake here.
>>>
>
>
>> Yes, it's a mistake, but not an actual bug.
>> The intent was to be able to catch unhandled
>> cases in the application, just as in ecpg_
Tim Bunce writes:
> On Sun, Jan 10, 2010 at 01:16:13AM -0500, Tom Lane wrote:
>> Doesn't make forcibly remove the target file if the command fails?
> Andrew, perhaps you could apply the attached to fix that. (Or I could
> bundle it into one of the split out plperl feature patches.)
Applied.
On Sun, Jan 10, 2010 at 18:55, Peter Eisentraut wrote:
> On sön, 2010-01-10 at 14:25 +0100, Magnus Hagander wrote:
>> The attached patch implements RADIUS authentication (RFC2865-compatible).
>>
>> The main usecase for me in this is the ability to use (token based)
>> one-time-password systems eas
Dean Rasheed writes:
> 2010/1/9 Tom Lane :
>> I think that a variant of your idea could be made to work: change
>> plpgsql_LookupIdentifiers to a three-state variable (which'd basically
>> mean "in DECLARE, in a SQL expression, anywhere else"), do no lookups in
>> DECLARE, and in SQL expressions d
On sön, 2010-01-10 at 14:25 +0100, Magnus Hagander wrote:
> The attached patch implements RADIUS authentication (RFC2865-compatible).
>
> The main usecase for me in this is the ability to use (token based)
> one-time-password systems easily with PostgreSQL. These systems almost
> always support RA
On sön, 2010-01-10 at 01:38 -0500, Tom Lane wrote:
> Now the other approach we could take is that we'll ship *something*
> on 7 Mar, even if it's less stable than what we've traditionally
> considered to be beta quality. I don't think that really helps
> much though; it just means we need more tim
On Sun, 2010-01-10 at 18:40 +0200, Heikki Linnakangas wrote:
> > We
> > don't have any way of monitoring that, as yet. Setting ps display is not
> > enough here.
>
> Yeah, monitoring would be nice too. But what I was wondering is whether
> we need some way of stopping that from filling the disk i
Magnus Hagander writes:
> On Fri, Dec 4, 2009 at 11:42, Tsutomu Yamada wrote:
>> I was checked where the string converted with "%ld" is used.
>> An especially fatal part is not found excluding one of plperl.
> I have not looked at the plperl stuff yet. I'd appreciate a comment
> from someone who
Boszormenyi Zoltan writes:
> Tom Lane írta:
>> I think that the compiler has caught an actual mistake here.
> Yes, it's a mistake, but not an actual bug.
> The intent was to be able to catch unhandled
> cases in the application, just as in ecpg_dynamic_type().
> The fix for sqlda_dynamic_type() i
On Fri, Dec 4, 2009 at 11:42, Tsutomu Yamada wrote:
> The following patches support Windows x64.
>
> 1) use intptr_t for Datum and pointer macros. (to support Windows LLP64)
> almost the same as that post before.
> http://archives.postgresql.org/pgsql-hackers/2009-06/threads.php#01364
>
> 2) u
Simon Riggs wrote:
> On Fri, 2010-01-08 at 14:20 -0800, Josh Berkus wrote:
>> On 1/8/10 1:16 PM, Heikki Linnakangas wrote:
>>> * A standby that connects to master, initiates streaming, and then sits
>>> idle without stalls recycling of old WAL files in the master. That will
>>> eventually lead to a
Tom Lane írta:
> Magnus Hagander writes:
>
>> The ecpg patch at
>> http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=2f567552
>> causes a compile warning on win64 (andi think win32, but I didn't
>> recheck that). Specifically, line 140 of typename.c has:
>> return (-type)
Magnus Hagander writes:
> The ecpg patch at
> http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=2f567552
> causes a compile warning on win64 (andi think win32, but I didn't
> recheck that). Specifically, line 140 of typename.c has:
> return (-type);
> Where type is of type
On Sun, 2009-12-27 at 20:11 +0100, Andres Freund wrote:
> On Tuesday 22 December 2009 11:42:30 Simon Riggs wrote:
> > On Tue, 2009-12-22 at 03:19 +0100, Andres Freund wrote:
> > > On Monday 21 December 2009 16:48:52 Simon Riggs wrote:
> > > > Giving the drop database a snapshot is not the answer. I
On Sun, Jan 10, 2010 at 13:44, Magnus Hagander wrote:
> On Sun, Jan 10, 2010 at 13:33, James Mansion
> wrote:
>> Tom Lane wrote:
>>>
>>> There's another copy of ListenSocket[] in the BackendParameters struct.
>>> I also wonder about postmaster.c's habit of using -1 for empty slots
>>> in ListenSo
The attached patch implements RADIUS authentication (RFC2865-compatible).
The main usecase for me in this is the ability to use (token based)
one-time-password systems easily with PostgreSQL. These systems almost
always support RADIUS, and the implementation is fairly simple. RADIUS
can of course
Stefan Kaltenbrunner wrote:
Hi all!
In order to install some OS security upgrades we are going to execute
planned maintainance one the following hosts affecting the mentioned
services tomorrow (10th January 13:00-14:00 GMT). Actual expected
downtime will be a few minutes at most so this is ju
Josh Berkus wrote:
I'll also say: if we can't make time-based releases work, we're probably
dead as a project. MySQL and Ingres both tried feature-based releases,
and look where they are now.
I think you're engaging in a bit of 'post hoc ergo propter hoc'
reasoning here.
In any case,
On Sun, Jan 10, 2010 at 5:27 AM, Magnus Hagander wrote:
> On Sun, Jan 10, 2010 at 05:54, Josh Berkus wrote:
>> Peter,
>>
>>> Just to clarify: I am for sticking to the agreed dates. If some things
>>> are not ready by the necessary date plus/minus one, they won't make the
>>> release. If it's ob
On Sun, Jan 10, 2010 at 5:31 AM, Magnus Hagander wrote:
>> But really if beta slips because we don't like the looks of our open issues
>> list, thats signicantly better than the last couple releases where we held
>> everything up just to get things into CVS months after feature freeze had
>> passe
On Sun, Jan 10, 2010 at 2:09 AM, Robert Treat
wrote:
> But really if beta slips because we don't like the looks of our open issues
> list, thats signicantly better than the last couple releases where we held
> everything up just to get things into CVS months after feature freeze had
> passed us by
On Sun, Jan 10, 2010 at 13:33, James Mansion
wrote:
> Tom Lane wrote:
>>
>> There's another copy of ListenSocket[] in the BackendParameters struct.
>> I also wonder about postmaster.c's habit of using -1 for empty slots
>> in ListenSocket ... how safe is that for Win64?
>>
>
> On Windows, it shoul
Tom Lane wrote:
There's another copy of ListenSocket[] in the BackendParameters struct.
I also wonder about postmaster.c's habit of using -1 for empty slots
in ListenSocket ... how safe is that for Win64?
On Windows, it should be INVALID_SOCKET.
James
--
Sent via pgsql-hackers mailing list
On Sun, Jan 10, 2010 at 01:16:13AM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > On Sat, Jan 09, 2010 at 11:16:18PM +0200, Peter Eisentraut wrote:
> >> What's the reason for the temp file here?
>
> > Defensive. If the text2macro.pl program fails/dies then you'd be left
> > with a broken output f
Hi!
The ecpg patch at
http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=2f567552
causes a compile warning on win64 (andi think win32, but I didn't
recheck that). Specifically, line 140 of typename.c has:
return (-type);
Where type is of type Oid, which is unsigned. This cau
Congratulations Alvaro!
2010/1/10 Devrim GÜNDÜZ :
>
> Alvaro, one of our hackers and committers and my colleague more than 4
> years, had a new baby today.
>
> Congrats Alvaro for his second daughter !
>
> -committers, please commit your patches for our new baby elephant!
> --
> Devrim GÜNDÜZ, RHC
On Sat, 2010-01-09 at 08:46 -0500, Robert Haas wrote:
> it seems much better to me to have the rule than not
I think we can overplay the need for lots of rules here and the need to
chase up status every 5 minutes.
The first problem, in previous years, was patches spent too long on the
patch queu
On Fri, 2010-01-08 at 12:41 +0200, Heikki Linnakangas wrote:
> let's make the default "no failover" if no trigger file
> location is configured, and remove the notion that normal shutdown of
> master stops recovery.
+1
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers m
On Fri, 2010-01-08 at 20:36 +0100, Joachim Wieland wrote:
> The attached patch implements the idea of Heikki / Simon published in
>
> http://archives.postgresql.org/pgsql-hackers/2009-11/msg00271.php
>
> Since nobody objected to the idea in general, I have implemented it.
>
> As this is not curr
On Fri, 2010-01-08 at 20:01 -0500, Tom Lane wrote:
> I mentioned earlier that buildfarm member jaguar (that's the one that
> builds with CLOBBER_CACHE_ALWAYS) was showing suspicious intermittent
> failures. There's another one today:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguar&
On Fri, 2010-01-08 at 14:20 -0800, Josh Berkus wrote:
> On 1/8/10 1:16 PM, Heikki Linnakangas wrote:
> > * A standby that connects to master, initiates streaming, and then sits
> > idle without stalls recycling of old WAL files in the master. That will
> > eventually lead to a full disk in master.
On Fri, 2010-01-08 at 23:16 +0200, Heikki Linnakangas wrote:
> * I removed the feature that archiver was started during recovery. The
> idea of that was to enable archiving from a standby server, to relieve
> the master server of that duty, but I found it annoying because it
> causes trouble if th
Tom Lane wrote:
I mentioned earlier that buildfarm member jaguar (that's the one that
builds with CLOBBER_CACHE_ALWAYS) was showing suspicious intermittent
failures. There's another one today:
hmm I was just doing a CLOBBER_CACHE_ALWAYS build on one of my ARM based
boxes and it seems to fall
On Sun, Jan 10, 2010 at 08:09, Robert Treat
wrote:
> On Sunday 10 January 2010 01:38:07 Tom Lane wrote:
>> Robert Treat writes:
>> > ... I don't see much sense in worrying about it now; the 2 weeks between
>> > end of CF and Beta are when we need to be cut-throat. Given that this
>> > time the "m
On Sun, Jan 10, 2010 at 07:38, Tom Lane wrote:
> Robert Treat writes:
>> ... I don't see much sense in worrying about it now; the 2 weeks between end
>> of CF and Beta are when we need to be cut-throat. Given that this time the
>> "must-have" feature is already in the tree, I think you will find
On Sun, Jan 10, 2010 at 05:54, Josh Berkus wrote:
> Peter,
>
>> Just to clarify: I am for sticking to the agreed dates. If some things
>> are not ready by the necessary date plus/minus one, they won't make the
>> release. If it's obvious earlier that something won't make the date, it
>> shouldn'
Hi,
Another occasion to show ignorance, I couldn't resist!
Tom Lane writes:
> What you're
> talking about would require a great deal more maintenance effort, and
> I don't see the point compared to using a VPATH build.
I've discovered VPATH builds pretty recently, in the context of
packaging e
Andrew Dunstan writes:
> That is assuming that the MUA gives you the option of specifying the
> attachment MIME type. Many (including mine) do not. It would mean an extra
> step - I'd have to gzip each patch or something like that. That would be
> unfortunate,as well as imposing extra effort, beca
Congratulations, good things to all the family!
Devrim GÜNDÜZ writes:
> Alvaro, one of our hackers and committers and my colleague more than 4
> years, had a new baby today.
>
> Congrats Alvaro for his second daughter !
>
> -committers, please commit your patches for our new baby elepha
76 matches
Mail list logo
