On 02/27/2010 11:20 PM, Craig Ringer wrote:
Essentially, you have:
1) People preparing statements to save on parse+plan time; and
2) People preparing statements to get convenenient param placement.
I suspect that most of (1) also want (2), but many of (2) don't care
much about (1) and are just
Hi Alvaro.
Ooops, surprised at news now:-(
I'm wishing you and your familys is no trouble.
However, I look at one relief because your mail has arrived. !
- Original Message -
From: "Marc G. Fournier"
On Sat, 27 Feb 2010, Alvaro Herrera wrote:
Hi. We're out of town right now
At Saturday, 02/27/2010 on 4:21 pm "Marc G. Fournier" wrote:
> On Sat, Feb 27, 2010 at 10:45 PM, Alvaro Herrera
> wrote:
>>
>> Is there a higher then normal amount of earthquakes happening recently?
>> haiti, japan just had one for 6.9, there was apparently one in illinos a
>> few weeks back, on
Greg Stark wrote:
On Sun, Feb 28, 2010 at 5:28 AM, Greg Smith wrote:
The idea of the workaround is that if you have a single long-running query
to execute, and you want to make sure it doesn't get canceled because of a
vacuum cleanup, you just have it connect back to the master to keep an op
Robert Haas wrote:
It seems to me that if we're forced to pass the xmin from the
slave back to the master, that would be a huge step backward in terms
of both scalability and performance, so I really hope it doesn't come
to that.
Not forced to--have the option of. There are obviously workloads
Robert Haas wrote:
This might be my fault, so I apologize for killing your enthusiasm. I
think when I get wrapped up in a CommitFest (and especially during the
second half) I get wound up in determining whether or not things are
going to get applied and tend to give short shrift to thinks that
If i have got over excited in the previous update, please ignore that.
a) We are already going from table to index to do unique checks. This is the
same thing, which we will do to go and update the snapshot in the indexes.
b) The way, it should work would be to have a check on whether the operator
On Sun, Feb 28, 2010 at 5:28 AM, Greg Smith wrote:
> The idea of the workaround is that if you have a single long-running query
> to execute, and you want to make sure it doesn't get canceled because of a
> vacuum cleanup, you just have it connect back to the master to keep an open
> snapshot the
Bruce Momjian wrote:
"The first option is to connect to the primary server and keep a query
active for as long as needed to run queries on the standby. This
guarantees that a WAL cleanup record is never generated and query
conflicts do not occur, as described above. This could be done using
co
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> > Hiroshi Inoue wrote:
> >> Bruce Momjian wrote:
> >>> Where are we on this issue?
> >> Oops I forgot it completely.
> >> I have a little improved version and would post it tonight.
> >
> > Ah, very good. Thanks.
>
> Attached is an improved version.
Robert Haas writes:
> On Fri, Feb 26, 2010 at 7:03 PM, Tom Lane wrote:
>> Wouldn't it be better if it just did the right thing automatically?
>>
>> The sort of heuristic I'm envisioning would essentially do "replan every
>> time" for some number of executions, and give up only if it noticed that
On 26/02/2010 11:40 AM, Tom Lane wrote:
But putting support for a per-query level
of control into the protocol (and then every client library) as well as
every PL is going to be painful to implement, and even more painful to
use.
You mean something like 'EXECUTE REPLAN' and protocol/PL-level e
On Sat, 27 Feb 2010, Alvaro Herrera wrote:
Hi. We're out of town right now, and it seems I can't get to my home
machine (probably just a loose cable). Our building was shaken badly
enough that we'll have a lot of work to do to make it usable again.
Our earthquake was 8.3 or 8.8 depending on w
Hi. We're out of town right now, and it seems I can't get to my home
machine (probably just a loose cable). Our building was shaken badly
enough that we'll have a lot of work to do to make it usable again.
Our earthquake was 8.3 or 8.8 depending on who you ask, and whatever
it really was, it was
Greg Smith wrote:
> Josh Berkus wrote:
>
> > Now that I think about it, the xmin thing really doesn't seem
> > conceptually difficult. If the slave just opens a 2nd, special query
> > connection back to the master and publishes its oldest xmin there, as
> > far as the master is concerned, it's ju
On Sat, Feb 27, 2010 at 6:22 PM, Mark Kirkwood
wrote:
> Greg Smith wrote:
>> While I was in there I also added some more notes on my personal top patch
>> submission peeve, patches whose purpose in life is to improve performance
>> that don't come with associated easy to run test cases, including
On Feb 27, 2010, at 20:33 , Robert Haas wrote:
On Sat, Feb 27, 2010 at 7:21 PM, Marc G. Fournier
wrote:
Is there a higher then normal amount of earthquakes happening
recently?
haiti, japan just had one for 6.9, there was apparently one in
illinos a few
weeks back, one on the Russia/China
On Sat, Feb 27, 2010 at 5:40 AM, Mark Kirkwood
wrote:
> I'd also like to take the opportunity to express a little frustration about
> the commitfest business - really all I wanted was the patch *reviewed* as
> WIP - it seemed that in order to do that I needed to enter it into the
> various commitf
On Sat, Feb 27, 2010 at 7:21 PM, Marc G. Fournier wrote:
> Is there a higher then normal amount of earthquakes happening recently?
> haiti, japan just had one for 6.9, there was apparently one in illinos a few
> weeks back, one on the Russia/China/N.Korean border and now Chile?
>
> Hrmmm ...
Shou
On Fri, Feb 26, 2010 at 3:28 PM, Yeb Havinga wrote:
> I'm wondering if there would be community support for adding using the
> execute message with a rownum > 0 in the c libpq client library, as it is
> used by the jdbc driver with setFetchSize.
Not sure I follow what you're asking... what would
On Fri, Feb 26, 2010 at 10:07 PM, Bruce Momjian wrote:
> Did this ever get applied/resolved?
No, I never went back and tried to fix the brokenness Tom found.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgre
On Fri, Feb 26, 2010 at 7:03 PM, Tom Lane wrote:
> Robert Haas writes:
>> Basically, what I really want here is some kind of keyword or other
>> syntax that I can stick into a PL/pgsql query that requests a replan
>> on every execution.
>
> Wouldn't it be better if it just did the right thing aut
On Fri, Feb 26, 2010 at 1:53 PM, Tom Lane wrote:
> Greg Stark writes:
>> In the model you describe any long-lived queries on the slave cause
>> tables in the master to bloat with dead records.
>
> Yup, same as they would do on the master.
>
>> I think this model is on the roadmap but it's not app
Is there a higher then normal amount of earthquakes happening recently?
haiti, japan just had one for 6.9, there was apparently one in illinos a
few weeks back, one on the Russia/China/N.Korean border and now Chile?
Hrmmm ...
On Sat, 27 Feb 2010, Bruce Momjian wrote:
Josh Berkus wrote:
Th
Mark Kirkwood wrote:
While I completely agree that the submitter should be required to
supply a test case and their results, so the rest of us can try to
reproduce said improvement - rejecting the patch out of hand is a bit
harsh I feel - Hey, they may just have forgotten to supply these things
Josh Berkus wrote:
Hey, take it easy! I read Stark's post as tongue-in-cheek, which I
think it was.
Yeah, I didn't get that. We've already exchanged mutual off-list
apologies for the misunderstanding in both directions, I stopped just
short of sending flowers.
I did kick off this discu
Greg Smith wrote:
While I was in there I also added some more notes on my personal top
patch submission peeve, patches whose purpose in life is to improve
performance that don't come with associated easy to run test cases,
including a sample of that test running on a system that shows the
s
> Thank you for combining a small personal attack with a selfish
> commentary about how yours is the only valid viewpoint. Saves me a lot
> of trouble replying to your messages, can just ignore them instead if
> this is how you're going to act.
Hey, take it easy! I read Stark's post as tongue-i
> The part I still don't have good visibility on is how much of the
> necessary SR infrastructure needed to support this communications
> channel is already available in some form. I had though the walsender
> on the master was already receiving messages sometimes from the
> walreceiver on the st
Mark Kirkwood wrote:
I don't mean to be ungrateful about the actual reviews at all - and I
did value the feedback received (which I hope was reasonably clear in
the various replies I sent). I sense a bit of attacking the messenger
in your tone...
I thought there was a moderately big differenc
Josh Berkus wrote:
Now that I think about it, the xmin thing really doesn't seem
conceptually difficult. If the slave just opens a 2nd, special query
connection back to the master and publishes its oldest xmin there, as
far as the master is concerned, it's just another query backend.
Could it b
On Fri, Feb 26, 2010 at 11:14:01AM -0500, Tom Lane wrote:
> I think it would be a good idea, just to have all that code using
> identical #includes. R�mi's problem may be a platform bug rather
Sounds reasonable, done.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot
On 2/27/10 1:04 PM, Mark Kirkwood wrote:
>>
>
> LOL - I said a bit - it was only a little, connected with the commit vs
> review confusion. I think I just got caught in the bedding in time for
> the new development processes, I was advised to add it to the
> commitfests, and them advised that it s
On Fri, Feb 26, 2010 at 10:23:19PM -0500, Bruce Momjian wrote:
> Was this fixed?
No, need to get along to fixing it.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ 179140304,
Greg Smith wrote:
Mark Kirkwood wrote:
Greg Smith wrote:
Returned with feedback in October after receiving a lot of review,
no updated version submitted since then:
https://commitfest.postgresql.org/action/patch_view?id=98
Hmm - I would say a bit of review rather than a lot :-)
It looks
=?iso-8859-1?Q?R=E9mi_Zara?= writes:
> Le 27 févr. 2010 à 17:57, Tom Lane a écrit :
>> I don't think it's our bug to fix.
> It would mean retiring pika until/if the bug is fixed... :-(
Grumble ... well, I suppose we've put in worse platform-specific hacks
elsewhere. At least this is pretty loca
Greg,
> If you think of it in those terms, the idea that "you need to run PITR
> backup/archive recovery" to not get that behavior isn't an important
> distinction anymore. If you run SR with the option enabled you could
> get it, any other setup and you won't.
+1.
I always expected that we'd g
Josh Berkus wrote:
> There was a huge earthquake in Chile this morning ... Alvaro, you OK?
Yes, I talked to Alvaro via IM about 2 hours ago. He was already
online. His apartment building was shaken up but undamaged and his
family is fine too.
--
Bruce Momjian http://momjian.us
Ent
There was a huge earthquake in Chile this morning ... Alvaro, you OK?
--Josh Berkus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Gokulakannan Somasundaram wrote:
Statspack works by the following way -a) it takes a copy of important
catalog tables(pg_ tables) which store the information like wait
statistics against wait events, i/o statistics cumulative against each
SQL_Hash( and SQL_Text), whether a particular plan went
Mark Kirkwood wrote:
Greg Smith wrote:
Returned with feedback in October after receiving a lot of review, no
updated version submitted since then:
https://commitfest.postgresql.org/action/patch_view?id=98
Hmm - I would say a bit of review rather than a lot :-)
It looks like you got useful
Le 27 févr. 2010 à 17:57, Tom Lane a écrit :
> =?iso-8859-1?Q?R=E9mi_Zara?= writes:
>> Le 26 févr. 2010 à 17:11, Tom Lane a écrit :
>>> Hmm. So what do you get from
>>> SELECT 'nan'::numeric::float8;
>
>> regression=# select 'nan'::numeric::float8;
>> float8
>> --
>> Infinity
>> (1
=?iso-8859-1?Q?R=E9mi_Zara?= writes:
> Le 26 févr. 2010 à 17:11, Tom Lane a écrit :
>> Hmm. So what do you get from
>> SELECT 'nan'::numeric::float8;
> regression=# select 'nan'::numeric::float8;
> float8
> --
> Infinity
> (1 row)
> So it is indeed the same behavior.
Yeah. So wha
Mark Kirkwood writes:
> I'd also like to take the opportunity to express a little frustration
> about the commitfest business - really all I wanted was the patch
> *reviewed* as WIP - it seemed that in order to do that I needed to enter
> it into the various commitfests... then I was faced with
> I think that what we are going to have to do before we can ship 9.0
> is rip all of that stuff out and replace it with the sort of closed-loop
> synchronization Greg Smith is pushing. It will probably be several
> months before everyone is forced to accept that, which is why 9.0 is
> not going t
yeah, we have a couple of patches that aren't good... And I kind of
lost track of it waiting for feedback on my last question.
It's not a must-fix, but it'd be good to get better messages eventually.
//Magnus
2010/2/26 Bruce Momjian :
>
> I assume we never came to any conclusion on this.
>
> ---
Fujii Masao wrote:
> On Tue, Dec 22, 2009 at 11:25 AM, Fujii Masao wrote:
> > I found there is no "primary" tag for the HS parameters
> > in config.sgml. Attached patch adds that tag.
>
> I found another small problem in HS doc; though the type of
> trace_recovery_messages is actually enum, it's
Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > Pavan Deolasee wrote:
> >> On Fri, Feb 26, 2010 at 8:19 AM, Bruce Momjian wrote:
> >>
> >>> Whatever happened to this? It was in the first 9.0 commitfest but was
> >>> returned with feedback but never updated:
> >>>
> >>>
> >> Though Alex did s
Greg Smith wrote:
> Joshua D. Drake wrote:
> > On Sat, 27 Feb 2010 00:43:48 +, Greg Stark wrote:
> >
> >> I want my ability to run large batch queries without any performance
> >> or reliability impact on the primary server.
> >>
> >
> > +1
> >
> > I can use any number of other technol
2010/2/27 Tom Lane :
> Buildfarm member caracara has been failing the last few days because of
> this:
>
> LOG: could not bind socket for statistics collector: Cannot assign requested
> address
> LOG: disabling statistics collector for lack of working socket
>
> That code hasn't changed recently
Le 26 févr. 2010 à 17:11, Tom Lane a écrit :
> =?iso-8859-1?Q?R=E9mi_Zara?= writes:
>> I've tried patch 1 and 2, but they do not work. The fact is that the code is
>> not used in the backend, because strtod("NaN", endptr) works.
>> (isnan(strtod("NaN", endptr)) is true).
>
> Hmm. So what do
Greg Smith wrote:
Bruce Momjian wrote:
What happened to this patch?
Returned with feedback in October after receiving a lot of review, no
updated version submitted since then:
https://commitfest.postgresql.org/action/patch_view?id=98
Hmm - I would say a bit of review rather than a lot
Heikki Linnakangas wrote:
> Dimitri Fontaine wrote:
>> Bruce Momjian writes:
>>> Doesn't the system already adjust the delay based on the length of slave
>>> transactions, e.g. max_standby_delay. It seems there is no need for a
>>> user switch --- just max_standby_delay really high.
>> Well that
Dimitri Fontaine wrote:
> Bruce Momjian writes:
>> Doesn't the system already adjust the delay based on the length of slave
>> transactions, e.g. max_standby_delay. It seems there is no need for a
>> user switch --- just max_standby_delay really high.
>
> Well that GUC looks like it allows to se
Bruce Momjian wrote:
> Pavan Deolasee wrote:
>> On Fri, Feb 26, 2010 at 8:19 AM, Bruce Momjian wrote:
>>
>>> Whatever happened to this? It was in the first 9.0 commitfest but was
>>> returned with feedback but never updated:
>>>
>>>
>> Though Alex did some useful tests and review, and in fact con
55 matches
Mail list logo
