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
> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
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. A
On Wed, May 9, 2012 at 8:43 AM, Robert Haas wrote:
> On Wed, May 9, 2012 at 10:34 AM, Bruce Momjian 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
> 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 unti
On Thu, May 10, 2012 at 6:23 AM, 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.
>>
>>
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 wr
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 lo
> 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 meanin
On Thu, May 10, 2012 at 1:42 AM, Robert Haas wrote:
> On Wed, May 9, 2012 at 10:02 AM, Simon Riggs 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'
On Wed, May 9, 2012 at 10:02 AM, Simon Riggs 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 fsyn
On Wed, May 9, 2012 at 10:34 AM, Bruce Momjian 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
fOn Wed, May 09, 2012 at 03:02:23PM +0100, Simon Riggs wrote:
> On 9 May 2012 13:48, Robert Haas wrote:
> > On Wed, May 9, 2012 at 7:29 AM, Bruce Momjian wrote:
> >> Let me point out that our documentation says nothing about it being
> >> written to the kernel --- it just says "has received the c
On 9 May 2012 13:48, Robert Haas wrote:
> On Wed, May 9, 2012 at 7:29 AM, Bruce Momjian 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_receiv
On Wed, May 9, 2012 at 7:29 AM, Bruce Momjian 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
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
On 9 May 2012 03:52, Bruce Momjian 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 wrote:
>>
>> >> And then, I could envision (if it continues down this road):
>> >> off
>> >> local
>> >> remote_accept
>> >> remote_
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 wrote:
>
> >> And then, I could envision (if it continues down this road):
> >> off
> >> local
> >> remote_accept
> >> remote_write
> >> remote_sync
> >> remote_apply (impli
On Tue, May 8, 2012 at 10:09 PM, Bruce Momjian 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
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 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
On Tue, May 8, 2012 at 9:13 PM, Bruce Momjian 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?
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 http://momjian.us
EnterpriseDB
22 matches
Mail list logo
