On 2013-11-22 14:43:15 -0500, Robert Haas wrote:
> The patch as proposed puts forward a particular way of
> doing that, and I think that neither that method *nor any other*
> should be part of core.
Working on something like that, updated the patch state to "waiting on
author".
Thanks,
Andres Fr
On Thu, Nov 21, 2013 at 8:26 AM, Andres Freund wrote:
> On 2013-11-21 08:22:05 -0500, Robert Haas wrote:
>> On Thu, Nov 21, 2013 at 6:15 AM, Andres Freund
>> wrote:
>> >> > WRT performance: I agree that fixed-width identifiers are more
>> >> > performant, that's why I went for them, but I am not
On 11/21/13, 6:15 AM, Andres Freund wrote:
> On 2013-11-20 15:05:17 -0500, Robert Haas wrote:
>>> That's what I had suggested to some people originally and the response
>>> was, well, somewhat unenthusiastic. It's not that easy to assign them in
>>> a meaningful automated manner. How do you automat
On Thu, Nov 21, 2013 at 6:15 AM, Andres Freund wrote:
>> > WRT performance: I agree that fixed-width identifiers are more
>> > performant, that's why I went for them, but I am not sure it's that
>> > important. The performance sensitive parts should all be done using the
>> > internal id the ident
On 2013-11-21 08:22:05 -0500, Robert Haas wrote:
> On Thu, Nov 21, 2013 at 6:15 AM, Andres Freund wrote:
> >> > WRT performance: I agree that fixed-width identifiers are more
> >> > performant, that's why I went for them, but I am not sure it's that
> >> > important. The performance sensitive part
On 2013-11-20 15:05:17 -0500, Robert Haas wrote:
> > That's what I had suggested to some people originally and the response
> > was, well, somewhat unenthusiastic. It's not that easy to assign them in
> > a meaningful automated manner. How do you automatically assign a pg
> > cluster an id?
>
> /d
On 2013-11-19 14:16:04 +, Greg Stark wrote:
> On Thu, Nov 14, 2013 at 5:26 PM, Andres Freund wrote:
>
> > But for that the receiving side needs to know up to where changes have
> > been applied. One relatively easy solution for that is that the
> > receiving side does something like:
> > UPDAT
Hi,
On 2013-11-19 18:49:27 -0500, Steve Singer wrote:
> >But for that the receiving side needs to know up to where changes have
> >been applied. One relatively easy solution for that is that the
> >receiving side does something like:
> >UPDATE replication_progress SET lsn = '0/1600' WHERE sou
On Tue, Nov 19, 2013 at 1:20 PM, Andres Freund wrote:
> On 2013-11-19 12:47:29 -0500, Robert Haas wrote:
>> On Tue, Nov 19, 2013 at 11:57 AM, Andres Freund
>> wrote:
>> > Agreed. As an alternative we could just have a single - probably longer
>> > than NAMEDATALEN - string to identify replicatio
On 11/14/2013 12:26 PM, Andres Freund wrote:
Hello,
As you know, the reason we are working changeset extraction is that we
want to build logical unidirection and bidirectional replication
ontop. To use changeset extraction effectively, I think one set of
related features ontop is very useful:
W
On 2013-11-19 12:47:29 -0500, Robert Haas wrote:
> On Tue, Nov 19, 2013 at 11:57 AM, Andres Freund
> wrote:
> > Agreed. As an alternative we could just have a single - probably longer
> > than NAMEDATALEN - string to identify replication progress and rely on
> > the users of the facility to build
On Tue, Nov 19, 2013 at 11:57 AM, Andres Freund wrote:
> Agreed. As an alternative we could just have a single - probably longer
> than NAMEDATALEN - string to identify replication progress and rely on
> the users of the facility to build the identifier automatically
> themselves using components
Hi,
On 2013-11-19 07:40:30 -0500, Robert Haas wrote:
> > This way, after a crash, restart, disconnect the replay process can look
> > into shared memory and check how far it has already replayed and restart
> > seamlessly. With minimal effort.
>
> It would be much less invasive for the replicatio
On Thu, Nov 14, 2013 at 5:26 PM, Andres Freund wrote:
> But for that the receiving side needs to know up to where changes have
> been applied. One relatively easy solution for that is that the
> receiving side does something like:
> UPDATE replication_progress SET lsn = '0/1600' WHERE source_i
On Thu, Nov 14, 2013 at 12:26 PM, Andres Freund wrote:
> As you know, the reason we are working changeset extraction is that we
> want to build logical unidirection and bidirectional replication
> ontop. To use changeset extraction effectively, I think one set of
> related features ontop is very u
15 matches
Mail list logo
