2012-06-19 09:24 keltezéssel, Andres Freund írta:
On Tuesday, June 19, 2012 04:12:47 AM Steve Singer wrote:
On 12-06-18 07:30 AM, Andres Freund wrote:
Hrmpf #666. I will go through through the series commit-by-commit again
to make sure everything compiles again. Reordinging this late
On Friday, June 29, 2012 02:43:49 PM Boszormenyi Zoltan wrote:
2012-06-19 09:24 keltezéssel, Andres Freund írta:
On Tuesday, June 19, 2012 04:12:47 AM Steve Singer wrote:
On 12-06-18 07:30 AM, Andres Freund wrote:
Hrmpf #666. I will go through through the series commit-by-commit again
to
On 20 June 2012 11:26, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Simon Riggs si...@2ndquadrant.com wrote:
The proposal is to use WAL to generate the logical change stream.
That has been shown in testing to be around x4 faster than having
a separate
On 20.06.2012 01:27, Kevin Grittner wrote:
Andres Freundand...@2ndquadrant.com wrote:
Yes, thats definitely a valid use-case. But that doesn't preclude
the other - also not uncommon - use-case where you want to have
different master which all contain up2date data.
I agree. I was just
On 20 June 2012 08:35, Robert Haas robertmh...@gmail.com wrote:
I expect it would be fine to have a tool that pulls LCRs out of WAL to
prepare that to be sent to remote locations. Is that what you have in
mind?
Yes. I think it should be possible to generate LCRs from WAL, but I
think that
On 20 June 2012 14:40, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The reason we need an origin id in this scenario is that otherwise this will
happen:
1. A row is updated on node A
2. Node B receives the WAL record from A, and updates the corresponding row
in B. This
On 20.06.2012 10:32, Simon Riggs wrote:
On 20 June 2012 14:40, Heikki Linnakangas
And I'm worried
it might not even be enough in more complicated scenarios.
It is not the only required conflict mechanism, and has never been
claimed to be so. It is simply one piece of information needed, at
On 20 June 2012 15:45, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20.06.2012 10:32, Simon Riggs wrote:
On 20 June 2012 14:40, Heikki Linnakangas
And I'm worried
it might not even be enough in more complicated scenarios.
It is not the only required conflict
On 20.06.2012 11:17, Simon Riggs wrote:
On 20 June 2012 15:45, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20.06.2012 10:32, Simon Riggs wrote:
On 20 June 2012 14:40, Heikki Linnakangas
And I'm worried
it might not even be enough in more complicated scenarios.
It is
On 20 June 2012 16:23, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
It's only needed for multi-master replication, where the same table can be
updated from multiple nodes. Just leave that out for now. There's plenty of
functionality and issues left even without that.
Huh?
On 20.06.2012 11:34, Simon Riggs wrote:
On 20 June 2012 16:23, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
It's only needed for multi-master replication, where the same table can be
updated from multiple nodes. Just leave that out for now. There's plenty of
functionality and
On Wednesday, June 20, 2012 02:35:59 AM Robert Haas wrote:
On Tue, Jun 19, 2012 at 5:59 PM, Christopher Browne cbbro...@gmail.com
wrote:
On Tue, Jun 19, 2012 at 5:46 PM, Robert Haas robertmh...@gmail.com
wrote:
Btw, what do you mean with conflating the stream? I don't really see
that
On 20 June 2012 16:44, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20.06.2012 11:34, Simon Riggs wrote:
On 20 June 2012 16:23, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
It's only needed for multi-master replication, where the same table can
be
Heikki Linnakangas wrote:
I don't like the idea of adding the origin id to the record header.
It's only required in some occasions, and on some record types.
Right.
And I'm worried it might not even be enough in more complicated
scenarios.
Perhaps we need a more generic WAL record
On Wed, Jun 20, 2012 at 5:15 AM, Andres Freund and...@2ndquadrant.com wrote:
As I said before, I definitely agree that we want to have a separate transport
format once we have decoding nailed down. We still need to ship wal around if
the decoding happens in a different instance, but *after*
On Wed, Jun 20, 2012 at 5:47 AM, Simon Riggs si...@2ndquadrant.com wrote:
The idea that logical rep is some kind of useful end goal in itself is
slightly misleading. If the thought is to block multi-master
completely on that basis, that would be a shame. Logical rep is the
mechanism for
On Wednesday, June 20, 2012 03:19:55 PM Robert Haas wrote:
On Wed, Jun 20, 2012 at 5:47 AM, Simon Riggs si...@2ndquadrant.com wrote:
The idea that logical rep is some kind of useful end goal in itself is
slightly misleading. If the thought is to block multi-master
completely on that basis,
On 20 June 2012 21:19, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 20, 2012 at 5:47 AM, Simon Riggs si...@2ndquadrant.com wrote:
The idea that logical rep is some kind of useful end goal in itself is
slightly misleading. If the thought is to block multi-master
completely on that
On Wed, Jun 20, 2012 at 9:25 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 20 June 2012 21:19, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 20, 2012 at 5:47 AM, Simon Riggs si...@2ndquadrant.com wrote:
The idea that logical rep is some kind of useful end goal in itself is
slightly
On Wednesday, June 20, 2012 03:02:28 PM Robert Haas wrote:
On Wed, Jun 20, 2012 at 5:15 AM, Andres Freund and...@2ndquadrant.com
wrote:
One bit is fine if you have only very simple replication topologies. Once
you think about globally distributed databases its a bit different. You
describe
On 20 June 2012 20:37, Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Heikki Linnakangas wrote:
I don't like the idea of adding the origin id to the record header.
It's only required in some occasions, and on some record types.
Right.
Wrong, as explained.
And I'm worried it might not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/19/2012 01:47 AM, Christopher Browne wrote:
That numbering scheme gets pretty anti-intuitive fairly quickly,
from whence we took the approach of having a couple digits
indicating data centre followed by a digit indicating which node in
that
On Wed, Jun 20, 2012 at 9:43 AM, Andres Freund and...@2ndquadrant.com wrote:
If you do that, then, yes,
everything that you need to disentangle various network topologies
must be present in WAL. But what I'm saying is: don't do it like
that. Generate the LCRs just ONCE, at the origin node,
On Wednesday, June 20, 2012 03:42:39 PM Robert Haas wrote:
On Wed, Jun 20, 2012 at 9:25 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 20 June 2012 21:19, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 20, 2012 at 5:47 AM, Simon Riggs si...@2ndquadrant.com
wrote:
The idea that
On Wednesday, June 20, 2012 03:54:43 PM Robert Haas wrote:
On Wed, Jun 20, 2012 at 9:43 AM, Andres Freund and...@2ndquadrant.com
wrote:
If you do that, then, yes,
everything that you need to disentangle various network topologies
must be present in WAL. But what I'm saying is: don't do it
On 20 June 2012 21:42, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 20, 2012 at 9:25 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 20 June 2012 21:19, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 20, 2012 at 5:47 AM, Simon Riggs si...@2ndquadrant.com wrote:
The idea that
On 20 June 2012 16:23, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20.06.2012 11:17, Simon Riggs wrote:
On 20 June 2012 15:45, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20.06.2012 10:32, Simon Riggs wrote:
On 20 June 2012 14:40, Heikki
Simon Riggs si...@2ndquadrant.com wrote:
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Heikki Linnakangas wrote:
I don't like the idea of adding the origin id to the record
header. It's only required in some occasions, and on some record
types.
Right.
Wrong, as explained.
The
On Wed, Jun 20, 2012 at 10:02 AM, Andres Freund and...@2ndquadrant.com wrote:
Were not the only ones here that are performing scope creep though... I think
about all people who have posted in the whole thread except maybe Tom and
Marko are guilty of doing so.
I still think its rather sensible
On Wednesday, June 20, 2012 05:34:42 PM Kevin Grittner wrote:
Simon Riggs si...@2ndquadrant.com wrote:
This is not transaction metadata, it is WAL record metadata
required for multi-master replication, see later point.
We need to add information to every WAL record that is used as the
On Wed, Jun 20, 2012 at 10:08 AM, Simon Riggs si...@2ndquadrant.com wrote:
But I think getting even
single-master logical replication working well in a single release
cycle is going to be a job and a half.
OK, so your estimate is 1.5 people to do that. And if we have more
people, should they
Hi,
On Wednesday, June 20, 2012 05:44:09 PM Robert Haas wrote:
On Wed, Jun 20, 2012 at 10:02 AM, Andres Freund and...@2ndquadrant.com
wrote:
Were not the only ones here that are performing scope creep though... I
think about all people who have posted in the whole thread except maybe
Tom
On 20 June 2012 23:34, Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Simon Riggs si...@2ndquadrant.com wrote:
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Heikki Linnakangas wrote:
I don't like the idea of adding the origin id to the record
header. It's only required in some
On Wed, Jun 20, 2012 at 11:50 AM, Andres Freund and...@2ndquadrant.com wrote:
On Wednesday, June 20, 2012 05:34:42 PM Kevin Grittner wrote:
Simon Riggs si...@2ndquadrant.com wrote:
This is not transaction metadata, it is WAL record metadata
required for multi-master replication, see later
On Wed, Jun 20, 2012 at 12:53 PM, Andres Freund and...@2ndquadrant.com wrote:
I would prefer the event trigger way because that seems to be the most
extensible/reusable. It would allow a fully replicated databases and catalog
only instances.
I think we need to design event triggers in a way
On Wednesday, June 20, 2012 07:17:57 PM Robert Haas wrote:
On Wed, Jun 20, 2012 at 12:53 PM, Andres Freund and...@2ndquadrant.com
wrote:
I would prefer the event trigger way because that seems to be the most
extensible/reusable. It would allow a fully replicated databases and
catalog only
On 20 June 2012 23:56, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 20, 2012 at 10:08 AM, Simon Riggs si...@2ndquadrant.com wrote:
But I think getting even
single-master logical replication working well in a single release
cycle is going to be a job and a half.
OK, so your estimate
On Wed, Jun 20, 2012 at 1:40 PM, Andres Freund and...@2ndquadrant.com wrote:
I realized a problem with that idea this morning: it might work for
reading things, but if anyone attempts to write data you've got big
problems. Maybe we could get away with forbidding that, not sure.
Hm, why is
On 21 June 2012 01:40, Andres Freund and...@2ndquadrant.com wrote:
I think extraction is a very sensible place to start; actually, I
think it's the best possible place to start. But this particular
thread is about adding origin_ids to WAL, which I think is definitely
not the best place to
Hi Chris!
On Wednesday, June 20, 2012 07:06:28 PM Christopher Browne wrote:
On Wed, Jun 20, 2012 at 11:50 AM, Andres Freund and...@2ndquadrant.com
wrote:
On Wednesday, June 20, 2012 05:34:42 PM Kevin Grittner wrote:
Simon Riggs si...@2ndquadrant.com wrote:
This is not transaction
On 21 June 2012 01:06, Christopher Browne cbbro...@gmail.com wrote:
I guess I'm not seeing the purpose to having the origin node id in the
WAL stream either.
We have it in the Slony sl_log_* stream, however there is a crucial
difference, in that sl_log_* is expressly a shared structure. In
On 20.06.2012 17:35, Simon Riggs wrote:
On 20 June 2012 16:23, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20.06.2012 11:17, Simon Riggs wrote:
On 20 June 2012 15:45, Heikki Linnakangas
heikki.linnakan...@enterprisedb.comwrote:
So, if the origin id is not
On Wednesday, June 20, 2012 07:50:37 PM Robert Haas wrote:
On Wed, Jun 20, 2012 at 1:40 PM, Andres Freund and...@2ndquadrant.com
wrote:
I realized a problem with that idea this morning: it might work for
reading things, but if anyone attempts to write data you've got big
problems. Maybe
On 20.06.2012 16:46, Simon Riggs wrote:
The proposal now includes flag bits that would allow the addition of a
variable length header, should that ever become necessary. So the
unused space in the fixed header is not being used up as you say. In
any case, the fixed header still has 4 wasted
On 21 June 2012 02:32, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20.06.2012 17:35, Simon Riggs wrote:
On 20 June 2012 16:23, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20.06.2012 11:17, Simon Riggs wrote:
On 20 June 2012 15:45, Heikki
On 21 June 2012 02:45, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20.06.2012 16:46, Simon Riggs wrote:
The proposal now includes flag bits that would allow the addition of a
variable length header, should that ever become necessary. So the
unused space in the fixed
On 21 June 2012 02:56, Simon Riggs si...@2ndquadrant.com wrote:
I think allowing rmgrs to redefine the wasted bytes in the header is
the best idea.
Hmm, I think the best idea is to save 2 bytes off the WAL header for
all records, so there are no wasted bytes on 64bit or 32bit.
That way the
On 20.06.2012 21:51, Simon Riggs wrote:
On 21 June 2012 02:32, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I'm not saying that we need to implement all possible conflict resolution
algorithms right now - on the contrary I think conflict resolution belongs
outside core
It's
Hi,
On Wednesday, June 20, 2012 08:32:53 PM Heikki Linnakangas wrote:
On 20.06.2012 17:35, Simon Riggs wrote:
On 20 June 2012 16:23, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20.06.2012 11:17, Simon Riggs wrote:
On 20 June 2012 15:45, Heikki Linnakangas
On 20.06.2012 22:11, Simon Riggs wrote:
On 21 June 2012 02:56, Simon Riggssi...@2ndquadrant.com wrote:
I think allowing rmgrs to redefine the wasted bytes in the header is
the best idea.
Hmm, I think the best idea is to save 2 bytes off the WAL header for
all records, so there are no wasted
On Wed, Jun 20, 2012 at 3:15 PM, Andres Freund and...@2ndquadrant.com wrote:
To recap why we think origin_id is a sensible design choice:
There are many sensible replication topologies where it does make sense that
you want to receive changes (on node C) from one node (say B) that originated
On 21 June 2012 03:13, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20.06.2012 21:51, Simon Riggs wrote:
On 21 June 2012 02:32, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I'm not saying that we need to implement all possible conflict resolution
On 21 June 2012 03:23, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
And then we just put the originid on each heap record for MMR, in some
manner, discussed later.
I reserve the right to object to that, too :-).
OK. But that would be only for MMR, using special record
On Wednesday, June 20, 2012 09:24:29 PM Aidan Van Dyk wrote:
On Wed, Jun 20, 2012 at 3:15 PM, Andres Freund and...@2ndquadrant.com
wrote:
To recap why we think origin_id is a sensible design choice:
There are many sensible replication topologies where it does make sense
that you want to
On Wednesday, June 20, 2012 09:23:34 PM Heikki Linnakangas wrote:
And then we just put the originid on each heap record for MMR, in some
manner, discussed later.
I reserve the right to object to that, too :-). Others raised the
concern that a 16-bit integer is not a very intuitive
On Wed, Jun 20, 2012 at 3:27 PM, Andres Freund and...@2ndquadrant.com wrote:
OK, so in this case, I still don't see how the origin_id is even enough.
C applies the change originally from A (routed through B, because it's
faster). But when it get's the change directly from A, how does it
On Wednesday, June 20, 2012 09:41:03 PM Aidan Van Dyk wrote:
On Wed, Jun 20, 2012 at 3:27 PM, Andres Freund and...@2ndquadrant.com
wrote:
OK, so in this case, I still don't see how the origin_id is even
enough.
C applies the change originally from A (routed through B, because it's
On Wed, Jun 20, 2012 at 3:49 PM, Andres Freund and...@2ndquadrant.com wrote:
On Wednesday, June 20, 2012 09:41:03 PM Aidan Van Dyk wrote:
On Wed, Jun 20, 2012 at 3:27 PM, Andres Freund and...@2ndquadrant.com
wrote:
OK, so in this case, I still don't see how the origin_id is even
enough.
On Wednesday, June 20, 2012 10:12:46 PM Aidan Van Dyk wrote:
On Wed, Jun 20, 2012 at 3:49 PM, Andres Freund and...@2ndquadrant.com
wrote:
On Wednesday, June 20, 2012 09:41:03 PM Aidan Van Dyk wrote:
On Wed, Jun 20, 2012 at 3:27 PM, Andres Freund and...@2ndquadrant.com
wrote:
OK, so
Andres Freund and...@2ndquadrant.com writes:
On Monday, June 18, 2012 11:51:27 PM Daniel Farina wrote:
What's the cost of going a lot higher? Because if one makes enough
numerical space available, one can assign node identities without a
coordinator, a massive decrease in complexity.
It
On Tuesday, June 19, 2012 12:47:54 AM Christopher Browne wrote:
On Mon, Jun 18, 2012 at 11:50 AM, Andres Freund and...@2ndquadrant.com
wrote:
Hi Simon,
On Monday, June 18, 2012 05:35:40 PM Simon Riggs wrote:
On 13 June 2012 19:28, Andres Freund and...@2ndquadrant.com wrote:
This adds
Hi,
On Tuesday, June 19, 2012 08:03:04 AM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On Monday, June 18, 2012 11:51:27 PM Daniel Farina wrote:
What's the cost of going a lot higher? Because if one makes enough
numerical space available, one can assign node identities
On Tuesday, June 19, 2012 04:12:47 AM Steve Singer wrote:
On 12-06-18 07:30 AM, Andres Freund wrote:
Hrmpf #666. I will go through through the series commit-by-commit again
to make sure everything compiles again. Reordinging this late definitely
wasn't a good idea...
I pushed a rebased
Andres Freund and...@2ndquadrant.com writes:
On Tuesday, June 19, 2012 08:03:04 AM Tom Lane wrote:
Every WAL record? Why in heck would you attach it to every record?
Surely putting it in WAL page headers would be sufficient.
The idea is that you can have cascading, circular and whatever
On Tuesday, June 19, 2012 04:17:01 PM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On Tuesday, June 19, 2012 08:03:04 AM Tom Lane wrote:
Every WAL record? Why in heck would you attach it to every record?
Surely putting it in WAL page headers would be sufficient.
The
Andres Freund and...@2ndquadrant.com writes:
On Tuesday, June 19, 2012 04:17:01 PM Tom Lane wrote:
... (If you are thinking
of something sufficiently high-level that merging could possibly work,
then it's not WAL, and we shouldn't be trying to make the WAL
representation cater for it.)
The
On Tuesday, June 19, 2012 04:30:59 PM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On Tuesday, June 19, 2012 04:17:01 PM Tom Lane wrote:
... (If you are thinking
of something sufficiently high-level that merging could possibly work,
then it's not WAL, and we shouldn't be
Andres Freund and...@2ndquadrant.com writes:
On Tuesday, June 19, 2012 04:30:59 PM Tom Lane wrote:
... (If you are thinking
of something sufficiently high-level that merging could possibly work,
then it's not WAL, and we shouldn't be trying to make the WAL
representation cater for it.)
Do
Hi,
On Tuesday, June 19, 2012 06:11:20 PM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On Tuesday, June 19, 2012 04:30:59 PM Tom Lane wrote:
... (If you are thinking
of something sufficiently high-level that merging could possibly work,
then it's not WAL, and we
On Tue, Jun 19, 2012 at 12:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
On Tuesday, June 19, 2012 04:30:59 PM Tom Lane wrote:
... (If you are thinking
of something sufficiently high-level that merging could possibly work,
then it's not WAL, and we
On Tuesday, June 19, 2012 07:24:13 PM Robert Haas wrote:
On Tue, Jun 19, 2012 at 12:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
On Tuesday, June 19, 2012 04:30:59 PM Tom Lane wrote:
... (If you are thinking
of something sufficiently high-level
Andres Freund and...@2ndquadrant.com wrote:
Robert Haas wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
However, if we're dead set on doing it that way, let us put
information that is only relevant to logical replication records
into only the logical replication records.
Right. If we decide we
On Mon, Jun 18, 2012 at 6:35 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 13 June 2012 19:28, Andres Freund and...@2ndquadrant.com wrote:
This adds a new configuration parameter multimaster_node_id which determines
the id used for wal originating in one cluster.
Looks good and it seems
On 20 June 2012 04:58, Marko Kreen mark...@gmail.com wrote:
On Mon, Jun 18, 2012 at 6:35 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 13 June 2012 19:28, Andres Freund and...@2ndquadrant.com wrote:
This adds a new configuration parameter multimaster_node_id which determines
the id used for
On Tue, Jun 19, 2012 at 3:18 PM, Andres Freund and...@2ndquadrant.com wrote:
More seriously: Even if we don't put MM in core I think putting the basis for
it in core so that somebody can build such a solution reusing the existing
infrastructure is a sensible idea. Imo the only thing that
On 19 June 2012 14:03, Tom Lane t...@sss.pgh.pa.us wrote:
Every WAL record? Why in heck would you attach it to every record?
Surely putting it in WAL page headers would be sufficient. We could
easily afford to burn a page switch (if not a whole segment switch)
when changing masters.
This
On Tue, Jun 19, 2012 at 5:46 PM, Robert Haas robertmh...@gmail.com wrote:
Btw, what do you mean with conflating the stream? I don't really see that
being proposed.
It seems to me that you are intent on using the WAL stream as the
logical change stream. I think that's a bad design. Instead,
On 20 June 2012 05:46, Robert Haas robertmh...@gmail.com wrote:
It seems to me that you are intent on using the WAL stream as the
logical change stream. I think that's a bad design. Instead, you
should extract changes from WAL and then ship them around in a format
that is specific to
On Tuesday, June 19, 2012 10:58:44 PM Marko Kreen wrote:
On Mon, Jun 18, 2012 at 6:35 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 13 June 2012 19:28, Andres Freund and...@2ndquadrant.com wrote:
This adds a new configuration parameter multimaster_node_id which
determines the id used for
On 20 June 2012 04:31, Kevin Grittner kevin.gritt...@wicourts.gov wrote:
I've done a lot of MM replication,
and so far have not had to use a topology which allowed loops.
The proposal is to use WAL to generate the logical change stream. That
has been shown in testing to be around x4 faster
On 20 June 2012 05:59, Christopher Browne cbbro...@gmail.com wrote:
But it's undesirable to pull *all* the bulk of contents of WAL around
if it's only part of the data that is going to get applied. On a
physical streaming replica, any logical data that gets captured will
be useless. And on
On 20 June 2012 00:11, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
On Tuesday, June 19, 2012 04:30:59 PM Tom Lane wrote:
... (If you are thinking
of something sufficiently high-level that merging could possibly work,
then it's not WAL, and we shouldn't be
On Tuesday, June 19, 2012 11:46:56 PM Robert Haas wrote:
On Tue, Jun 19, 2012 at 3:18 PM, Andres Freund and...@2ndquadrant.com
wrote:
More seriously: Even if we don't put MM in core I think putting the basis
for it in core so that somebody can build such a solution reusing the
existing
Simon Riggs si...@2ndquadrant.com wrote:
The proposal is to use WAL to generate the logical change stream.
That has been shown in testing to be around x4 faster than having
a separate change stream, which must also be WAL logged (as Jan
noted).
Sure, that's why I want it.
If we use WAL
On Wednesday, June 20, 2012 12:15:03 AM Kevin Grittner wrote:
Simon Riggs si...@2ndquadrant.com wrote:
If we use WAL in this way, multi-master implies that the data will
*always* be in a loop. So in any configuration we must be able to
tell difference between changes made by one node and
Andres Freund and...@2ndquadrant.com wrote:
Yes, thats definitely a valid use-case. But that doesn't preclude
the other - also not uncommon - use-case where you want to have
different master which all contain up2date data.
I agree. I was just saying that while one requires an origin_id,
On Tue, Jun 19, 2012 at 5:59 PM, Christopher Browne cbbro...@gmail.com wrote:
On Tue, Jun 19, 2012 at 5:46 PM, Robert Haas robertmh...@gmail.com wrote:
Btw, what do you mean with conflating the stream? I don't really see that
being proposed.
It seems to me that you are intent on using the WAL
On Tue, Jun 19, 2012 at 6:14 PM, Andres Freund and...@2ndquadrant.com wrote:
I definitely agree that low-level apply is possible as a module. Sure change
extraction needs core support but I was talking about what you need to
implement it reusing the plain logical support...
What I do not
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Simon Riggs si...@2ndquadrant.com wrote:
The proposal is to use WAL to generate the logical change stream.
That has been shown in testing to be around x4 faster than having
a separate change stream, which must also be WAL logged (as Jan
On Monday, June 18, 2012 02:43:26 AM Steve Singer wrote:
On 12-06-13 01:27 PM, Andres Freund wrote:
The previous mail contained a patch with a mismerge caused by reording
commits. Corrected version attached.
Thanks to Steve Singer for noticing this quickly.
Attached is a more complete
On 13 June 2012 19:28, Andres Freund and...@2ndquadrant.com wrote:
This adds a new configuration parameter multimaster_node_id which determines
the id used for wal originating in one cluster.
Looks good and it seems this aspect at least is commitable in this CF.
Design decisions I think we
Hi Simon,
On Monday, June 18, 2012 05:35:40 PM Simon Riggs wrote:
On 13 June 2012 19:28, Andres Freund and...@2ndquadrant.com wrote:
This adds a new configuration parameter multimaster_node_id which
determines the id used for wal originating in one cluster.
Looks good and it seems this
On Mon, Jun 18, 2012 at 8:50 AM, Andres Freund and...@2ndquadrant.com wrote:
* Size of field. 16 bits is enough for 32,000 master nodes, which is
quite a lot. Do we need that many? I think we may have need for a few
flag bits, so I'd like to reserve at least 4 bits for flag bits, maybe
8
On Monday, June 18, 2012 11:51:27 PM Daniel Farina wrote:
On Mon, Jun 18, 2012 at 8:50 AM, Andres Freund and...@2ndquadrant.com
wrote:
* Size of field. 16 bits is enough for 32,000 master nodes, which is
quite a lot. Do we need that many? I think we may have need for a few
flag bits, so
On Mon, Jun 18, 2012 at 11:50 AM, Andres Freund and...@2ndquadrant.com wrote:
Hi Simon,
On Monday, June 18, 2012 05:35:40 PM Simon Riggs wrote:
On 13 June 2012 19:28, Andres Freund and...@2ndquadrant.com wrote:
This adds a new configuration parameter multimaster_node_id which
determines
On 12-06-18 07:30 AM, Andres Freund wrote:
Hrmpf #666. I will go through through the series commit-by-commit again to
make sure everything compiles again. Reordinging this late definitely wasn't a
good idea...
I pushed a rebased version with all those fixups (and removal of the
zeroRecPtr
On 12-06-18 11:50 AM, Andres Freund wrote:
Hi Simon,
I think we need to agree on the parameter name. It currently is
'multimaster_node_id'. In the discussion with Steve we got to
replication_node_id. I don't particularly like either.
Other suggestions?
Other things that come to mind (for
On 12-06-13 01:27 PM, Andres Freund wrote:
The previous mail contained a patch with a mismerge caused by reording
commits. Corrected version attached.
Thanks to Steve Singer for noticing this quickly.
Attached is a more complete review of this patch.
I agree that we will need to identify
The previous mail contained a patch with a mismerge caused by reording
commits. Corrected version attached.
Thanks to Steve Singer for noticing this quickly.
Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
From
99 matches
Mail list logo
