Joshua D. Drake wrote:
On Thu, 2008-05-29 at 17:42 -0400, Robert Treat wrote:
I would have thought the read only piece would have been more important than
the synchronous piece. In my experience readable slaves is the big selling
point in both Oracle and MySQL's implementations, and
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Yeah. The main problem is that unless you do WAL based replication,
you cannot achieve transparency. So you need to pick few use cases
and tailor you solution for them, which gets uninteresting very fast
- user _will_ stumble upon spacial
On Thu, 2008-05-29 at 18:39 -0400, Andrew Dunstan wrote:
Joshua D. Drake wrote:
On Thu, 2008-05-29 at 17:42 -0400, Robert Treat wrote:
You must be gauging a different market from the one I'm in. I have just
come back from a meeting with a (quite technically savvy) customer who
One
Joshua D. Drake [EMAIL PROTECTED] writes:
One customer does not make a hundred. I am not saying that the shipping
isn't valid, just that those that I talk to are more interested in the
read only slave. Consider that we have any number of ways to solve the
problem we are considering
This is a proposal of a non-standard, albeit useful functionality in
Postgres (it is also a quite long email message).
Background:
I'm currently working on a GSoC project for PostgreSQL
(http://wiki.postgresql.org/wiki/Gsoc08-tss). But at the same time, I'm
now at the point where I need to
On Thu, 2008-05-29 at 19:02 -0400, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
One customer does not make a hundred. I am not saying that the shipping
isn't valid, just that those that I talk to are more interested in the
read only slave. Consider that we have any number of
Jorgen Austvik - Sun Norway [EMAIL PROTECTED] writes:
Tom Lane wrote:
The RPM packages have done this since approximately forever. You might
want to look at the patches used there.
yes [1] is the same that we have been using internally.
Let me reformulate my question: would it be better to
[EMAIL PROTECTED] (Tom Lane) writes:
As I said originally, we have no expectation that the proposed features
will displace the existing replication projects for high end
replication problems ... and I'd characterize all of Robert's concerns
as high end problems. We are happy to let those be
Joshua D. Drake [EMAIL PROTECTED] writes:
I think maybe my actual argument isn't coming through. What I am arguing
for is not shipping XY without Z. That is all. (and no, I don't think we
should hold up 8.4).
So we should keep all the work out of the tree until every part is done?
No thanks;
Is there a reason that we can't add a trigger to a table while a
select is running? This is a serious pain when trying to setup
londiste or slony.
--
Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
On Thu, May 29, 2008 at 7:12 PM, Joshua D. Drake [EMAIL PROTECTED] wrote:
On Thu, 2008-05-29 at 19:02 -0400, Tom Lane wrote:
I think we have nontrivial
work in front of us to build a simple, reliable, community-tested
log shipping solution; and it's not very sexy work either. But it
needs
On Thu, 29 May 2008, Tom Lane wrote:
There's no point in having read-only slave queries if you don't have a
trustworthy method of getting the data to them.
This is a key statement that highlights the difference in how you're
thinking about this compared to some other people here. As far as
* Tom Lane [EMAIL PROTECTED] [080529 20:22]:
Joshua D. Drake [EMAIL PROTECTED] writes:
I think maybe my actual argument isn't coming through. What I am arguing
for is not shipping XY without Z. That is all. (and no, I don't think we
should hold up 8.4).
So we should keep all the work out
Tom Lane wrote:
There's no point in having read-only slave queries if you don't have a
trustworthy method of getting the data to them.
O.k. I was with you until here. Log shipping ala pg_standby works fine
now sans read-only slave. No, it isn't out of the box which I can see an
argument for
Greg,
I fully accept that it may be the case that it doesn't make technical
sense to tackle them in any order besides sync-read-only slaves because
of dependencies in the implementation between the two. If that's the
case, it would be nice to explicitly spell out what that was to deflect
Greg Sabino Mullane wrote:
there another way around this problem that can be somewhat
automated?
I don't think so. This is a particular case. So my advice is to hack
test_config_settings() and add your custom values to trial_conns[] and
trial_bufs[].
--
Euler Taveira de Oliveira
On Thu, May 29, 2008 at 07:02:56PM -0400, Tom Lane wrote:
People want the bits to go from point A to point B; they don't want
to have to research, design, test, and administer their own solution
for moving the bits.
I agree with this. I think I probably know as well as most people --
On Thu, May 29, 2008 at 9:26 PM, Josh Berkus [EMAIL PROTECTED] wrote:
I fully accept that it may be the case that it doesn't make technical
sense to tackle them in any order besides sync-read-only slaves because
of dependencies in the implementation between the two. If that's the
case, it
Josh Berkus wrote:
Greg,
I fully accept that it may be the case that it doesn't make technical
sense to tackle them in any order besides sync-read-only slaves because
of dependencies in the implementation between the two. If that's the
case, it would be nice to explicitly spell out what
Greg Smith [EMAIL PROTECTED] writes:
I fully accept that it may be the case that it doesn't make technical
sense to tackle them in any order besides sync-read-only slaves because
of dependencies in the implementation between the two.
Well, it's certainly not been my intention to suggest that
101 - 120 of 120 matches
Mail list logo
