Обсуждение: synchronous_commit and remote_write
It seems pretty confusing that synchronous_commit = 'remote_write' means write confirmed to the remote socket, not write to the file system. Is there no better term we could some up with? remote_pipe? remote_transfer? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Tue, May 8, 2012 at 9:13 PM, Bruce Momjian <bruce@momjian.us> wrote: > It seems pretty confusing that synchronous_commit = 'remote_write' means > write confirmed to the remote socket, not write to the file system. Is > there no better term we could some up with? remote_pipe? > remote_transfer? remote_accept? And then, I could envision (if it continues down this road): off local remote_accept remote_write remote_sync remote_apply(implies visible to new connections on the standby) Not saying all off these are necessarily worth it, but they are all the various "stages" of WAL processing on the remote... -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
On Tue, May 08, 2012 at 10:04:46PM -0400, Aidan Van Dyk wrote: > On Tue, May 8, 2012 at 9:13 PM, Bruce Momjian <bruce@momjian.us> wrote: > > It seems pretty confusing that synchronous_commit = 'remote_write' means > > write confirmed to the remote socket, not write to the file system. Is > > there no better term we could some up with? remote_pipe? > > remote_transfer? > > remote_accept? > > And then, I could envision (if it continues down this road): > off > local > remote_accept > remote_write > remote_sync > remote_apply (implies visible to new connections on the standby) > > Not saying all off these are necessarily worth it, but they are all > the various "stages" of WAL processing on the remote... The _big_ problem with "write" is that we might need that someday to indicate some other kind of write, e.g. write to kernel, fsync to disk. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Tue, May 8, 2012 at 10:09 PM, Bruce Momjian <bruce@momjian.us> wrote: >> And then, I could envision (if it continues down this road): >> off >> local >> remote_accept >> remote_write >> remote_sync >> remote_apply (implies visible to new connections on the standby) >> >> Not saying all off these are necessarily worth it, but they are all >> the various "stages" of WAL processing on the remote... > > The _big_ problem with "write" is that we might need that someday to > indicate some other kind of write, e.g. write to kernel, fsync to disk. Well, yes, but in the sequence of: >> remote_accept >> remote_write >> remote_sync it is much more clear... With a single "remote_write", you can't tell just by itself it that is intended to be "it's a write *to* the remote", or "it's a write *by* the remote". But when combined with other terms, only one makes sense in all cases. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
On Tue, May 08, 2012 at 10:29:31PM -0400, Aidan Van Dyk wrote: > On Tue, May 8, 2012 at 10:09 PM, Bruce Momjian <bruce@momjian.us> wrote: > > >> And then, I could envision (if it continues down this road): > >> off > >> local > >> remote_accept > >> remote_write > >> remote_sync > >> remote_apply (implies visible to new connections on the standby) > >> > >> Not saying all off these are necessarily worth it, but they are all > >> the various "stages" of WAL processing on the remote... > > > > The _big_ problem with "write" is that we might need that someday to > > indicate some other kind of write, e.g. write to kernel, fsync to disk. > > Well, yes, but in the sequence of: > >> remote_accept > >> remote_write > >> remote_sync > > it is much more clear... > > With a single "remote_write", you can't tell just by itself it that is > intended to be "it's a write *to* the remote", or "it's a write *by* > the remote". But when combined with other terms, only one makes sense > in all cases. Yep. In fact, remote_write I thought meant a remote write, while it currently means a write to the remote. I like remote_accept. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On 9 May 2012 03:52, Bruce Momjian <bruce@momjian.us> wrote: > On Tue, May 08, 2012 at 10:29:31PM -0400, Aidan Van Dyk wrote: >> On Tue, May 8, 2012 at 10:09 PM, Bruce Momjian <bruce@momjian.us> wrote: >> >> >> And then, I could envision (if it continues down this road): >> >> off >> >> local >> >> remote_accept >> >> remote_write >> >> remote_sync >> >> remote_apply (implies visible to new connections on the standby) >> >> >> >> Not saying all off these are necessarily worth it, but they are all >> >> the various "stages" of WAL processing on the remote... >> > >> > The _big_ problem with "write" is that we might need that someday to >> > indicate some other kind of write, e.g. write to kernel, fsync to disk. >> >> Well, yes, but in the sequence of: >> >> remote_accept >> >> remote_write >> >> remote_sync >> >> it is much more clear... >> >> With a single "remote_write", you can't tell just by itself it that is >> intended to be "it's a write *to* the remote", or "it's a write *by* >> the remote". But when combined with other terms, only one makes sense >> in all cases. > > Yep. In fact, remote_write I thought meant a remote write, while it > currently means a write to the remote. I like remote_accept. The naming is not arbitrary. -1 to changing it as suggested. It is as Aidan says, a state between receive and fsync, normally referred to as write. Plus the word remote denotes it is on the standby, not the local master. So both words have specific meaning, and IMHO clear meaning. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Wed, May 09, 2012 at 08:52:40AM +0100, Simon Riggs wrote: > >> Well, yes, but in the sequence of: > >> >> remote_accept > >> >> remote_write > >> >> remote_sync > >> > >> it is much more clear... > >> > >> With a single "remote_write", you can't tell just by itself it that is > >> intended to be "it's a write *to* the remote", or "it's a write *by* > >> the remote". But when combined with other terms, only one makes sense > >> in all cases. > > > > Yep. In fact, remote_write I thought meant a remote write, while it > > currently means a write to the remote. I like remote_accept. > > The naming is not arbitrary. -1 to changing it as suggested. > > It is as Aidan says, a state between receive and fsync, normally > referred to as write. Let me point out that our documentation says nothing about it being written to the kernel --- it just says "has received the commit record of the transaction to memory." -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Wed, May 9, 2012 at 7:29 AM, Bruce Momjian <bruce@momjian.us> wrote: > Let me point out that our documentation says nothing about it being > written to the kernel --- it just says "has received the commit record > of the transaction to memory." Maybe remote_receive would be better. If we're actually writing it back to the kernel before acknowledging the commit, that seems like an implementation defect more than anything else, since it does not - AFAICS - provide any additional, useful guarantee. Another thing I've been wondering is whether, perhaps, we ought to keep synchronous_commit tri-valued: on/local/off, and have a separate GUC for synchronous_replication_mode. It's a bit arbitrary that "on" happens to mean remote fsync rather than remote write/receive. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 9 May 2012 13:48, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, May 9, 2012 at 7:29 AM, Bruce Momjian <bruce@momjian.us> wrote: >> Let me point out that our documentation says nothing about it being >> written to the kernel --- it just says "has received the commit record >> of the transaction to memory." > > Maybe remote_receive would be better. If we're actually writing it > back to the kernel before acknowledging the commit, that seems like an > implementation defect more than anything else, since it does not - > AFAICS - provide any additional, useful guarantee. It does provide an additional guarantee, but I accept you personally may not find that useful. If the docs don't describe it well enough, then we can change the docs. > Another thing I've been wondering is whether, perhaps, we ought to > keep synchronous_commit tri-valued: on/local/off, and have a separate > GUC for synchronous_replication_mode. It's a bit arbitrary that "on" > happens to mean remote fsync rather than remote write/receive. You mean the way it originally was? I would agree. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
fOn Wed, May 09, 2012 at 03:02:23PM +0100, Simon Riggs wrote: > On 9 May 2012 13:48, Robert Haas <robertmhaas@gmail.com> wrote: > > On Wed, May 9, 2012 at 7:29 AM, Bruce Momjian <bruce@momjian.us> wrote: > >> Let me point out that our documentation says nothing about it being > >> written to the kernel --- it just says "has received the commit record > >> of the transaction to memory." > > > > Maybe remote_receive would be better. If we're actually writing it > > back to the kernel before acknowledging the commit, that seems like an > > implementation defect more than anything else, since it does not - > > AFAICS - provide any additional, useful guarantee. > > It does provide an additional guarantee, but I accept you personally > may not find that useful. The guarantee is that if Postgres crashes, we don't lose any data, but not if the OS crashes (right?) because that isn't clear now. > If the docs don't describe it well enough, then we can change the docs. Well, we should make that clear in the docs then. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Wed, May 9, 2012 at 10:34 AM, Bruce Momjian <bruce@momjian.us> wrote: >> It does provide an additional guarantee, but I accept you personally >> may not find that useful. > > The guarantee is that if Postgres crashes, we don't lose any data, but > not if the OS crashes (right?) because that isn't clear now. True, point taken. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, May 9, 2012 at 10:02 AM, Simon Riggs <simon@2ndquadrant.com> wrote: >> Another thing I've been wondering is whether, perhaps, we ought to >> keep synchronous_commit tri-valued: on/local/off, and have a separate >> GUC for synchronous_replication_mode. It's a bit arbitrary that "on" >> happens to mean remote fsync rather than remote write/receive. > > You mean the way it originally was? I would agree. No. The original design for sync rep had synchronous_commit with only TWO values, on and off. I think the design we eventually settled on, with three values, was better, and I'm in favor of keeping it. However, there might be some virtue in separating the knob that controls whether we do sync rep from the knob that controls which kind of sync rep we do. I'm not sure. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, May 10, 2012 at 1:42 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, May 9, 2012 at 10:02 AM, Simon Riggs <simon@2ndquadrant.com> wrote: >>> Another thing I've been wondering is whether, perhaps, we ought to >>> keep synchronous_commit tri-valued: on/local/off, and have a separate >>> GUC for synchronous_replication_mode. It's a bit arbitrary that "on" >>> happens to mean remote fsync rather than remote write/receive. >> >> You mean the way it originally was? I would agree. > > No. The original design for sync rep had synchronous_commit with only > TWO values, on and off. I think the design we eventually settled on, > with three values, was better, and I'm in favor of keeping it. > However, there might be some virtue in separating the knob that > controls whether we do sync rep from the knob that controls which kind > of sync rep we do. I'm not sure. At least there is one problem in separating the knob: a user can set synchronous_commit to OFF and synchronous_replication_mode to ON, which makes the transaction wait long for replication. In this setting, because of asynchronous commit, WAL records cannot be written to the local disk immediately, and which means that WAL records cannot be sent immediately, so replication wait time would get long. AFAIR this is the reason why we merged two parameters into one before. Regards, -- Fujii Masao
> The naming is not arbitrary. -1 to changing it as suggested. > > It is as Aidan says, a state between receive and fsync, normally > referred to as write. > > Plus the word remote denotes it is on the standby, not the local master. > > So both words have specific meaning, and IMHO clear meaning. Clear to a postgres hacker, maybe. Not at *all* clear to our general users. The natural assumption is that "remote write" means that it's written to disk on the remote. Which is not what it means. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Wed, May 09, 2012 at 02:23:30PM -0700, Josh Berkus wrote: > > > The naming is not arbitrary. -1 to changing it as suggested. > > > > It is as Aidan says, a state between receive and fsync, normally > > referred to as write. > > > > Plus the word remote denotes it is on the standby, not the local master. > > > > So both words have specific meaning, and IMHO clear meaning. > > Clear to a postgres hacker, maybe. Not at *all* clear to our general users. > > The natural assumption is that "remote write" means that it's written to > disk on the remote. Which is not what it means. Right, and if we are wrapping beta tomorrow, it would be good for us to decide soon. We can always change it after beta, but sooner is better. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Wed, May 09, 2012 at 05:37:09PM -0400, Bruce Momjian wrote: > On Wed, May 09, 2012 at 02:23:30PM -0700, Josh Berkus wrote: > > > > > The naming is not arbitrary. -1 to changing it as suggested. > > > > > > It is as Aidan says, a state between receive and fsync, normally > > > referred to as write. > > > > > > Plus the word remote denotes it is on the standby, not the local master. > > > > > > So both words have specific meaning, and IMHO clear meaning. > > > > Clear to a postgres hacker, maybe. Not at *all* clear to our general users. > > > > The natural assumption is that "remote write" means that it's written to > > disk on the remote. Which is not what it means. > > Right, and if we are wrapping beta tomorrow, it would be good for us to > decide soon. We can always change it after beta, but sooner is better. And I will take the blame for brining it up so near beta --- I only realized when writing the release notes (which should be announced in a few hours). -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Thu, May 10, 2012 at 6:23 AM, Josh Berkus <josh@agliodbs.com> wrote: > >> The naming is not arbitrary. -1 to changing it as suggested. >> >> It is as Aidan says, a state between receive and fsync, normally >> referred to as write. >> >> Plus the word remote denotes it is on the standby, not the local master. >> >> So both words have specific meaning, and IMHO clear meaning. > > Clear to a postgres hacker, maybe. Not at *all* clear to our general users. If so, we should also rename the column "write_location" in pg_stat_replication? I named "remote_write (originally write)" after that column. And, in "remote_write", internally the master waits for replication until the wait LSN has reached write_location. Regards, -- Fujii Masao
> If so, we should also rename the column "write_location" in pg_stat_replication? Now that you bring it up, probably. Although not necessarily for 9.2. > I named "remote_write (originally write)" after that column. And, in > "remote_write", > internally the master waits for replication until the wait LSN has > reached write_location. Yeah, I get what it means. But I'm not the person I'm worried about being confused. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Wed, May 9, 2012 at 8:43 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, May 9, 2012 at 10:34 AM, Bruce Momjian <bruce@momjian.us> wrote: >>> It does provide an additional guarantee, but I accept you personally >>> may not find that useful. >> >> The guarantee is that if Postgres crashes, we don't lose any data, but >> not if the OS crashes (right?) because that isn't clear now. > > True, point taken. Back when synchronous_commit only had 2 values, I thought it should have had 3. The guarantee of losing transactions only on an OS crash, and not on a Postgres server crash, seems quite valuable (especially if you are playing around with custom extensions that might crash Postgres upon custom bugs). And the costs seem minimal. If the kernel is so constipated that even simple writes are blocking, it seems you are hosed regardless of where those writes are occurring. Cheers, Jeff
On Wed, May 09, 2012 at 05:02:57PM -0700, Josh Berkus wrote: > > > If so, we should also rename the column "write_location" in pg_stat_replication? > > Now that you bring it up, probably. Although not necessarily for 9.2. > > > I named "remote_write (originally write)" after that column. And, in > > "remote_write", > > internally the master waits for replication until the wait LSN has > > reached write_location. > > Yeah, I get what it means. But I'm not the person I'm worried about > being confused. So, are we shipping remote_write in beta1? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
> So, are we shipping remote_write in beta1? Given that it's thursday afternoon US time, and we haven't changed it yet, yes. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Thu, May 10, 2012 at 03:55:45PM -0700, Josh Berkus wrote: > > > So, are we shipping remote_write in beta1? > > Given that it's thursday afternoon US time, and we haven't changed it > yet, yes. Did we conclude just the docs are wrong and we do write (but not fsync) on the remote? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +