Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iDbae-0004He-3p for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Sep 2019 21:46:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iDbac-0000nj-IW for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Sep 2019 21:46:18 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iDbac-0000X6-3w for pgsql-hackers@lists.postgresql.org; Thu, 26 Sep 2019 21:46:18 +0000 Received: from mail-wr1-x443.google.com ([2a00:1450:4864:20::443]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1iDbaV-0006FC-0p for pgsql-hackers@postgresql.org; Thu, 26 Sep 2019 21:46:16 +0000 Received: by mail-wr1-x443.google.com with SMTP id v8so444297wrt.2 for ; Thu, 26 Sep 2019 14:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Dh8FHqjfydKafLns5JrtBUi70oNzBClFpBcZ63nxa/g=; b=iixjbAjjC5Eok76NsWbWsVGrL5mykgzZnDyHc92treMeDcSNPuhgvk0cjuHhOF8cid vHfuIfIEL9oNNIlSerJWkcMYxgBNHNXOvZIM3cdeXf01s+6fBTJNp5AP0n5qSgm3HIPy V2w+yC7Nd/tT9YIdLgURmAOnS1Ouy8IRZJBy55+CZN9GwMbIFyKZteCu9nOH+y5yPJ8P JQGatCbQbaLnxZIG4Sy5103JWf6yks//BSR3bCOtmAJFIiwaI8MJBe1RouRi4SJTLI2w HXRexgrUJf4pA9jhqyamSX7nFeCRwIbKMkFjp5q7MYnp/ctmtBJ2/jeqTy/ZgprmZOYI Jp1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Dh8FHqjfydKafLns5JrtBUi70oNzBClFpBcZ63nxa/g=; b=XpMxYQLWWCLoD3z2hOS8szzjt88v3YWi9luRoPkLr2Cy7V6B3yvGmDj9JihZrOlD8S iXaHX2KNTnTnCYt3+g5jSFBQvj0VGoU+KruCPaiOF9q+/9/sYGgoax9+k4w9ZnRgspvI yXORHGuoSHoqciNUY9FZ5y+oIKO/h54bVsYKiCv7k9wLYAlpO51iAfFBphz1wgZ2m7Y6 T0kgYy0mc9Lc/I7p65rJ7G/9BhbQHNyIZXeLwj+FZLvwV07JbzycOLATijAXafHnlEZB lUzo7m5jFfAFgb6nwUPkd8/VnV8FUdij/Lg8yQwFKAl03nVgdTH+6dBdiJFImdWRbhLG Bgnw== X-Gm-Message-State: APjAAAXUx/J6d4Ix7pCf7jNQ397+mVGSA0a2K/ETcok84JdeddF6St+e Bz8Bjwwn4fYpomsatKRwO0k9yQ== X-Google-Smtp-Source: APXvYqzoH61cpSkCbkIozj/OB90Awn1PPtH87FgBvjz1TR1mnld1rv0JYv81A+krmAMuTK/j87cDLw== X-Received: by 2002:adf:ed04:: with SMTP id a4mr393507wro.77.1569534369365; Thu, 26 Sep 2019 14:46:09 -0700 (PDT) Received: from localhost (ip-86-49-253-183.net.upcbroadband.cz. [86.49.253.183]) by smtp.gmail.com with ESMTPSA id y186sm9718916wmb.41.2019.09.26.14.46.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Sep 2019 14:46:07 -0700 (PDT) Date: Thu, 26 Sep 2019 23:46:06 +0200 From: Tomas Vondra To: Alvaro Herrera Cc: Amit Kapila , PostgreSQL Hackers Subject: Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions Message-ID: <20190926214606.q6ad65r4umimc5w3@development> References: <20190926175845.pau2qocmlffd37qg@development> <20190926193359.GA16585@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20190926193359.GA16585@alvherre.pgsql> User-Agent: NeoMutt/20180716 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Thu, Sep 26, 2019 at 04:33:59PM -0300, Alvaro Herrera wrote: >On 2019-Sep-26, Tomas Vondra wrote: > >> Hi, >> >> Attached is an updated patch series, rebased on current master. It does >> fix one memory accounting bug in ReorderBufferToastReplace (the code was >> not properly updating the amount of memory). > >Cool. > >Can we aim to get 0001 pushed during this commitfest, or is that a lost >cause? > It's tempting. The patch has been in the queue for quite a bit of time, and I think it's solid (at least 0001). I'll address the comments from Peter's review about separating the GUC etc. and polish it a bit more. If I manage to do that by Monday, I'll consider pushing it. If anyone feels I shouldn't do that, let me know. The one open question pointed out by Amit is how the patch picks the trasction for eviction. My feeling is that's fine and if needed can be improved later if necessary, but I'll try to construct a worst case (max_connections xacts, each with 64 subxact) to verify. >The large new comment in reorderbuffer.c says that a transaction might >get spilled *or streamed*, but surely that second thing is not correct, >since before the subsequent patches it's not possible to stream >transactions that have not yet finished? > True. That's a residue of reordering the patch series repeatedly, I think. I'll fix that while polishing the patch. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services