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
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
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:wait for slave to process
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
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 copies data
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,
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 then apply
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 reconstruct
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_commit would not
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.
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
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's get the
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
parameter
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:
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
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 with
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 approach,
where
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
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 apply can
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:have
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 sounds best and I
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
optionally
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 architecture
*
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,
* different
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
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
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
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
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
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 think the
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 reproducibility.
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
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 believe so.
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 fits many
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: do we
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
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
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
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
transaction
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 are able to
-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 performance
41 matches
Mail list logo
