On Sun, May 9, 2010 at 12:08 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> > Clearly, anything is more feature-full than boolean --- the big question
>> > is whether Tom's proposal is significantly better than boolean that we
>> > should spend the time designing and implementing it, with the
>>
Robert Haas wrote:
> > Clearly, anything is more feature-full than boolean --- the big question
> > is whether Tom's proposal is significantly better than boolean that we
> > should spend the time designing and implementing it, with the
> > possibility it will all be changed in 9.1.
>
> I doubt it
On Sat, May 8, 2010 at 10:40 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> Uh, did we decide that 'wal_keep_segments' was the best name for this
>> GUC setting? I know we shipped beta1 using that name.
>
> I thought min_wal_segments was a reasonable proposal, but it wasn't
> clear if there was
On Sat, May 8, 2010 at 6:51 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Sat, May 8, 2010 at 3:40 PM, Bruce Momjian wrote:
>> > Robert Haas wrote:
>> >> On Sat, May 8, 2010 at 2:48 PM, Bruce Momjian wrote:
>> >> > I think the concensus is to change this setting to a boolean. ?If you
>> >>
Greg Smith wrote:
> Tom Lane wrote:
>
> > Taking out features after they've been in a release is very hard, even if
> > we realize they're badly
> > designed.
> >
>
> It doesn't have to be; that's the problem the "release often" part takes
> care of. If a release has only been out a year, a
Tom Lane wrote:
Taking out features after they've been in a release is very hard, even if we
realize they're badly
designed.
It doesn't have to be; that's the problem the "release often" part takes
care of. If a release has only been out a year, and a new one comes out
saying "oh, that
Bruce Momjian writes:
> Uh, did we decide that 'wal_keep_segments' was the best name for this
> GUC setting? I know we shipped beta1 using that name.
I thought min_wal_segments was a reasonable proposal, but it wasn't
clear if there was consensus or not.
regards, tom lan
Bruce Momjian wrote:
> Simon Riggs wrote:
> > On Fri, 2010-04-30 at 12:22 -0400, Bruce Momjian wrote:
> > > >
> > > > (wal_keep_segments can be changed without restarting, right?)
> > >
> > > Should we allow -1 to mean "keep all segments"?
> >
> > Why is that not called "max_wal_segments"? wal_k
hernan gonzalez writes:
> BTW, I understand that postgresql uses locale semantics in the server code.
> But is this really necessary/appropiate in the client (psql) side?
> Couldnt we stick with C locale here?
As far as that goes, I think we have to turn on that machinery in order
to have gettext
hgonza...@gmail.com writes:
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=649
> The last explains why they do not consider it a bug:
> ISO C99 requires for %.*s to only write complete characters that fit below
> the
> precision number of bytes. If you are using say UTF-8 locale, but ISO-
Andres Freund writes:
> On Sunday 09 May 2010 01:34:18 Bruce Momjian wrote:
>> I think everyone agrees the current code is unusable, per Heikki's
>> comment about a WAL file arriving after a period of no WAL activity, and
>> look how long it took our group to even understand why that fails so
>> b
On Sunday 09 May 2010 01:34:18 Bruce Momjian wrote:
> I think everyone agrees the current code is unusable, per Heikki's
> comment about a WAL file arriving after a period of no WAL activity, and
> look how long it took our group to even understand why that fails so
> badly.
To be honest its not *t
Greg Smith wrote:
> Bruce Momjian wrote:
> > I think the big question is whether this issue is significant enough
> > that we should ignore our policy of no feature design during beta
>
> The idea that you're considering removal of a feature that we already
> have people using in beta and making
Bruce Momjian wrote:
I think the big question is whether this issue is significant enough
that we should ignore our policy of no feature design during beta
The idea that you're considering removal of a feature that we already
have people using in beta and making plans around is a policy violat
Robert Haas wrote:
> On Sat, May 8, 2010 at 3:40 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Sat, May 8, 2010 at 2:48 PM, Bruce Momjian wrote:
> >> > I think the concensus is to change this setting to a boolean. ?If you
> >> > don't want to do it, I am sure we can find someone who wil
Well, I finally found some related -rather old- issues in Bugzilla (glib)
http://sources.redhat.com/bugzilla/show_bug.cgi?id=6530
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=208308
http://sources.redhat.com/bugzilla/show_bug.cgi?id=649
The last explains why they do not consider it a bug:
I
Bruce Momjian writes:
> I have no idea why an objection from you should mean more than an
> objection from anyone else in the community, and I have no idea what an
> "extreme reaction" means, or why anyone should care.
Maybe I shouldn't say anything here. But clearly while you're spot on
that Sim
On Feb 1, 2010, at 12:18 PM, James William Pye wrote:
> Right now, I'm trying to trim some of the easy issues[1] and getting a
> project web page up. I expect to be able to make a release soon, and I'll
> follow-up to this thread when I do.
Well, I ended up doing some others things at that point
On Sat, May 8, 2010 at 3:40 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Sat, May 8, 2010 at 2:48 PM, Bruce Momjian wrote:
>> > I think the concensus is to change this setting to a boolean. ?If you
>> > don't want to do it, I am sure we can find someone who will.
>>
>> I still think we sho
Robert Haas wrote:
> On Sat, May 8, 2010 at 2:48 PM, Bruce Momjian wrote:
> > I think the concensus is to change this setting to a boolean. ?If you
> > don't want to do it, I am sure we can find someone who will.
>
> I still think we should revert to Tom's original proposal.
And Tom's proposal w
On Sat, May 8, 2010 at 2:48 PM, Bruce Momjian wrote:
> I think the concensus is to change this setting to a boolean. If you
> don't want to do it, I am sure we can find someone who will.
I still think we should revert to Tom's original proposal.
--
Robert Haas
EnterpriseDB: http://www.enterpri
Simon Riggs wrote:
> With a plugin option, I would not object to option 1.
>
> If option 1 was taken, without plugins, it's clear that would be against
> consensus.
>
> Having said that, I'll confirm now there will not be an extreme reaction
> from me if option (1) was forced, nor do I counsel th
Wow, you are right, this is bizarre...
And it's not that glibc intends to compute the length in unicode chars,
it actually counts bytes (c plain chars) -as it should- for computing
field widths...
But, for some strange reason, when there is some width calculation involved
it tries so parse the cha
Joe Conway writes:
> That's what I was thinking. I saw your other email about LATERAL for 9.1
> -- would it be helpful for me to work on this issue for 9.1? After all,
> about 7 years ago I said I'd do it ;-). Or do you think it will be an
> integral part of the LATERAL work?
Dunno. What I was a
On 05/08/2010 09:12 AM, Tom Lane wrote:
> Joe Conway writes:
>> I think this is an example of why we still need to implement a real
>> SFRM_ValuePerCall mode that allows results to be pipelined. Yes,
>> ValuePerCall sort of works from the targetlist, but it is pretty much
>> useless for the use ca
Joe Conway writes:
> I think this is an example of why we still need to implement a real
> SFRM_ValuePerCall mode that allows results to be pipelined. Yes,
> ValuePerCall sort of works from the targetlist, but it is pretty much
> useless for the use cases where people really want to use it.
> Or
On 05/07/2010 09:06 PM, Nikhil Sontakke wrote:
>>> Yeah this is my basic confusion. But wouldn't the arguments be
>>> evaluated afresh on the subsequent call for this SRF?
>>
>> No, see ExecMakeFunctionResult(). If we did that we'd have serious
>> problems with volatile functions, ie srf(random())
Nikhil Sontakke writes:
> Ok thanks. So if someone uses a really long-running srf with argument
> expression evaluations thrown in, then running into "out of memory"
> issues should be expected and then in those cases they are better off
> using multiple srf calls to get the same effect if they ca
hernan gonzalez writes:
> Sorry about a error in my previous example (mixed width and precision).
> But the conclusion is the same - it works on bytes:
This example works like that because it's running in C locale always.
Try something like this:
#include
#include
int main () {
char s[]
Hi!
We're having Lightning Talks again at PgCon - scheduled for 5:30pm on
May 20th in Ottawa!
Do you have a talk or idea you'd like to share? Lightning Talks are
one of the most highly attended sessions because they are fast, fun,
and useful (but not always). Slides are not required. If you use
On Sat, 2010-05-08 at 08:12 -0400, Robert Haas wrote:
> (3) mentoring the GSoC
> projects on matviews, json, and merge. Everything else is pretty
> amorphous at this point,
That's good you volunteered. I'm sorry to say that I'm really surprised
to hear anyone thinks MERGE or matviews are suitabl
On Sat, May 8, 2010 at 6:34 AM, Simon Riggs wrote:
> I've often faced the issue you describe. I think its difficult for
> everybody to help at this stage. In many ways it is a serialization and
> it's good that Tom holds the gate tighter than normal at this point.
>
> The main thing I've tried to
On Sat, May 8, 2010 at 12:04 AM, Marc G. Fournier wrote:
> IMHO, there is nothing wrong with you (or any other developer) spending time
> working on v9.1 features if said person feels that they have satisfied
> themselves that v9.0 is ready for release (ie. I think the best test anyone
> can run,
On Fri, 2010-05-07 at 18:26 -0400, Robert Haas wrote:
> On Fri, May 7, 2010 at 5:35 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> [ argues, in effect, for starting 9.1 development right now ]
> >
> > I can't stop you from spending your time as you please. My development
> > time for at least
On Thu, 2010-05-06 at 12:03 -0700, Josh Berkus wrote:
> So changing to a lock-based mechanism or designing a plugin interface
> are really not at all realistic at this date.
I agree that changing to a lock-based mechanism is too much at this
stage of development.
However, putting in a plugin is
On 8/05/2010 1:56 AM, Josh Berkus wrote:
I never meant to suggest any statement in that section is factually
wrong; it's just all too rosy, leading people to believe it's no big
deal to turn it off.
Yeah, that section is overdue for an update. I'll write some new text
and post it to pgsql-doc
36 matches
Mail list logo
