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 ag
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 definitely
On Wednesday, June 20, 2012 10:12:46 PM Aidan Van Dyk wrote:
> On Wed, Jun 20, 2012 at 3:49 PM, Andres Freund
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
> >
> > wrote:
> >> >> OK, so in this case, I still don't see
On Wed, Jun 20, 2012 at 3:49 PM, Andres Freund 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
> wrote:
>> >> OK, so in this case, I still don't see how the "origin_id" is even
>> >> enough.
>> >>
>> >> C applies the change o
On Wednesday, June 20, 2012 09:41:03 PM Aidan Van Dyk wrote:
> On Wed, Jun 20, 2012 at 3:27 PM, Andres Freund
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).
On Wed, Jun 20, 2012 at 3:27 PM, Andres Freund 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
>> know to *not*
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 i
On Wednesday, June 20, 2012 09:24:29 PM Aidan Van Dyk wrote:
> On Wed, Jun 20, 2012 at 3:15 PM, Andres Freund
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 chang
On 21 June 2012 03:23, 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 :-).
OK. But that would be only for MMR, using special record types.
> Others raised the concer
On 21 June 2012 03:13, Heikki Linnakangas
wrote:
> On 20.06.2012 21:51, Simon Riggs wrote:
>>
>> On 21 June 2012 02:32, Heikki Linnakangas
>> wrote:
>>>
>>> I'm not saying that we need to implement all possible conflict resolution
>>>
>>> algorithms right now - on the contrary I think conflict r
On Wed, Jun 20, 2012 at 3:15 PM, Andres Freund 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
> from some other n
On 20.06.2012 22:11, Simon Riggs wrote:
On 21 June 2012 02:56, Simon Riggs 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 32b
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
> >
> > wrote:
> >> On 20.06.2012 11:17, Simon Riggs wrote:
> >>> On 20 June 2012 15:45, Heikki Linnakangas
> >>>
> >>> wrote:
> >>>
On 20.06.2012 21:51, Simon Riggs wrote:
On 21 June 2012 02:32, Heikki Linnakangas
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 a pretty standard requirement to hav
On 21 June 2012 02:56, Simon Riggs 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 potential for use goes
On 21 June 2012 02:45, Heikki Linnakangas
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 header is not being "used up" as
On 21 June 2012 02:32, Heikki Linnakangas
wrote:
> On 20.06.2012 17:35, Simon Riggs wrote:
>>
>> On 20 June 2012 16:23, Heikki Linnakangas
>> wrote:
>>>
>>> On 20.06.2012 11:17, Simon Riggs wrote:
On 20 June 2012 15:45, Heikki Linnakangas
wrote:
>
>
> So, if t
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 byt
On Wednesday, June 20, 2012 07:50:37 PM Robert Haas wrote:
> On Wed, Jun 20, 2012 at 1:40 PM, Andres Freund
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 a
On 20.06.2012 17:35, Simon Riggs wrote:
On 20 June 2012 16:23, Heikki Linnakangas
wrote:
On 20.06.2012 11:17, Simon Riggs wrote:
On 20 June 2012 15:45, Heikki Linnakangas
wrote:
So, if the origin id is not sufficient for some conflict resolution
mechanisms, what extra information do yo
On 21 June 2012 01:06, Christopher Browne 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
> contrast, WA
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
wrote:
> > On Wednesday, June 20, 2012 05:34:42 PM Kevin Grittner wrote:
> >> Simon Riggs wrote:
> >> > This is not transaction metadata, it is WAL record metadata
> >>
On 21 June 2012 01:40, Andres Freund 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 start.
> Yep. I
On Wed, Jun 20, 2012 at 1:40 PM, Andres Freund 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 writing a problem?
On 20 June 2012 23:56, Robert Haas wrote:
> On Wed, Jun 20, 2012 at 10:08 AM, Simon Riggs 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
On Wednesday, June 20, 2012 07:17:57 PM Robert Haas wrote:
> On Wed, Jun 20, 2012 at 12:53 PM, Andres Freund
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
On Wed, Jun 20, 2012 at 12:53 PM, Andres Freund 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 you cannot simply cir
On Wed, Jun 20, 2012 at 11:50 AM, Andres Freund wrote:
> On Wednesday, June 20, 2012 05:34:42 PM Kevin Grittner wrote:
>> Simon Riggs wrote:
>> > This is not transaction metadata, it is WAL record metadata
>> > required for multi-master replication, see later point.
>
>> > We need to add informat
On 20 June 2012 23:34, Kevin Grittner wrote:
> Simon Riggs wrote:
>> Kevin Grittner 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.
>>
>> W
Hi,
On Wednesday, June 20, 2012 05:44:09 PM Robert Haas wrote:
> On Wed, Jun 20, 2012 at 10:02 AM, Andres Freund
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 gu
On Wed, Jun 20, 2012 at 10:08 AM, Simon Riggs 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
On Wednesday, June 20, 2012 05:34:42 PM Kevin Grittner wrote:
> Simon Riggs 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
> > source for gene
On Wed, Jun 20, 2012 at 10:02 AM, Andres Freund 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 to focus on exact
Simon Riggs wrote:
> Kevin Grittner 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 point is not wrong; you are sim
On 20 June 2012 16:23, Heikki Linnakangas
wrote:
> On 20.06.2012 11:17, Simon Riggs wrote:
>>
>> On 20 June 2012 15:45, Heikki Linnakangas
>> wrote:
>>>
>>> On 20.06.2012 10:32, Simon Riggs wrote:
On 20 June 2012 14:40, Heikki Linnakangas
>
>
> And I'm worried
> it
On 20 June 2012 21:42, Robert Haas wrote:
> On Wed, Jun 20, 2012 at 9:25 AM, Simon Riggs wrote:
>> On 20 June 2012 21:19, Robert Haas wrote:
>>> On Wed, Jun 20, 2012 at 5:47 AM, Simon Riggs wrote:
The idea that logical rep is some kind of useful end goal in itself is
slightly misleadi
On Wednesday, June 20, 2012 03:54:43 PM Robert Haas wrote:
> On Wed, Jun 20, 2012 at 9:43 AM, Andres Freund
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
> >> th
On Wednesday, June 20, 2012 03:42:39 PM Robert Haas wrote:
> On Wed, Jun 20, 2012 at 9:25 AM, Simon Riggs wrote:
> > On 20 June 2012 21:19, Robert Haas wrote:
> >> On Wed, Jun 20, 2012 at 5:47 AM, Simon Riggs
wrote:
> >>> The idea that logical rep is some kind of useful end goal in itself is
>
On Wed, Jun 20, 2012 at 9:43 AM, Andres Freund 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, and then pass
>>
-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
> th
On 20 June 2012 20:37, Kevin Grittner 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 even be enough in
On Wednesday, June 20, 2012 03:02:28 PM Robert Haas wrote:
> On Wed, Jun 20, 2012 at 5:15 AM, Andres Freund
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 some of that be
On Wed, Jun 20, 2012 at 9:25 AM, Simon Riggs wrote:
> On 20 June 2012 21:19, Robert Haas wrote:
>> On Wed, Jun 20, 2012 at 5:47 AM, Simon Riggs 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
>>> c
On 20 June 2012 21:19, Robert Haas wrote:
> On Wed, Jun 20, 2012 at 5:47 AM, Simon Riggs 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
On Wednesday, June 20, 2012 03:19:55 PM Robert Haas wrote:
> On Wed, Jun 20, 2012 at 5:47 AM, Simon Riggs 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
On Wed, Jun 20, 2012 at 5:47 AM, Simon Riggs 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 implementing multi-maste
On Wed, Jun 20, 2012 at 5:15 AM, Andres Freund 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* that it can be
> shippe
> 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 rec
On 20 June 2012 16:44, Heikki Linnakangas
wrote:
> On 20.06.2012 11:34, Simon Riggs wrote:
>>
>> On 20 June 2012 16:23, Heikki Linnakangas
>> 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.
On Wednesday, June 20, 2012 02:35:59 AM Robert Haas wrote:
> On Tue, Jun 19, 2012 at 5:59 PM, Christopher Browne
wrote:
> > On Tue, Jun 19, 2012 at 5:46 PM, Robert Haas
wrote:
> >>> Btw, what do you mean with "conflating" the stream? I don't really see
> >>> that being proposed.
> >>
> >> It s
On 20.06.2012 11:34, Simon Riggs wrote:
On 20 June 2012 16:23, Heikki Linnakangas
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.
Hu
On 20 June 2012 16:23, Heikki Linnakangas
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? Multi-master replication is what is
On 20.06.2012 11:17, Simon Riggs wrote:
On 20 June 2012 15:45, Heikki Linnakangas
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 mecha
On 20 June 2012 15:45, Heikki Linnakangas
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 mechanism, and has nev
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
var
On 20 June 2012 14:40, Heikki Linnakangas
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 generates a new WAL record.
> 3. N
On 20 June 2012 08:35, Robert Haas 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 the on-the-w
On 20.06.2012 01:27, Kevin Grittner wrote:
Andres Freund 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 requir
On 20 June 2012 11:26, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Simon Riggs 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
"Kevin Grittner" writes:
> Simon Riggs 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.
I
On Tue, Jun 19, 2012 at 6:14 PM, Andres Freund 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 understand is how yo
On Tue, Jun 19, 2012 at 5:59 PM, Christopher Browne wrote:
> On Tue, Jun 19, 2012 at 5:46 PM, Robert Haas 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 c
Andres Freund 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,
the other doesn't. An
On Wednesday, June 20, 2012 12:15:03 AM Kevin Grittner wrote:
> Simon Riggs 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 another.
>
> Onl
Simon Riggs 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 in this way, mult
On Tuesday, June 19, 2012 11:46:56 PM Robert Haas wrote:
> On Tue, Jun 19, 2012 at 3:18 PM, Andres Freund
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
On 20 June 2012 00:11, Tom Lane wrote:
> Andres Freund 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
>>>
On 20 June 2012 05:59, Christopher Browne 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 a "logical re
On 20 June 2012 04:31, Kevin Grittner 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 than having a
separate change
On Tuesday, June 19, 2012 10:58:44 PM Marko Kreen wrote:
> On Mon, Jun 18, 2012 at 6:35 PM, Simon Riggs wrote:
> > On 13 June 2012 19:28, Andres Freund wrote:
> >> This adds a new configuration parameter multimaster_node_id which
> >> determines the id used for wal originating in one cluster.
> >
On 20 June 2012 05:46, Robert Haas 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 logical replication.
Th
On Tue, Jun 19, 2012 at 5:46 PM, Robert Haas 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, you
> should
On 19 June 2012 14:03, 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. We could
> easily afford to burn a page switch (if not a whole segment switch)
> when changing masters.
This does appear to
On Tue, Jun 19, 2012 at 3:18 PM, Andres Freund 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 requires explicit
> suppor
On 20 June 2012 04:58, Marko Kreen wrote:
> On Mon, Jun 18, 2012 at 6:35 PM, Simon Riggs wrote:
>> On 13 June 2012 19:28, Andres Freund wrote:
>>> This adds a new configuration parameter multimaster_node_id which determines
>>> the id used for wal originating in one cluster.
>>
>> Looks good and
On Mon, Jun 18, 2012 at 6:35 PM, Simon Riggs wrote:
> On 13 June 2012 19:28, Andres Freund 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 th
Andres Freund wrote:
> Robert Haas wrote:
>> Tom Lane 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 need this, and if we did de
On Tuesday, June 19, 2012 07:24:13 PM Robert Haas wrote:
> On Tue, Jun 19, 2012 at 12:11 PM, Tom Lane wrote:
> > Andres Freund 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 possibl
On Tue, Jun 19, 2012 at 12:11 PM, Tom Lane wrote:
> Andres Freund 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
Hi,
On Tuesday, June 19, 2012 06:11:20 PM Tom Lane wrote:
> Andres Freund 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 try
Andres Freund 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 you reall
On Tuesday, June 19, 2012 04:30:59 PM Tom Lane wrote:
> Andres Freund 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 m
Andres Freund 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 idea is that
On Tuesday, June 19, 2012 04:17:01 PM Tom Lane wrote:
> Andres Freund 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 th
Andres Freund 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 replication
> topo
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
Hi,
On Tuesday, June 19, 2012 08:03:04 AM Tom Lane wrote:
> Andres Freund 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
> >> co
On Tuesday, June 19, 2012 12:47:54 AM Christopher Browne wrote:
> On Mon, Jun 18, 2012 at 11:50 AM, Andres Freund
wrote:
> > Hi Simon,
> >
> > On Monday, June 18, 2012 05:35:40 PM Simon Riggs wrote:
> >> On 13 June 2012 19:28, Andres Freund wrote:
> >> > This adds a new configuration parameter
Andres Freund 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 would increase the
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 n
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 patch
On Mon, Jun 18, 2012 at 11:50 AM, Andres Freund wrote:
> Hi Simon,
>
> On Monday, June 18, 2012 05:35:40 PM Simon Riggs wrote:
>> On 13 June 2012 19:28, Andres Freund wrote:
>> > This adds a new configuration parameter multimaster_node_id which
>> > determines the id used for wal originating in o
On Monday, June 18, 2012 11:51:27 PM Daniel Farina wrote:
> On Mon, Jun 18, 2012 at 8:50 AM, Andres Freund
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 res
On Mon, Jun 18, 2012 at 8:50 AM, Andres Freund 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 bits. Even if we do
Hi Simon,
On Monday, June 18, 2012 05:35:40 PM Simon Riggs wrote:
> On 13 June 2012 19:28, Andres Freund 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
On 13 June 2012 19:28, Andres Freund 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 need to review are
* N
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 mor
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
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
From: Andres Freund
One solution to avoid loops when doing wal based logical replication in
topologies which are more complex than one unidirectional transport is
introducing the concept of a 'origin_id' into the wal stream. Luckily there is
some padding in the XLogRecord struct that allows us to
100 matches
Mail list logo
