On Fri, 2011-02-18 at 00:48 +, Simon Riggs wrote:
> Complete but rough hack, for comments, but nothing surprising.
This is an implicit requirement from our earlier agreed API, so its
blocking further work on Sync Rep.
I'm looking to commit this in about 3-4 hours unless I get comments.
--
On Fri, 2011-01-21 at 14:45 +0200, Heikki Linnakangas wrote:
> * The UI differs from what was agreed on here:
> http://archives.postgresql.org/message-id/4d1dcf5a.7070...@enterprisedb.com.
Patch to add server_name parameter, plus mechanism to send info from
standby to master. While doing that, r
On Wed, Feb 16, 2011 at 12:34 PM, Heikki Linnakangas
wrote:
> On 16.02.2011 19:29, Robert Haas wrote:
>>
>> Actually, on further reflection, I'm not even sure why we bother with
>> the fsync. It seems like a useful safeguard but I'm not seeing how we
>> can get to that point without having fsync'
On 16.02.2011 19:29, Robert Haas wrote:
Actually, on further reflection, I'm not even sure why we bother with
the fsync. It seems like a useful safeguard but I'm not seeing how we
can get to that point without having fsync'd everything anyway. Am I
missing something?
WalRcvDie() is called on
On Wed, Feb 16, 2011 at 11:32 AM, Simon Riggs wrote:
> On Wed, 2011-02-16 at 17:40 +0200, Heikki Linnakangas wrote:
>> On 16.02.2011 17:36, Simon Riggs wrote:
>> > On Tue, 2011-02-15 at 12:08 -0500, Robert Haas wrote:
>> >> On Mon, Feb 14, 2011 at 12:25 AM, Fujii Masao
>> >> wrote:
>> >>> On Fri
On Wed, 2011-02-16 at 17:40 +0200, Heikki Linnakangas wrote:
> On 16.02.2011 17:36, Simon Riggs wrote:
> > On Tue, 2011-02-15 at 12:08 -0500, Robert Haas wrote:
> >> On Mon, Feb 14, 2011 at 12:25 AM, Fujii Masao
> >> wrote:
> >>> On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
> >>> wrote:
On 16.02.2011 17:36, Simon Riggs wrote:
On Tue, 2011-02-15 at 12:08 -0500, Robert Haas wrote:
On Mon, Feb 14, 2011 at 12:25 AM, Fujii Masao wrote:
On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
wrote:
I added a XLogWalRcvSendReply() call into XLogWalRcvFlush() so that it also
sends a s
On Tue, 2011-02-15 at 12:08 -0500, Robert Haas wrote:
> On Mon, Feb 14, 2011 at 12:25 AM, Fujii Masao wrote:
> > On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
> > wrote:
> >> I added a XLogWalRcvSendReply() call into XLogWalRcvFlush() so that it also
> >> sends a status update every time th
On Tue, Feb 15, 2011 at 10:13 PM, Fujii Masao wrote:
> On Wed, Feb 16, 2011 at 2:08 AM, Robert Haas wrote:
>> On Mon, Feb 14, 2011 at 12:25 AM, Fujii Masao wrote:
>>> On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
>>> wrote:
I added a XLogWalRcvSendReply() call into XLogWalRcvFlush()
On Wed, Feb 16, 2011 at 2:08 AM, Robert Haas wrote:
> On Mon, Feb 14, 2011 at 12:25 AM, Fujii Masao wrote:
>> On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
>> wrote:
>>> I added a XLogWalRcvSendReply() call into XLogWalRcvFlush() so that it also
>>> sends a status update every time the WAL
On Mon, Feb 14, 2011 at 12:25 AM, Fujii Masao wrote:
> On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
> wrote:
>> I added a XLogWalRcvSendReply() call into XLogWalRcvFlush() so that it also
>> sends a status update every time the WAL is flushed. If the walreceiver is
>> busy receiving and fl
On Tue, Feb 15, 2011 at 1:11 AM, Fujii Masao wrote:
> On Mon, Feb 14, 2011 at 2:08 PM, Fujii Masao wrote:
>> On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
>> wrote:
>>> I committed the patch with those changes, and some minor comment tweaks and
>>> other kibitzing.
>
> I have another comme
On Mon, Feb 14, 2011 at 12:08 AM, Fujii Masao wrote:
> On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
> wrote:
>> I committed the patch with those changes, and some minor comment tweaks and
>> other kibitzing.
>
> + * 'd' means a standby reply wrapped in a COPY BOTH packet.
> +
On Tue, 2011-02-15 at 01:45 -0500, Jaime Casanova wrote:
> On Sat, Jan 15, 2011 at 4:40 PM, Simon Riggs wrote:
> >
> > Here's the latest patch for sync rep.
> >
>
> I was looking at this code and found something in SyncRepWaitOnQueue
> we declare a timeout variable that is a long and another that
On Sat, Jan 15, 2011 at 4:40 PM, Simon Riggs wrote:
>
> Here's the latest patch for sync rep.
>
I was looking at this code and found something in SyncRepWaitOnQueue
we declare a timeout variable that is a long and another that is a
boolean (this last one in the else part of the "if
(!IsOnSyncRepQ
On Mon, Feb 14, 2011 at 2:08 PM, Fujii Masao wrote:
> On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
> wrote:
>> I committed the patch with those changes, and some minor comment tweaks and
>> other kibitzing.
I have another comment:
The description of wal_receiver_status_interval is in "18
On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
wrote:
> I added a XLogWalRcvSendReply() call into XLogWalRcvFlush() so that it also
> sends a status update every time the WAL is flushed. If the walreceiver is
> busy receiving and flushing, that would happen once per WAL segment, which
> seems
On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
wrote:
> I committed the patch with those changes, and some minor comment tweaks and
> other kibitzing.
+* 'd' means a standby reply wrapped in a COPY BOTH packet.
+*/
Typo: s/COPY BOTH/CopyData
+ msgtype = pq_getmsg
On 08.02.2011 20:53, Robert Haas wrote:
That having been said, there is at least one part of this patch which
looks to be in pretty good shape and seems independently useful
regardless of what happens to the rest of it, and that is the code
that sends replies from the standby back to the primary.
On Wed, Feb 9, 2011 at 5:25 AM, Robert Haas wrote:
> On Tue, Feb 8, 2011 at 2:34 PM, Magnus Hagander wrote:
>> I also agree with the general idea of trying to break it into smaller
>> parts - even if they only provide small parts each on it's own. That
>> also makes it easier to get an overview o
On Wed, Feb 9, 2011 at 2:01 PM, David E. Wheeler wrote:
> ha ha! Alas, I'm completely overcommitted at this point. Been having a hard
> time making time for PGXN. I've been tracking the extension stuff closely,
> though, as you can imagine.
It's a common problem, and of course none of us are in
On Feb 9, 2011, at 10:56 AM, Robert Haas wrote:
>> “Listen up, bitches! I'm tired of Tom and me having to do all the work. All
>> of you who submitted patches need to review some other patches! If you
>> haven't submitted a review for someone else's patch by commitfest end, your
>> patches will
On Wed, Feb 9, 2011 at 1:32 PM, David E. Wheeler wrote:
> On Feb 9, 2011, at 10:29 AM, Robert Haas wrote:
>>> Frankly, I think you should surrender some of those 14 and cajole some
>>> other folks to take on more.
>>
>> Happily... only trouble is, I suck at cajoling. Even my begging is
>> disti
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Feb 9, 2011 at 1:09 PM, David E. Wheeler wrote:
> > Frankly, I think you should surrender some of those 14 and cajole some
> > other folks to take on more.
>
> Happily... only trouble is, I suck at cajoling. Even my begging is
> distinctly
On Feb 9, 2011, at 10:29 AM, Robert Haas wrote:
>> Frankly, I think you should surrender some of those 14 and cajole some other
>> folks to take on more.
>
> Happily... only trouble is, I suck at cajoling. Even my begging is
> distinctly sub-par.
>
> Plase?
Try this:
“Listen up, bit
On Wed, Feb 9, 2011 at 1:09 PM, David E. Wheeler wrote:
> Frankly, I think you should surrender some of those 14 and cajole some other
> folks to take on more.
Happily... only trouble is, I suck at cajoling. Even my begging is
distinctly sub-par.
Plase?
--
Robert Haas
EnterpriseDB:
On Feb 9, 2011, at 9:20 AM, Robert Haas wrote:
> There are certainly some patches in this CommitFest that need more
> attention than that, and that probably need the attention of a senior
> community member. Jeff's range types patch and Alvaro's key lock
> patch are two of those. And I would be
On Wed, Feb 9, 2011 at 7:53 AM, Peter Eisentraut wrote:
> Moreover, under the current process, it is apparent that reviewing is
> the bottleneck. More code gets written than gets reviewed. By
> insisting on the current schedule, we would just push the growing review
> backlog ahead of ourselves.
On Wed, Feb 9, 2011 at 9:42 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 02/09/2011 07:53 AM, Peter Eisentraut wrote:
>>> The previous three commit fests contained about 50 patches each and
>>> lasted one month each. The current commit fest contains about 100
>>> patches, so it shouldn't b
Andrew Dunstan writes:
> On 02/09/2011 07:53 AM, Peter Eisentraut wrote:
>> The previous three commit fests contained about 50 patches each and
>> lasted one month each. The current commit fest contains about 100
>> patches, so it shouldn't be surprising that it will take about 2 months
>> to get
On 02/09/2011 07:53 AM, Peter Eisentraut wrote:
On mån, 2011-02-07 at 12:55 -0500, Robert Haas wrote:
On Mon, Feb 7, 2011 at 12:43 PM, Tom Lane wrote:
Robert Haas writes:
... Well, the current CommitFest ends in one week, ...
Really? I thought the idea for the last CF of a development cy
On mån, 2011-02-07 at 12:55 -0500, Robert Haas wrote:
> On Mon, Feb 7, 2011 at 12:43 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> ... Well, the current CommitFest ends in one week, ...
> >
> > Really? I thought the idea for the last CF of a development cycle was
> > that it kept going till w
On Wed, Feb 9, 2011 at 3:53 AM, Robert Haas wrote:
> That having been said, there is at least one part of this patch which
> looks to be in pretty good shape and seems independently useful
> regardless of what happens to the rest of it, and that is the code
> that sends replies from the standby ba
On Tue, 2011-02-08 at 13:53 -0500, Robert Haas wrote:
> That having been said, there is at least one part of this patch which
> looks to be in pretty good shape and seems independently useful
> regardless of what happens to the rest of it, and that is the code
> that sends replies from the standby
On Tue, Feb 8, 2011 at 2:34 PM, Magnus Hagander wrote:
> I would usually not worry about the bandwidth, really, I'd be more
> worried about potentially increasing latency somewhere.
The time to read and write the socket doesn't seem like it should be
significant, unless the network buffers fill u
On Tue, Feb 8, 2011 at 19:53, Robert Haas wrote:
> On Mon, Feb 7, 2011 at 1:20 PM, Robert Haas wrote:
>> On Sat, Jan 15, 2011 at 4:40 PM, Simon Riggs wrote:
>>> Here's the latest patch for sync rep.
>>
>> Here is a rebased version of this patch which applies to head of the
>> master branch. I h
On Mon, Feb 7, 2011 at 1:20 PM, Robert Haas wrote:
> On Sat, Jan 15, 2011 at 4:40 PM, Simon Riggs wrote:
>> Here's the latest patch for sync rep.
>
> Here is a rebased version of this patch which applies to head of the
> master branch. I haven't tested it yet beyond making sure that it
> compile
On Mon, Feb 7, 2011 at 5:16 PM, Simon Riggs wrote:
> On Mon, 2011-02-07 at 11:50 -0800, Josh Berkus wrote:
>> >> I just spoke to my manager at EnterpriseDB and he cleared my schedule
>> >> for the next two days to work on this. So I'll go hack on this now.
>> >> I haven't read the patch yet so I
On Mon, 2011-02-07 at 11:50 -0800, Josh Berkus wrote:
> >> I just spoke to my manager at EnterpriseDB and he cleared my schedule
> >> for the next two days to work on this. So I'll go hack on this now.
> >> I haven't read the patch yet so I don't know for sure how quite I'll
> >> be able to get up
On Mon, 2011-02-07 at 15:25 -0500, Robert Haas wrote:
> I would certainly appreciate it if
> everyone could at least credit me with acting in good faith.
I think you are, if that helps.
--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training a
dp...@pgadmin.org (Dave Page) writes:
> On Mon, Feb 7, 2011 at 6:55 PM, Robert Haas wrote:
>> On Mon, Feb 7, 2011 at 12:43 PM, Tom Lane wrote:
>>> Robert Haas writes:
... Well, the current CommitFest ends in one week, ...
>>>
>>> Really? I thought the idea for the last CF of a development
On Mon, Feb 7, 2011 at 9:46 PM, Robert Haas wrote:
> On Mon, Feb 7, 2011 at 3:34 PM, Dave Page wrote:
>> On Mon, Feb 7, 2011 at 9:25 PM, Robert Haas wrote:
>>> You're moving the bar. It DOES say that the CommitFest will end on
>>> February 15th. Now, if we want to have a discussion about chang
On Mon, Feb 7, 2011 at 3:34 PM, Dave Page wrote:
> On Mon, Feb 7, 2011 at 9:25 PM, Robert Haas wrote:
>> You're moving the bar. It DOES say that the CommitFest will end on
>> February 15th. Now, if we want to have a discussion about changing
>> that, let's have that discussion (perhaps on a thr
On Mon, Feb 7, 2011 at 3:14 PM, Dimitri Fontaine wrote:
> Robert Haas writes:
>> I'm not trying to bypass compromising, and I don't know what makes you
>> think otherwise. I am trying to ensure that the CommitFest wraps up
>
> Well, I'm too tired to allow myself posting such comments, sorry to h
On Mon, Feb 7, 2011 at 9:25 PM, Robert Haas wrote:
> You're moving the bar. It DOES say that the CommitFest will end on
> February 15th. Now, if we want to have a discussion about changing
> that, let's have that discussion (perhaps on a thread where the
> subject has something to do with the to
On Mon, 2011-02-07 at 12:24 -0800, Josh Berkus wrote:
> +1.
>
> I, for one, would vote against extending beta if Sync Rep isn't ready
> yet. There's plenty of other "big features" in 9.1, and Sync Rep will
> benefit from having additional development time given the number of
> major spec points
On Mon, Feb 7, 2011 at 3:06 PM, Dave Page wrote:
>>> Rejecting stuff because we haven't gotten round to dealing with it in
>>> such a short period of time is a damn good way to limit the number of
>>> contributions we get. I don't believe we've agreed at any point that
>>> the last commitfest shou
On 2/7/11 11:41 AM, Robert Haas wrote:
> However, I don't want to prolong
> the CommitFest indefinitely in the face of patches that the authors
> are not actively working on or can't finish in the time available, or
> where there is no consensus that the proposed change is what we want.
> I believe
Robert Haas writes:
> I'm not trying to bypass compromising, and I don't know what makes you
> think otherwise. I am trying to ensure that the CommitFest wraps up
Well, I'm too tired to allow myself posting such comments, sorry to have
left the previous mail through. More than one commit fest s
On Mon, Feb 7, 2011 at 8:59 PM, Robert Haas wrote:
> On Mon, Feb 7, 2011 at 2:56 PM, Dave Page wrote:
>> On Mon, Feb 7, 2011 at 6:55 PM, Robert Haas wrote:
>>> On Mon, Feb 7, 2011 at 12:43 PM, Tom Lane wrote:
Robert Haas writes:
> ... Well, the current CommitFest ends in one week, ...
Robert Haas wrote:
> Dave Page wrote:
>> Robert Haas wrote:
>>> Tom Lane wrote:
Robert Haas writes:
> ... Well, the current CommitFest ends in one week, ...
Really? I thought the idea for the last CF of a development
cycle was that it kept going till we'd dealt with ev
On Mon, Feb 7, 2011 at 6:55 PM, Robert Haas wrote:
> On Mon, Feb 7, 2011 at 12:43 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> ... Well, the current CommitFest ends in one week, ...
>>
>> Really? I thought the idea for the last CF of a development cycle was
>> that it kept going till we'd dea
On Mon, Feb 7, 2011 at 2:56 PM, Dave Page wrote:
> On Mon, Feb 7, 2011 at 6:55 PM, Robert Haas wrote:
>> On Mon, Feb 7, 2011 at 12:43 PM, Tom Lane wrote:
>>> Robert Haas writes:
... Well, the current CommitFest ends in one week, ...
>>>
>>> Really? I thought the idea for the last CF of a
>> I just spoke to my manager at EnterpriseDB and he cleared my schedule
>> for the next two days to work on this. So I'll go hack on this now.
>> I haven't read the patch yet so I don't know for sure how quite I'll
>> be able to get up to speed on it, so if someone who is more familiar
>> with t
On Mon, Feb 7, 2011 at 2:09 PM, Dimitri Fontaine wrote:
> Robert Haas writes:
>> done in the time available is another thing entirely. I do NOT want
>> to still be working on the items for this CommitFest in June - that's
>> about when I'd like to be releasing beta3.
>
> Except that's not how we
On Mon, 2011-02-07 at 17:59 +, Simon Riggs wrote:
> On Mon, 2011-02-07 at 12:39 -0500, Robert Haas wrote:
>
> > I just spoke to my manager at EnterpriseDB and he cleared my schedule
> > for the next two days to work on this. So I'll go hack on this now.
> > I haven't read the patch yet so I d
Robert Haas writes:
> done in the time available is another thing entirely. I do NOT want
> to still be working on the items for this CommitFest in June - that's
> about when I'd like to be releasing beta3.
Except that's not how we work here. You want to change that with
respect to the release
On Mon, Feb 7, 2011 at 12:59 PM, Simon Riggs wrote:
> On Mon, 2011-02-07 at 12:39 -0500, Robert Haas wrote:
>
>> I just spoke to my manager at EnterpriseDB and he cleared my schedule
>> for the next two days to work on this. So I'll go hack on this now.
>> I haven't read the patch yet so I don't
On Mon, Feb 7, 2011 at 12:43 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... Well, the current CommitFest ends in one week, ...
>
> Really? I thought the idea for the last CF of a development cycle was
> that it kept going till we'd dealt with everything. Arbitrarily
> rejecting stuff we haven
On Mon, 2011-02-07 at 12:39 -0500, Robert Haas wrote:
> I just spoke to my manager at EnterpriseDB and he cleared my schedule
> for the next two days to work on this. So I'll go hack on this now.
> I haven't read the patch yet so I don't know for sure how quite I'll
> be able to get up to speed o
Robert Haas writes:
> ... Well, the current CommitFest ends in one week, ...
Really? I thought the idea for the last CF of a development cycle was
that it kept going till we'd dealt with everything. Arbitrarily
rejecting stuff we haven't dealt with doesn't seem fair.
re
On Mon, Feb 7, 2011 at 12:28 PM, Robert Haas wrote:
> On Mon, Feb 7, 2011 at 11:33 AM, Simon Riggs wrote:
>> On Mon, 2011-02-07 at 09:55 -0500, Robert Haas wrote:
>>> On Sun, Jan 30, 2011 at 11:44 AM, Robert Haas wrote:
>>> > Time's running short - do you have an updated patch?
>>>
>>> This patc
On Mon, Feb 7, 2011 at 11:33 AM, Simon Riggs wrote:
> On Mon, 2011-02-07 at 09:55 -0500, Robert Haas wrote:
>> On Sun, Jan 30, 2011 at 11:44 AM, Robert Haas wrote:
>> > Time's running short - do you have an updated patch?
>>
>> This patch hasn't been updated in more than three weeks. I assume
>>
On Mon, 2011-02-07 at 09:55 -0500, Robert Haas wrote:
> On Sun, Jan 30, 2011 at 11:44 AM, Robert Haas wrote:
> > Time's running short - do you have an updated patch?
>
> This patch hasn't been updated in more than three weeks. I assume
> this should now be marked Returned with Feedback, and we'l
Robert Haas wrote:
> On Sun, Jan 30, 2011 at 11:44 AM, Robert Haas wrote:
> > Time's running short - do you have an updated patch?
>
> This patch hasn't been updated in more than three weeks. I assume
> this should now be marked Returned with Feedback, and we'll revisit
> synchronous replication
On Sun, Jan 30, 2011 at 11:44 AM, Robert Haas wrote:
> Time's running short - do you have an updated patch?
This patch hasn't been updated in more than three weeks. I assume
this should now be marked Returned with Feedback, and we'll revisit
synchronous replication for 9.2?
--
Robert Haas
Ente
On Sat, Jan 22, 2011 at 8:31 AM, Simon Riggs wrote:
> On Fri, 2011-01-21 at 13:32 -0500, Robert Haas wrote:
>
>> One idea might be to wait both before and after commit. If
>> allow_standalone_primary is off, and a commit is attempted, we check
>> whether there's a slave connected, and if not, wai
On Fri, 2011-01-21 at 13:32 -0500, Robert Haas wrote:
> One idea might be to wait both before and after commit. If
> allow_standalone_primary is off, and a commit is attempted, we check
> whether there's a slave connected, and if not, wait for one to
> connect. Then, we write and sync the commit
On Fri, Jan 21, 2011 at 1:59 PM, Aidan Van Dyk wrote:
> Yup. And I'm OK with that. In my case, it would be much better to
> have a few quick failures, which can complete automatically a few
> seconds later then to have a big buildup of transactions to re-verify
> by hand upon starting manual pro
On Fri, Jan 21, 2011 at 1:32 PM, Robert Haas wrote:
>> Again, I'm trying to stop "forward progress" as soon as possible when
>> a sync slave isn't replicating. And I'ld like clients to fail with
>> errors sooner (hopefully they get to the commit point) rather than
>> accumulate the WAL synced to
On Fri, Jan 21, 2011 at 1:09 PM, Aidan Van Dyk wrote:
> On Fri, Jan 21, 2011 at 1:03 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Fri, Jan 21, 2011 at 12:23 PM, Aidan Van Dyk wrote:
When no sync slave is connected, yes, I want to stop things hard.
>>
>>> What you're proposing is to fa
On Fri, Jan 21, 2011 at 1:03 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jan 21, 2011 at 12:23 PM, Aidan Van Dyk wrote:
>>> When no sync slave is connected, yes, I want to stop things hard.
>
>> What you're proposing is to fail things earlier than absolutely
>> necessary (when they try
Robert Haas writes:
> On Fri, Jan 21, 2011 at 12:23 PM, Aidan Van Dyk wrote:
>> When no sync slave is connected, yes, I want to stop things hard.
> What you're proposing is to fail things earlier than absolutely
> necessary (when they try to XLOG, rather than at commit) but still
> later than wh
On Fri, Jan 21, 2011 at 12:23 PM, Aidan Van Dyk wrote:
> On Fri, Jan 21, 2011 at 11:59 AM, Simon Riggs wrote:
>
>> We all think our own proposed options are the only reasonable thing, but
>> that helps us not at all in moving forwards. I've put much time into
>> delivering options many other peop
On Fri, Jan 21, 2011 at 11:59 AM, Simon Riggs wrote:
> We all think our own proposed options are the only reasonable thing, but
> that helps us not at all in moving forwards. I've put much time into
> delivering options many other people want, so there is a range of
> function. I think we should
On Fri, 2011-01-21 at 14:34 +0100, Magnus Hagander wrote:
> On Fri, Jan 21, 2011 at 14:24, Simon Riggs wrote:
> > On Fri, 2011-01-21 at 14:45 +0200, Heikki Linnakangas wrote:
> >> * it seems like overkill to not let clients to even connect when
> >> allow_standalone_primary=off and no synchronous
On Fri, 2011-01-21 at 17:33 +0200, Heikki Linnakangas wrote:
> On 21.01.2011 15:24, Simon Riggs wrote:
> > On Fri, 2011-01-21 at 14:45 +0200, Heikki Linnakangas wrote:
> >> * it seems like overkill to not let clients to even connect when
> >> allow_standalone_primary=off and no synchronous standbys
On Fri, Jan 21, 2011 at 10:33 AM, Heikki Linnakangas
wrote:
> It's also possible that most of your transactions in fact do "set
> synchronous_replication=off", and only a few actually do synchronous
> replication. It would be pretty bad to not allow connections in that case.
> And what if you want
On 21.01.2011 15:24, Simon Riggs wrote:
On Fri, 2011-01-21 at 14:45 +0200, Heikki Linnakangas wrote:
* it seems like overkill to not let clients to even connect when
allow_standalone_primary=off and no synchronous standbys are available.
What if you just want to run a read-only query?
That's w
On Fri, Jan 21, 2011 at 14:24, Simon Riggs wrote:
> On Fri, 2011-01-21 at 14:45 +0200, Heikki Linnakangas wrote:
>> * it seems like overkill to not let clients to even connect when
>> allow_standalone_primary=off and no synchronous standbys are available.
>> What if you just want to run a read-onl
On Fri, Jan 21, 2011 at 7:45 AM, Heikki Linnakangas
wrote:
> * it seems like overkill to not let clients to even connect when
> allow_standalone_primary=off and no synchronous standbys are available. What
> if you just want to run a read-only query?
For what it's worth, +1.
--
Robert Haas
Enter
On Fri, 2011-01-21 at 14:45 +0200, Heikki Linnakangas wrote:
> (grr, I wrote this on Monday already, but just found it in my drafts
> folder, unsent)
No worries, thanks for commenting.
> Thanks! Some quick observations after first read-through:
>
> * The docs for synchronous_replication still c
(grr, I wrote this on Monday already, but just found it in my drafts
folder, unsent)
On 15.01.2011 23:40, Simon Riggs wrote:
Here's the latest patch for sync rep.
From here, I will be developing the patch further on public git
repository towards commit. My expectation is that commit is at l
On Sat, Jan 15, 2011 at 22:40, Simon Riggs wrote:
>
> Here's the latest patch for sync rep.
>
> >From here, I will be developing the patch further on public git
> repository towards commit. My expectation is that commit is at least 2
That's great. Just one tiny detail - which repository and which
84 matches
Mail list logo
