On Wed, 2008-08-13 at 12:55 -0400, Bruce Momjian wrote:
> NTT is working with EnterpriseDB
> on the WAL steaming code to be released to the community.
Hopefully the code isn't steaming... :-)
and that we will be able to see detailed designs and code soon.
Might end up as a big pileup otherwise.
Simon Riggs wrote:
>
> On Wed, 2008-08-13 at 11:27 -0400, Bruce Momjian wrote:
>
> > I disagree. If they make it the master they change the setting.
>
> It's not acceptable to force people to edit a configuration file when
> failover occurs. Some people wish to automate this and fumbling
> para
Simon Riggs wrote:
>
> On Wed, 2008-08-13 at 11:17 -0400, Bruce Momjian wrote:
>
> > I think doing the WAL streaming and allowing a read-only slave is
> > enough work to keep Simon busy for quite some time. I don't
> > understand why the logical issue is being discussed at this stage ---
> > let
On Wed, 2008-08-13 at 11:27 -0400, Bruce Momjian wrote:
> I disagree. If they make it the master they change the setting.
It's not acceptable to force people to edit a configuration file when
failover occurs. Some people wish to automate this and fumbling
parameter values at this important time
On Wed, 2008-08-13 at 11:17 -0400, Bruce Momjian wrote:
> I think doing the WAL streaming and allowing a read-only slave is
> enough work to keep Simon busy for quite some time. I don't
> understand why the logical issue is being discussed at this stage ---
> let's get the other stuff done first
Simon Riggs wrote:
> > > The main point of the post is that the parameter would be transaction
> > > controlled, so *must* be set in the transaction and thus *must* be set
> > > on the master. Otherwise the capability is not available in the way I am
> > > describing.
> >
> > Oh, so synchronous_co
Simon Riggs wrote:
>
> On Wed, 2008-08-13 at 15:38 +0200, Markus Wanner wrote:
>
> > Simon Riggs wrote:
> > > Classification of Replication Techniques
> >
> > Thanks for your classifications. It helps a great deal to clarify.
> >
> > > Type 2 is where you ship the WAL (efficient) then use it to
On Wed, 2008-08-13 at 15:38 +0200, Markus Wanner wrote:
> Simon Riggs wrote:
> > Classification of Replication Techniques
>
> Thanks for your classifications. It helps a great deal to clarify.
>
> > Type 2 is where you ship the WAL (efficient) then use it to reconstruct
> > SQL (flexible) and t
Hi,
Simon Riggs wrote:
Classification of Replication Techniques
Thanks for your classifications. It helps a great deal to clarify.
Type 2 is where you ship the WAL (efficient) then use it to reconstruct
SQL (flexible) and then apply that to other nodes. It is somewhat harder
than type 1, but
On Wed, 2008-08-13 at 11:27 +0200, Markus Wanner wrote:
> Hi,
>
> Robert Hodges wrote:
> > Part of this is semantics—I like Simon’s logical vs. physical
> > terminology because it distinguishes neatly between replication that
> > copies implementation down to OIDs etc. and replication that copi
Hi,
Robert Hodges wrote:
Part of this is semantics—I like Simon’s logical vs. physical
terminology because it distinguishes neatly between replication that
copies implementation down to OIDs etc. and replication that copies data
content including schema changes but not implementation.
So far
On Tue, 2008-08-12 at 13:33 -0400, Bruce Momjian wrote:
> Simon Riggs wrote:
> > > > > with values of:
> > > > >
> > > > > nothing:have network traffic send WAL as needed
> > > > > netflush: wait for flush of WAL network packets to slave
> > > > > process:w
Hi,
Alvaro Herrera wrote:
Actually I think the idea here is to take certain WAL records, translate
them into "portable" constructs, ship them,
At which point it clearly shouldn't be called a WAL shipping method.
What would it have to do with the WAL at all, then? Why translate from
WAL reco
Hi,
Robert Hodges wrote:
I like Simon’s logical vs. physical terminology
So far, it seems to mainly have caused confusion (physical replication,
but logical application? logical replication using WAL shipping?). At
least I still prefer the more meaningful and descriptive terms, like
"log sh
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> What I think Simon was actually driving at was query-shipping, which is
> >> not my idea of "WAL" at all. It has some usefulness, but also a bunch
> >> of downsides of its very own, mostly centered around reprodu
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What I think Simon was actually driving at was query-shipping, which is
>> not my idea of "WAL" at all. It has some usefulness, but also a bunch
>> of downsides of its very own, mostly centered around reproducibility.
> Actually I th
Hi Tom,
Part of this is semantics-I like Simon's logical vs. physical terminology
because it distinguishes neatly between replication that copies implementation
down to OIDs etc. and replication that copies data content including schema
changes but not implementation. It seems a noble goal get
Tom Lane wrote:
> What I think Simon was actually driving at was query-shipping, which is
> not my idea of "WAL" at all. It has some usefulness, but also a bunch
> of downsides of its very own, mostly centered around reproducibility.
> With the current WAL design I have some faith that the slaves
Markus Wanner <[EMAIL PROTECTED]> writes:
> Robert Hodges wrote:
>> Could you expand on why logical application of WAL records is impractical in
>> these cases? This is what Oracle does. Moreover once you are into SQL a
>> lot of other use cases immediately become practical, such as large scale
>
Hi,
Robert Hodges wrote:
Could you expand on why logical application of WAL records is impractical in
these cases? This is what Oracle does. Moreover once you are into SQL a
lot of other use cases immediately become practical, such as large scale
master/slave set-ups for read scaling.
I cann
Hi Tom,
Could you expand on why logical application of WAL records is impractical in
these cases? This is what Oracle does. Moreover once you are into SQL a
lot of other use cases immediately become practical, such as large scale
master/slave set-ups for read scaling.
Thanks, Robert
On 8/12/08
On Tue, 2008-08-12 at 15:40 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Tue, 2008-08-12 at 11:52 -0400, Bruce Momjian wrote:
> >> What is the attraction of logical application of the WAL logs?
> >> Transmitting to a server with different architecture?
>
> > Yes,
>
>
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Tue, 2008-08-12 at 11:52 -0400, Bruce Momjian wrote:
>> What is the attraction of logical application of the WAL logs?
>> Transmitting to a server with different architecture?
> Yes,
> * different release
> * different encoding
> * different CPU archi
Simon Riggs wrote:
> > > > with values of:
> > > >
> > > > nothing:have network traffic send WAL as needed
> > > > netflush: wait for flush of WAL network packets to slave
> > > > process:wait for slave to process WAL traffic and
> > > >
On Tue, 2008-08-12 at 12:54 -0400, Bruce Momjian wrote:
> Simon Riggs wrote:
> >
> > On Tue, 2008-08-12 at 11:51 -0400, Bruce Momjian wrote:
> > > I think you need to make it an enumerated type like log_min_messages;
> > > something like:
> > >
> > > wal_transfer_wait
> >
> > Yeh, that way s
Simon Riggs wrote:
>
> On Tue, 2008-08-12 at 11:51 -0400, Bruce Momjian wrote:
> > I think you need to make it an enumerated type like log_min_messages;
> > something like:
> >
> > wal_transfer_wait
>
> Yeh, that way sounds best and I like name.
>
> > with values of:
> >
> > nothing:
Simon Riggs wrote:
> > What is the attraction of logical application of the WAL logs?
> > Transmitting to a server with different architecture?
>
> Yes,
>
> * different release
> * different encoding
> * different CPU architecture
> * (with the correct transform) a different DBMS
>
> So logical
On Tue, 2008-08-12 at 11:51 -0400, Bruce Momjian wrote:
> I think you need to make it an enumerated type like log_min_messages;
> something like:
>
> wal_transfer_wait
Yeh, that way sounds best and I like name.
> with values of:
>
> nothing:have network traffic send WAL as
On Tue, 2008-08-12 at 11:52 -0400, Bruce Momjian wrote:
> Simon Riggs wrote:
> >
> > On Sat, 2008-07-26 at 10:17 +0200, Markus Wanner wrote:
> > > What I still don't understand is, why you are speaking about
> > > "logical"
> > > replication. It rather sounds like an ordinary log shipping approa
Simon Riggs wrote:
>
> On Sat, 2008-07-26 at 10:17 +0200, Markus Wanner wrote:
> > What I still don't understand is, why you are speaking about
> > "logical"
> > replication. It rather sounds like an ordinary log shipping approach,
> > where the complete WAL is sent over the wire. Nothing wrong
Simon Riggs wrote:
> We can generalise this as three closed questions, answered either Yes
> (Synchronous) or No (Asynchronous)
>
> * Does WAL get forced to disk on primary at commit time?
> * Does WAL get forced across link to standby at commit time?
> * Does WAL get forced to disk on standby at
On Sat, 2008-07-26 at 10:17 +0200, Markus Wanner wrote:
> What I still don't understand is, why you are speaking about
> "logical"
> replication. It rather sounds like an ordinary log shipping approach,
> where the complete WAL is sent over the wire. Nothing wrong with
> that,
> it certainly fi
On Sat, 2008-07-26 at 10:17 +0200, Markus Wanner wrote:
>
> > Expensive as in we need to parse and handle each statement
> separately.
> > If we have a single parameter then much lower overhead.
>
> Is that really much of a concern when otherwise caring about network
> and i/o latency?
I belie
Hi,
Simon Riggs wrote:
There is no sync() during WAL apply when each individual transaction
hits commit. This is because there is "no WAL" i.e. changes comes from
WAL to the database, so we have no need of a second WAL to protect the
changes being made.
Aha, that makes much more sense to me no
On Wed, 2008-07-23 at 10:49 +1000, Jens-Wolfhard Schicke wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Simon Riggs wrote:
> > Asynchronous commit controls whether we go to disk at time of commit, or
> > whether we defer this slightly. We have the same options with
> > replication:
Hi,
Jens-Wolfhard Schicke wrote:
* Does WAL get forced to disk on primary at commit time?
* Does WAL get forced across link to standby at commit time?
* Does WAL get forced to disk on standby at commit time?
* Does WAL get applied [and synced] to disk on standby at commit time?
I think that's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Simon Riggs wrote:
> Asynchronous commit controls whether we go to disk at time of commit, or
> whether we defer this slightly. We have the same options with
> replication: do we replicate at time of commit, or do we defer this
> slightly for performan
On Wed, 2008-07-23 at 01:39 +0300, Marko Kreen wrote:
> On 7/22/08, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > We could represent this with 3 parameters:
> > synchronous_commit = on | off
> > synchronous_standby_transfer = on | off
> > synchronous_standby_wal_fsync = on | off
> >
> > If we ar
On 7/22/08, Simon Riggs <[EMAIL PROTECTED]> wrote:
> We could represent this with 3 parameters:
> synchronous_commit = on | off
> synchronous_standby_transfer = on | off
> synchronous_standby_wal_fsync = on | off
>
> If we are able to define these robustness characteristics for each
> transac
Hi,
very nice proposal and thoughts. Allow me to compare against Postgres-R
again.
Simon Riggs wrote:
Asynchronous commit controls whether we go to disk at time of commit, or
whether we defer this slightly. We have the same options with
replication: do we replicate at time of commit, or do we
One of the cool features of 8.3 was the ability to control at the
transaction level whether we would use synchronous or asynchronous
commit.
We're planning to add integrated replication features to 8.4, and I
think it will be possible to extend the concept of asynchronous commit
to a more general
41 matches
Mail list logo
