David Fetter wrote:
> On Thu, Jan 07, 2010 at 03:32:28PM -0500, Tom Lane wrote:
> > [ shrug... ] To me, HS+SR is actual replication, which would
> > justify tagging this release 9.0. With only one of them, it's 8.5.
> > I understand that there are power users who would find HS alone to
> > be tr
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
while I agree that HS is very useful without SR, I think that it's
mostly the well known powerusers inthe community are actively waiting
for HS and not so much for SR. For the typical user outside of -hackers
or even
On Thu, Jan 07, 2010 at 03:32:28PM -0500, Tom Lane wrote:
> Magnus Hagander writes:
> > On Thu, Jan 7, 2010 at 21:22, Tom Lane wrote:
> >> No, I don't think so. �HS without SR means you still have to fool
> >> with setting up WAL-file-based replication, which despite the
> >> existence of pg_stan
Tom Lane writes:
> No, I don't think so. HS without SR means you still have to fool with
> setting up WAL-file-based replication, which despite the existence of
> pg_standby is a PITA. And you have to make a tradeoff of how often to
> flush WAL files to the standby. To be a real candidate for "
Robert Haas writes:
> Hmm. There's something to what you say, but what about the people who
> were expecting their patches to be reviewed and perhaps committed in
> the forthcoming CommitFest. I proposed a schedule for this release
> that involved only three CommitFests and it was rejected, so i
Robert Haas writes:
> On Thu, Jan 7, 2010 at 3:36 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> I am tempted to say we should clamp down and go into damage control
>>> mode sooner rather than later.
>>
>> The more I see of the HS patch, the more I think the same. But my
>> proposal for "damag
On Thu, Jan 7, 2010 at 3:36 PM, Tom Lane wrote:
> Robert Haas writes:
>> I am tempted to say we should clamp down and go into damage control
>> mode sooner rather than later.
>
> The more I see of the HS patch, the more I think the same. But my
> proposal for "damage control mode" would be to im
Tom Lane wrote:
> Heikki Linnakangas writes:
>> But FWIW I have dedicated today and tomorrow for SR, and plan to
>> dedicate 2-3 days next week as well.
>
> So you carefully avoided answering the question: when do you think it
> might be committable?
:-). I was hoping to commit it by the end of
On Thu, 2010-01-07 at 15:49 -0500, Andrew Dunstan wrote:
> Right. As someone engaged in the marketplace, I can tell you that
> IMNSHO it is almost impossible to overstate the importance of getting
> both of these features. We will suffer an enormous loss of face and
> respect if we don't.
+1. T
Tom Lane wrote:
> Magnus Hagander writes:
> > On Thu, Jan 7, 2010 at 21:22, Tom Lane wrote:
> >> No, I don't think so. ?HS without SR means you still have to fool with
> >> setting up WAL-file-based replication, which despite the existence of
> >> pg_standby is a PITA. ?And you have to make a tra
On Thu, Jan 7, 2010 at 8:36 PM, Tom Lane wrote:
> Robert Haas writes:
>> I am tempted to say we should clamp down and go into damage control
>> mode sooner rather than later.
>
> The more I see of the HS patch, the more I think the same. But my
> proposal for "damage control mode" would be to im
On Thu, Jan 7, 2010 at 7:00 PM, Tom Lane wrote:
> Robert Haas writes:
>> That may well be so, but adding another one is not going to improve
>> the situation even a little bit. I don't think what you're saying
>> weakens in the slightest the argument that I was making, namely, that
>> if this is
Tom Lane wrote:
[ shrug... ] To me, HS+SR is actual replication, which would justify
tagging this release 9.0. With only one of them, it's 8.5. I
understand that there are power users who would find HS alone to be
tremendously useful, but in terms of what the average user sees, there's
a qu
Robert Haas writes:
> I am tempted to say we should clamp down and go into damage control
> mode sooner rather than later.
The more I see of the HS patch, the more I think the same. But my
proposal for "damage control mode" would be to immediately punt
everything else to the next release and foc
Heikki Linnakangas writes:
> Josh Berkus wrote:
>> Yes. I think there's tremendous value to PG if we could get HS+SR into
>> 8.5. And I know that SR is what Heikki is working on exclusively.
> That hasn't been true for some time, I haven't spent very much time on
> SR recently. Not enough, real
Magnus Hagander writes:
> On Thu, Jan 7, 2010 at 21:22, Tom Lane wrote:
>> No, I don't think so. HS without SR means you still have to fool with
>> setting up WAL-file-based replication, which despite the existence of
>> pg_standby is a PITA. And you have to make a tradeoff of how often to
>> f
On Thu, Jan 7, 2010 at 21:22, Tom Lane wrote:
> "Greg Sabino Mullane" writes:
>>> However, HS is already in the tree, and HS without SR is a whole lot
>>> less compelling than HS with SR. So it's going to be pretty
>>> unsatisfying if we can't get SR in there.
>
>> I don't think that's the case.
"Greg Sabino Mullane" writes:
>> However, HS is already in the tree, and HS without SR is a whole lot
>> less compelling than HS with SR. So it's going to be pretty
>> unsatisfying if we can't get SR in there.
> I don't think that's the case. Having HS alone would be a huge win,
> and the sooner
On Jan 7, 2010, at 12:10 PM, Heikki Linnakangas wrote:
> But FWIW I have dedicated today and tomorrow for SR, and plan to
> dedicate 2-3 days next week as well.
Should we then await what you determine over the next week?
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
Josh Berkus wrote:
> Yes. I think there's tremendous value to PG if we could get HS+SR into
> 8.5. And I know that SR is what Heikki is working on exclusively.
That hasn't been true for some time, I haven't spent very much time on
SR recently. Not enough, really.
But FWIW I have dedicated today
On Thu, Jan 7, 2010 at 1:53 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Robert Haas writes:
>> > I like Andres' suggestion upthread of setting a deadline and
>> > determining to bounce the patch if it's not committed by that date.
>> > If it turns out we have to bounce it, that stinks, but I do
> I am really reluctant to go through another cycle of giving a big
> feature as much time as humanly possible before bouncing it, and then
> bouncing it anyway, and I fear that is what will happen. I don't
> believe this patch has had a major rewrite since it was submitted for
> the September Co
On Thu, Jan 7, 2010 at 2:00 PM, Tom Lane wrote:
> Robert Haas writes:
>> That may well be so, but adding another one is not going to improve
>> the situation even a little bit. I don't think what you're saying
>> weakens in the slightest the argument that I was making, namely, that
>> if this is
> Well, the argument to my mind is about a suitable value of "RSN".
> I think you were stating that we should bounce SR if it's not committed
> before the final commitfest starts (ie, next week). I think we can give
> it more slack than that. Maybe the end of the fest (where the length of
> the
Robert Haas writes:
> That may well be so, but adding another one is not going to improve
> the situation even a little bit. I don't think what you're saying
> weakens in the slightest the argument that I was making, namely, that
> if this isn't committed RSN it should be postponed to 8.6. Do yo
Tom Lane wrote:
> Robert Haas writes:
> > I like Andres' suggestion upthread of setting a deadline and
> > determining to bounce the patch if it's not committed by that date.
> > If it turns out we have to bounce it, that stinks, but I don't think
> > it makes sense to go to beta with a huge, bare
On Thu, Jan 7, 2010 at 1:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> I like Andres' suggestion upthread of setting a deadline and
>> determining to bounce the patch if it's not committed by that date.
>> If it turns out we have to bounce it, that stinks, but I don't think
>> it makes sense to
Robert Haas writes:
> I like Andres' suggestion upthread of setting a deadline and
> determining to bounce the patch if it's not committed by that date.
> If it turns out we have to bounce it, that stinks, but I don't think
> it makes sense to go to beta with a huge, barely-tested pile of code
> i
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> while I agree that HS is very useful without SR, I think that it's
> mostly the well known powerusers inthe community are actively waiting
> for HS and not so much for SR. For the typical user outside of -hackers
> or even -general I'm not so
On Thu, Jan 7, 2010 at 12:24 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> We made the mistake last time to delay the release significantly for a
>> single feature. It turned out said feature didn't make it *anyway*.
>> Let's not repeat that mistake.
>
> Yeah, we've certainly learned that less
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
However, HS is already in the tree, and HS without SR is a whole lot
less compelling than HS with SR. So it's going to be pretty
unsatisfying if we can't get SR in there.
I don't think that's the case. Having HS a
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> However, HS is already in the tree, and HS without SR is a whole lot
> less compelling than HS with SR. So it's going to be pretty
> unsatisfying if we can't get SR in there.
I don't think that's the case. Having HS alone would be a huge win
Magnus Hagander writes:
> We made the mistake last time to delay the release significantly for a
> single feature. It turned out said feature didn't make it *anyway*.
> Let's not repeat that mistake.
Yeah, we've certainly learned that lesson often enough, or should I say
failed to learn that less
2010/1/7 Magnus Hagander :
> 2010/1/7 Devrim GÜNDÜZ :
>> On Thu, 2010-01-07 at 11:55 -0500, Robert Haas wrote:
>>
>>> Personally, I would rather have a release without SR in June or July
>>> than a release with SR in August or September.
>
> June, yes. July, frankly, no, because July == September,
On Thursday 07 January 2010 18:10:43 Magnus Hagander wrote:
> Not having our release schedule driven by marketing is a *strength* of
> our project!
Yes.
> We made the mistake last time to delay the release significantly for a
> single feature. It turned out said feature didn't make it *anyway*.
>
2010/1/7 Devrim GÜNDÜZ :
> On Thu, 2010-01-07 at 11:55 -0500, Robert Haas wrote:
>
>> Personally, I would rather have a release without SR in June or July
>> than a release with SR in August or September.
June, yes. July, frankly, no, because July == September, when it comes
to any such scheduling
On Thu, 2010-01-07 at 11:55 -0500, Robert Haas wrote:
> Personally, I would rather have a release without SR in June or July
> than a release with SR in August or September.
If SR will be ready until then, I'd like to see a release in September
which has SR in it. We already postponed SR a lot.
On Wed, Jan 6, 2010 at 3:03 AM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>>> I've done that in my git branch.
>>
>> Could you push that git branch to a public place?
>
> Ahh, sorry, forgot that again. It's there now, at
> git://git.postgresql.org/git/users/heikki/postgres.git, branch
> 'repl
Craig Ringer writes:
> Fujii Masao wrote:
>> On Tue, Jan 5, 2010 at 11:29 PM, Alvaro Herrera
>> wrote:
>>> This was probably discussed to death earlier, but: why was it decided to
>>> not simply use a different port for listening for walsender
>>> connections?
>>
>> I believe that using a differ
Fujii Masao wrote:
> On Tue, Jan 5, 2010 at 11:29 PM, Alvaro Herrera
> wrote:
>> This was probably discussed to death earlier, but: why was it decided to
>> not simply use a different port for listening for walsender
>> connections?
>
> I believe that using a different port would make the setup
>
Fujii Masao wrote:
>> I've done that in my git branch.
>
> Could you push that git branch to a public place?
Ahh, sorry, forgot that again. It's there now, at
git://git.postgresql.org/git/users/heikki/postgres.git, branch
'replication'.
--
Heikki Linnakangas
EnterpriseDB http://www.enterp
On Tue, Jan 5, 2010 at 11:29 PM, Alvaro Herrera
wrote:
> This was probably discussed to death earlier, but: why was it decided to
> not simply use a different port for listening for walsender
> connections?
I believe that using a different port would make the setup
of replication messier; look fo
On Tue, Jan 5, 2010 at 11:07 PM, Heikki Linnakangas
wrote:
> I think it would be better to utilize the existing array of child
> processes in pmsignal.c. Instead of having postmaster peek into
> WalSndCtlData, let's add a new state to PMChildFlags,
> PM_CHILD_WALSENDER, which is just like PM_CHILD
Heikki Linnakangas escribió:
> Looking at the latest streaming replication patch, I don't much like the
> signaling between WAL sender and postmaster. It seems complicated, and
> as a rule of thumb postmaster shouldn't be accessing shared memory. The
> current signaling is:
>
> 1. A new connection
Looking at the latest streaming replication patch, I don't much like the
signaling between WAL sender and postmaster. It seems complicated, and
as a rule of thumb postmaster shouldn't be accessing shared memory. The
current signaling is:
1. A new connection arrives. A new backend process is forked
45 matches
Mail list logo
