Re: [HACKERS] Causal reads take II

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

Re: [HACKERS] Causal reads take II

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

Re: [HACKERS] Causal reads take II

> 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

Re: [HACKERS] Causal reads take II

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

Re: [HACKERS] Causal reads take II

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

Re: [HACKERS] Causal reads take II

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

Re: [HACKERS] Causal reads take II

> 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,

Re: [HACKERS] Causal reads take II

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

Re: [HACKERS] Causal reads take II

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?

Re: [HACKERS] Causal reads take II

> 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

Re: [HACKERS] Causal reads take II

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

Re: [HACKERS] Causal reads take II

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

Re: [HACKERS] Causal reads take II

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

Re: [HACKERS] Causal reads take II

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

Re: [HACKERS] Causal reads take II

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

Re: [HACKERS] Causal reads take II

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

Re: [HACKERS] Causal reads take II

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

Re: [HACKERS] Causal reads take II

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

Re: [HACKERS] Causal reads take II

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

Re: [HACKERS] Causal reads take II

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

Re: [HACKERS] Causal reads take II

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

Re: [HACKERS] Causal reads take II

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

Re: [HACKERS] Causal reads take II

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

[HACKERS] Causal reads take II

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 =