Prev: Hot Standby and handling max_standby_delay
Next: Archive recovery crashes on win32 in HEAD - hot standby related?
From: Tom Lane on 15 Jan 2010 19:40
"Joshua D. Drake" <jd(a)commandprompt.com> writes:
> O.k. I know there is no way we will hit this for 8.5. So this is more of
> a future discussion more than anything.

Well, this is not really the time to be having such a discussion; right
now we need to all have our noses to the grindstone dealing with the
already-submitted 8.5 features. The start of the next devel cycle would
be a more appropriate time to think about it.

(Personally, I suspect we're going to have our hands full dealing with
HS+SR for quite some time to come, which implies we should not scatter
our energies across multiple replication solutions. But that will be
clearer in a few months when we see what emerges from beta.)

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Takahiro Itagaki on 18 Jan 2010 04:13

"Joshua D. Drake" <jd(a)commandprompt.com> wrote:

> My question is, do we have any interest in working on getting this into
> core?

We had a discussion how replication projects work together with the core
in the developer meeting on PGCon 2009 Japan.
http://wiki.postgresql.org/wiki/PGCon2009JapanClusterDeveloperMeeting

The conclusion is splitting existing projects into some 'modules',
and getting the modules one by one into core. Voted features are here:
http://wiki.postgresql.org/wiki/ClusterFeatures

Mammoth Replicator seems to modify the core heavily, no? I hope you
would split the mammoth patch into several independent features,
and submit them separately. It is much better if some of them can
be shared by other replication projects.

Regards,
---
Takahiro Itagaki
NTT Open Source Software Center



--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Greg Smith on 19 Jan 2010 12:28
Takahiro Itagaki wrote:
> The conclusion is splitting existing projects into some 'modules',
> and getting the modules one by one into core. Voted features are here:
> http://wiki.postgresql.org/wiki/ClusterFeatures
>
This page was a bit messy for someone who didn't attend the meeting to
follow. I just cleaned it up so that the features are listed in voting
order, and to have more inter-page links. It's better, but could use
some more work still.

There are a few things I noted that I didn't see in the voting order; I
moved those all into another section. If anyone who was there can help
prioritize those it would be helpful. Also, the voting included "XID
set", but I didn't see any section that clearly matched that, so there
may be a missing description section there too.

Stepping back for a second, there are three big picture things that I
think need to be sorted out before it's possible for this to be useful
guidance for something like suggesting how JD might best fit his Mammoth
work into the broad work being done in this area, which I consider a
subset of the larger important question "how can people help here?":

-There are dependencies that exist regardless of what order people would
like to see the features at. For example, the one I thought I saw
listed and therefore documented is that the "Modification trigger into
core" feature presumes you've already resolved "Generalized Data
Queue". Are there more of those? Does "Function scan push-down" depend
on "Export snapshots" already being done? Those are the kind of
questions I'm left with when reading.

-Who if anyone is actually working in this area already with prototypes
or at all? In some cases these are listed (like notes referencing
Slony/Londiste etc.); it would be helpful to explicitly nail those down
in every case. For the Mammoth example, that might help identify which
components they have a uniquely useful piece for.

-Is there anyone who's taken on responsibility for working on any of
these specific parts yet? When we had a similar work prioritization
session at the PGCon developer's meeting, most of the action items there
came with a clearly labeled person on the hook who was working on them.
I don't see any notion like that from this meeting's outcome.

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(a)2ndQuadrant.com www.2ndQuadrant.com


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Markus Wanner on 19 Jan 2010 15:55
Hi,

Greg Smith wrote:
> Takahiro Itagaki wrote:
>> The conclusion is splitting existing projects into some 'modules',
>> and getting the modules one by one into core. Voted features are here:
>> http://wiki.postgresql.org/wiki/ClusterFeatures

That's certainly been one of the outcomes, however, there was a lot more
to it that just that. You find a bit more covered on
http://wiki.postgresql.org/wiki/PGCon2009JapanClusterDeveloperMeeting
(and some of its links), but I understand it's hard to follow.

It's unfortunate that none of the Mammoth developers have been around.
It would have been interesting hearing their POV as well.

> There are a few things I noted that I didn't see in the voting order; I
> moved those all into another section. If anyone who was there can help
> prioritize those it would be helpful. Also, the voting included "XID
> set", but I didn't see any section that clearly matched that, so there
> may be a missing description section there too.

I don't remember, sorry.

Note that this is just a wish-list of things that the clustering hackers
possibly want in core. There are lots of little, but important details
that still need to be fleshed out for every single item.

> Stepping back for a second, there are three big picture things that I
> think need to be sorted out before it's possible for this to be useful
> guidance for something like suggesting how JD might best fit his Mammoth
> work into the broad work being done in this area, which I consider a
> subset of the larger important question "how can people help here?"

Well, that's not exactly the kind of question JD posed. He offered to
help with making Mammoth "community ready" - whatever that is. (And I
bet not even "the community" knows. You certainly won't get a single
answer).

However, I'm in a somewhat similar situation with Postgres-R. And since
the clustering meeting, I'm even more convinced that I need to break it
apart and split into single modules, which might be of use for others. I
didn't have no luck with the imessages patch, so far. But Kevin seems to
be interested in the testing framework I'm putting together [1] - and
he's not even using it for a clustering project. (And another module
that's core code is in the queue, so stay tuned).

So, that's what I'd recommend the Mammoth developers to do as well:
cherry-picking, sort of. Maybe that fulfills one or the other item on
our wish-list (in one way or another)...

Regards

Markus Wanner

[1]: dtester
http://www.bluegap.ch/projects/dtester


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: "Joshua D. Drake" on 19 Jan 2010 17:34
On Tue, 2010-01-19 at 21:55 +0100, Markus Wanner wrote:
> Hi,

> So, that's what I'd recommend the Mammoth developers to do as well:
> cherry-picking, sort of. Maybe that fulfills one or the other item on
> our wish-list (in one way or another)...
>

I doubt we are going to spend the time to do that. Mammoth is BSD and
open source. If people want to jump in and help, that would be
interesting, but on our own... it isn't on our priority list.

Our priority list with mammoth is simple.

Finish 1.9

Fix things we know the community as hackers (not feature set) will grump
about.

Make it work on 8.4 ad 8.5

But again, as Tom says... none of this is relevant until 8.5 is released
at which point, we can talk about all of this again. Hopefully 1.9 will
be done by then.

Done.

Joshua D. Drake



--


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 |  Next  |  Last
Pages: 1 2 3
Prev: Hot Standby and handling max_standby_delay
Next: Archive recovery crashes on win32 in HEAD - hot standby related?