On Sun, Oct 1, 2017 at 10:03 AM, Thomas Munro
wrote:
>> I tried few more times, and I've got it two times from four attempts on a
>> fresh
>> installation (when all instances were on the same machine). But anyway I'll
>> try
>> to investigate, maybe it has something to do with my environment.
>>
>
On Sun, Oct 1, 2017 at 9:05 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>>> LOG: could not remove directory "pg_tblspc/47733/PG_10_201707211/47732":
>>> Directory not empty
>>> ...
>>
>> Hmm. The first error ("could not remove directory") could perhaps be
>> explained by temporary files from
> On 31 July 2017 at 07:49, Thomas Munro
wrote:
>> On Sun, Jul 30, 2017 at 7:07 AM, Dmitry Dolgov <9erthali...@gmail.com>
wrote:
>>
>> I looked through the code of `synchronous-replay-v1.patch` a bit and ran
a few
>> tests. I didn't manage to break anything, except one mysterious error
that I've
>
On Thu, Aug 10, 2017 at 2:02 PM, Thomas Munro
wrote:
> Rebased after conflicting commit 030273b7. Now using format-patch
> with a commit message to keep track of review/discussion history.
TAP test 006_logical_decoding.pl failed with that version. I had
missed some places that know how to decod
On Mon, Jul 31, 2017 at 5:49 PM, Thomas Munro
wrote:
> Here is a version to put it back.
Rebased after conflicting commit 030273b7. Now using format-patch
with a commit message to keep track of review/discussion history.
--
Thomas Munro
http://www.enterprisedb.com
synchronous-replay-v3.patc
On Sun, Jul 30, 2017 at 7:07 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> I looked through the code of `synchronous-replay-v1.patch` a bit and ran a
> few
> tests. I didn't manage to break anything, except one mysterious error that
> I've
> got only once on one of my replicas, but I couldn't
> On 12 July 2017 at 23:45, Thomas Munro
wrote:
> I renamed it to "synchronous replay", because "causal reads" seemed a bit
too
> arcane.
Hi
I looked through the code of `synchronous-replay-v1.patch` a bit and ran a
few
tests. I didn't manage to break anything, except one mysterious error that
I
On Sun, Jun 25, 2017 at 2:36 AM, Simon Riggs wrote:
> On 3 January 2017 at 01:43, Thomas Munro
> wrote:
>
>> Here is a new version of my "causal reads" patch (see the earlier
>> thread from the 9.6 development cycle[1]), which provides a way to
>> avoid stale reads when load balancing with strea
On Thu, Jul 13, 2017 at 2:51 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> Thank you. I started to play with it a little bit, since I think it's an
> interesting idea. And there are already few notes:
Thanks Dmitry.
> * I don't see a CF item for that, where is it?
https://commitfest.postgre
> On 23 June 2017 at 13:48, Thomas Munro
wrote:
>
> Apologies for the extended delay. Here is the rebased patch, now with a
> couple of improvements (see below).
Thank you. I started to play with it a little bit, since I think it's an
interesting idea. And there are already few notes:
* I don't
On Tue, Jun 27, 2017 at 12:20 PM, Thomas Munro
wrote:
> On Sun, Jun 25, 2017 at 2:36 AM, Simon Riggs wrote:
>> What I think we need is a joined up plan for load balancing, so that
>> we can understand how it will work. i.e. explain the whole use case
>> and how the solution works.
Here's a proof
On Sat, Jun 24, 2017 at 4:05 PM, Thomas Munro
wrote:
> On Fri, Jun 23, 2017 at 11:48 PM, Thomas Munro
> wrote:
>> Maybe it needs a better name.
>
> Ok, how about this: the feature could be called "synchronous replay".
> The new column in pg_stat_replication could be called sync_replay
> (like the
On Sun, Jun 25, 2017 at 2:36 AM, Simon Riggs wrote:
> I'm very happy that you are addressing this topic.
>
> I noticed you didn't put in links my earlier doubts about this
> specific scheme, though I can see doubts from myself and Heikki at
> least in the URLs. I maintain those doubts as to whethe
On 3 January 2017 at 01:43, Thomas Munro wrote:
> Here is a new version of my "causal reads" patch (see the earlier
> thread from the 9.6 development cycle[1]), which provides a way to
> avoid stale reads when load balancing with streaming replication.
I'm very happy that you are addressing this
On Fri, Jun 23, 2017 at 11:48 PM, Thomas Munro
wrote:
> Apply the patch after first applying a small bug fix for replication
> lag tracking[4]. Then:
That bug fix was committed, so now causal-reads-v17.patch can be
applied directly on top of master.
> 1. Set up some streaming replicas.
> 2. S
On Wed, May 24, 2017 at 3:58 PM, Thomas Munro
wrote:
>> On Mon, May 22, 2017 at 4:10 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>>> I'm wondering about status of this patch and how can I try it out?
>
> I ran into a problem while doing this, and it may take a couple more
> days to fix it sin
On Mon, May 22, 2017 at 6:32 AM, Thomas Munro
wrote:
> On Mon, May 22, 2017 at 4:10 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>> I'm wondering about status of this patch and how can I try it out?
>
> Hi Dmitry, thanks for your interest.
>
>>> On 3 January 2017 at 02:43, Thomas Munro
>>> wr
On Mon, May 22, 2017 at 4:10 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> I'm wondering about status of this patch and how can I try it out?
Hi Dmitry, thanks for your interest.
>> On 3 January 2017 at 02:43, Thomas Munro
>> wrote:
>> The replay lag tracking patch this depends on is in the
Hi
I'm wondering about status of this patch and how can I try it out?
> On 3 January 2017 at 02:43, Thomas Munro
wrote:
> The replay lag tracking patch this depends on is in the current commitfest
I assume you're talking about this patch [1] (at least it's the only thread
where I could find a `
On Fri, Jan 20, 2017 at 3:01 AM, Ants Aasma wrote:
> Yes there is a race even with all transactions having the same
> synchronization level. But nobody will mind if we some day fix that
> race. :)
We really should fix that!
> With different synchronization levels it is much trickier to
> fix as
On Thu, Jan 19, 2017 at 2:22 PM, Thomas Munro
wrote:
> On Thu, Jan 19, 2017 at 8:11 PM, Ants Aasma wrote:
>> On Tue, Jan 3, 2017 at 3:43 AM, Thomas Munro
>> wrote:
>>> Long term, I think it would be pretty cool if we could develop a set
>>> of features that give you distributed sequential consis
On Thu, Jan 19, 2017 at 8:11 PM, Ants Aasma wrote:
> On Tue, Jan 3, 2017 at 3:43 AM, Thomas Munro
> wrote:
>> Long term, I think it would be pretty cool if we could develop a set
>> of features that give you distributed sequential consistency on top of
>> streaming replication. Something like (t
On Tue, Jan 3, 2017 at 3:43 AM, Thomas Munro
wrote:
> Here is a new version of my "causal reads" patch (see the earlier
> thread from the 9.6 development cycle[1]), which provides a way to
> avoid stale reads when load balancing with streaming replication.
Thanks for working on this. It will let
Hi hackers,
Here is a new version of my "causal reads" patch (see the earlier
thread from the 9.6 development cycle[1]), which provides a way to
avoid stale reads when load balancing with streaming replication.
To try it out:
Set up a primary and some standbys, and put "causal_reads_timeout =
4s
24 matches
Mail list logo