Simon Riggs wrote:
> On Fri, 2010-01-15 at 19:29 +0200, Heikki Linnakangas wrote:
>
> > File-based Log Shipping
> > Planning
> > Implementation
> > Streaming Replication
> > Setting up
>
> How about "Log Streaming Replication"?
>
> So its a particular kind of replicatio
Heikki Linnakangas wrote:
> > Uh, do we really want to call this "replication" rather than archive log
> > streaming or something. It seems "replication" is a generic term and
> > will confuse people who are using other replication solutions like
> > Slony.
>
> Good question. OTOH, if we move the
On Fri, 2010-01-15 at 22:38 +, Greg Stark wrote:
> On Fri, Jan 15, 2010 at 6:39 PM, Simon Riggs wrote:
> > On Fri, 2010-01-15 at 19:29 +0200, Heikki Linnakangas wrote:
> > How about "Log Streaming Replication"?
> >
> > So its a particular kind of replication, which seems correct to me.
>
> I
On Fri, Jan 15, 2010 at 6:39 PM, Simon Riggs wrote:
> On Fri, 2010-01-15 at 19:29 +0200, Heikki Linnakangas wrote:
> How about "Log Streaming Replication"?
>
> So its a particular kind of replication, which seems correct to me.
I thought the whole point of this effort was to be able to bill it as
On Fri, 2010-01-15 at 19:29 +0200, Heikki Linnakangas wrote:
> File-based Log Shipping
> Planning
> Implementation
> Streaming Replication
> Setting up
How about "Log Streaming Replication"?
So its a particular kind of replication, which seems correct to me.
--
Simon
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
+1, it is not replication. I would call it something like continuous
archiving or streaming pitr
I agree we should consider a different name.
> But I'm still wondering why this isn't replication.
Because replication is an ambiguous
On Fri, Jan 15, 2010 at 12:11:01PM -0500, Tom Lane wrote:
> Heikki Linnakangas writes:
> > I moved the line for src/backend/replication/walreceiver in
> > src/Makefile further down, after src/interfaces. That should fix
> > the build failures for now, but I'm all ears if there's better
> > suggest
On Jan 15, 2010, at 9:37 AM, Robert Haas wrote:
> But I'm still wondering why this isn't replication.
I was wondering the same thing. ISTM that the docs could reference third-party
replication solutions, too (or a wiki page listing them, since they'll change
often).
Anyway, I think Heikki's pr
On Fri, Jan 15, 2010 at 12:30 PM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> On Fri, Jan 15, 2010 at 12:17 PM, Joshua D. Drake
>> wrote:
Uh, do we really want to call this "replication" rather than archive log
streaming or something. It seems "replication" is a generic term and
On Fri, 2010-01-15 at 19:30 +0200, Heikki Linnakangas wrote:
> Robert Haas wrote:
> > On Fri, Jan 15, 2010 at 12:17 PM, Joshua D. Drake
> > wrote:
> >>> Uh, do we really want to call this "replication" rather than archive log
> >>> streaming or something. It seems "replication" is a generic term
Robert Haas wrote:
> On Fri, Jan 15, 2010 at 12:17 PM, Joshua D. Drake
> wrote:
>>> Uh, do we really want to call this "replication" rather than archive log
>>> streaming or something. It seems "replication" is a generic term and
>>> will confuse people who are using other replication solutions
Bruce Momjian wrote:
> Heikki Linnakangas wrote:
>> I've now committed streaming replication. I moved the files around a
>> bit, and put the walreceiver/walsender stuff in a new
>> src/backend/replication subdirectory. There's enough stuff there already
>> to deserve a new subdirectory, and if we a
On Fri, Jan 15, 2010 at 12:17 PM, Joshua D. Drake
wrote:
>> Uh, do we really want to call this "replication" rather than archive log
>> streaming or something. It seems "replication" is a generic term and
>> will confuse people who are using other replication solutions like
>> Slony.
>
> +1, it
On Fri, 2010-01-15 at 05:36 -0500, Bruce Momjian wrote:
> Heikki Linnakangas wrote:
> > I've now committed streaming replication. I moved the files around a
> > bit, and put the walreceiver/walsender stuff in a new
> > src/backend/replication subdirectory. There's enough stuff there already
> > to
Heikki Linnakangas writes:
> I moved the line for src/backend/replication/walreceiver in src/Makefile
> further down, after src/interfaces. That should fix the build failures
> for now, but I'm all ears if there's better suggestions.
Yeah, I saw. Seems like a reasonable solution for now.
Robert Haas wrote:
> On Fri, Jan 15, 2010 at 11:47 AM, Heikki Linnakangas
> wrote:
>> Tom Lane wrote:
>>> Heikki Linnakangas writes:
Yep. What's happening is that "make -j" starts building libpq and
walreceiver.so simultaneously, because of the above line in the
Makefile. We actual
Heikki Linnakangas writes:
> Tom Lane wrote:
>> I'm actually fairly uncomfortable with the notion that something buried
>> deep within the src/backend tree is going to reach over and cause libpq
>> to get built. Maybe the real answer is that you put walreceiver in the
>> wrong place, and it ought
On Fri, Jan 15, 2010 at 11:47 AM, Heikki Linnakangas
wrote:
> Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> Yep. What's happening is that "make -j" starts building libpq and
>>> walreceiver.so simultaneously, because of the above line in the
>>> Makefile. We actually have the same problem in
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Yep. What's happening is that "make -j" starts building libpq and
>> walreceiver.so simultaneously, because of the above line in the
>> Makefile. We actually have the same problem in src/bin/*/Makefile, but
>> we don't notice it there because src/int
Heikki Linnakangas writes:
> Yep. What's happening is that "make -j" starts building libpq and
> walreceiver.so simultaneously, because of the above line in the
> Makefile. We actually have the same problem in src/bin/*/Makefile, but
> we don't notice it there because src/interfaces is listed befo
Heikki Linnakangas wrote:
> Also, I'm seeing a failure in buildfarm member 'colugos':
>
> /opt/local/bin/ccache /Developer/usr/bin/llvm-gcc-4.2 -no-cpp-precomp
> -I/opt/local/include -Wall -Wmissing-prototypes -Wpointer-arith
> -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing
> -f
Boszormenyi Zoltan wrote:
> Heikki Linnakangas írta:
>> I've now committed streaming replication. I moved the files around a
>> bit, and put the walreceiver/walsender stuff in a new
>> src/backend/replication subdirectory. [snip]
>
> there's one loose end indeed.
> "make maintainer-clean" doesn't
Hi,
Heikki Linnakangas írta:
> I've now committed streaming replication. I moved the files around a
> bit, and put the walreceiver/walsender stuff in a new
> src/backend/replication subdirectory. [snip]
there's one loose end indeed.
"make maintainer-clean" doesn't delete these:
src/backend/repli
2010/1/15 Bruce Momjian :
> Heikki Linnakangas wrote:
>> I've now committed streaming replication. I moved the files around a
>> bit, and put the walreceiver/walsender stuff in a new
>> src/backend/replication subdirectory. There's enough stuff there already
>> to deserve a new subdirectory, and if
Heikki Linnakangas wrote:
> I've now committed streaming replication. I moved the files around a
> bit, and put the walreceiver/walsender stuff in a new
> src/backend/replication subdirectory. There's enough stuff there already
> to deserve a new subdirectory, and if we add the capability for
> str
I've now committed streaming replication. I moved the files around a
bit, and put the walreceiver/walsender stuff in a new
src/backend/replication subdirectory. There's enough stuff there already
to deserve a new subdirectory, and if we add the capability for
streaming base backups etc. that has be
26 matches
Mail list logo
