Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jWuWh-0006S2-9L for pgsql-hackers@arkaria.postgresql.org; Fri, 08 May 2020 04:22:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jWuWd-00013W-CV for pgsql-hackers@arkaria.postgresql.org; Fri, 08 May 2020 04:22:15 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jWuWc-00013M-SL for pgsql-hackers@lists.postgresql.org; Fri, 08 May 2020 04:22:15 +0000 Received: from mail-pg1-x543.google.com ([2607:f8b0:4864:20::543]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jWuWV-0006W3-CO for pgsql-hackers@postgresql.org; Fri, 08 May 2020 04:22:12 +0000 Received: by mail-pg1-x543.google.com with SMTP id q124so265908pgq.13 for ; Thu, 07 May 2020 21:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=INimsi1dHe82toyQCh1Km6XgkSLdf+qNIOawsLWDonU=; b=XhVHpsaQ0Prs51JXzqlVAF6sA2ofepGz5I4+FsUI98F6CUgjHUAZ4OpnpCKgkkxm4L JqHnW/5WYx16CaZRJKCHrfvZcp5QvL6v+FoNR1pbhkF9R6mvDvrq1Ce81yq8hzBVlkT2 SwXCkvVYHtnOZmc0JzfKeHb1yNm1AB3RC0jmg= 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=INimsi1dHe82toyQCh1Km6XgkSLdf+qNIOawsLWDonU=; b=Mh7Ej1uZ3XhePRyA3P0VG9V9qMI9Bw5NobN9DhrfyW48HrCv9fV/n3MB2IhLdxbj9M bRomRt/5zarus3igpNIe7RzJBt9rM+M5SiVFRnTgMyRBA/IomhkZFkNjx+hMQl6oZhQr +znhFHtWGMDgpS2Gjlo/aZSJ6pi6x5bSCuA5tDBTwbI0CKzectMkXpEkIuzptozRYrMt nBsGYDkIKxjADiE4PFidCvUb4N4j0x4v4UF0o8iBqeQ8210i8xUs4K7foCu8CNy0XB6Q tZBB8PQBwSTlkk5FpF5bTu9y1Au7qeSLykj5KBIEAnSOOXozyChUzj8I1DO5mNJEIa4a bqCw== X-Gm-Message-State: AGi0PuYR527P/P84pT+rdCf1rmHw0JTV27Uf8kC+tIARwiy5j43XNiEY a1848r+ppGIft7wCKd8ElilVBw== X-Google-Smtp-Source: APiQypLBTVGtzUaT7MuWx59q/8jGP6ij/D4cxmd9s6VhMG7rgI0Qz1GZchpb3MZxaxm+Mali4WENkg== X-Received: by 2002:a62:1814:: with SMTP id 20mr796043pfy.63.1588911725863; Thu, 07 May 2020 21:22:05 -0700 (PDT) Received: from rfd.leadboat.com (108-233-125-46.lightspeed.sntcca.sbcglobal.net. [108.233.125.46]) by smtp.gmail.com with ESMTPSA id 189sm347377pfd.55.2020.05.07.21.22.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2020 21:22:04 -0700 (PDT) Date: Thu, 7 May 2020 21:22:02 -0700 From: Noah Misch To: Bruce Momjian Cc: PostgreSQL-development Subject: Re: PG 13 release notes, first draft Message-ID: <20200508042202.GA563018@rfd.leadboat.com> References: <20200505031600.GB21752@momjian.us> <20200506063910.GA515983@rfd.leadboat.com> <20200506234025.GC3649@momjian.us> <20200507052057.GB541283@rfd.leadboat.com> <20200507133834.GJ3649@momjian.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200507133834.GJ3649@momjian.us> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Thu, May 07, 2020 at 09:38:34AM -0400, Bruce Momjian wrote: > On Wed, May 6, 2020 at 10:20:57PM -0700, Noah Misch wrote: > > On Wed, May 06, 2020 at 07:40:25PM -0400, Bruce Momjian wrote: > > > On Tue, May 5, 2020 at 11:39:10PM -0700, Noah Misch wrote: > > > > On Mon, May 04, 2020 at 11:16:00PM -0400, Bruce Momjian wrote: > > > > > Allow skipping of WAL for new tables and indexes if wal_level is 'minimal' (Noah Misch) > > > > > > > > Kyotaro Horiguchi authored that one. (I committed it.) The commit message > > > > noted characteristics, some of which may deserve mention in the notes: > > > > > > Fixed. > > > > I don't see that change pushed (but it's not urgent). > > I got stuck on Amit's partition items and my head couldn't process any > more, so I went to bed, and just committed it now. I was afraid to have > pending stuff uncommitted, but I am also hesitant to do a commit for > each change. Got it, +1 for batching such changes. > > > > - Crash recovery was losing tuples written via COPY TO. This fixes the bug. > > > > > > This was not backpatched? > > > > Right. > > Oh. So you are saying we could lose COPY data on a crash, even after a > commit. That seems bad. Can you show me the commit info? I can't find > it. commit c6b9204 Author: Noah Misch AuthorDate: Sat Apr 4 12:25:34 2020 -0700 Commit: Noah Misch CommitDate: Sat Apr 4 12:25:34 2020 -0700 Skip WAL for new relfilenodes, under wal_level=minimal. Until now, only selected bulk operations (e.g. COPY) did this. If a given relfilenode received both a WAL-skipping COPY and a WAL-logged operation (e.g. INSERT), recovery could lose tuples from the COPY. See src/backend/access/transam/README section "Skipping WAL for New RelFileNode" for the new coding rules. Maintainers of table access methods should examine that section. To maintain data durability, just before commit, we choose between an fsync of the relfilenode and copying its contents to WAL. A new GUC, wal_skip_threshold, guides that choice. If this change slows a workload that creates small, permanent relfilenodes under wal_level=minimal, try adjusting wal_skip_threshold. Users setting a timeout on COMMIT may need to adjust that timeout, and log_min_duration_statement analysis will reflect time consumption moving to COMMIT from commands like COPY. Internally, this requires a reliable determination of whether RollbackAndReleaseCurrentSubTransaction() would unlink a relation's current relfilenode. Introduce rd_firstRelfilenodeSubid. Amend the specification of rd_createSubid such that the field is zero when a new rel has an old rd_node. Make relcache.c retain entries for certain dropped relations until end of transaction. Bump XLOG_PAGE_MAGIC, since this introduces XLOG_GIST_ASSIGN_LSN. Future servers accept older WAL, so this bump is discretionary. Kyotaro Horiguchi, reviewed (in earlier, similar versions) by Robert Haas. Heikki Linnakangas and Michael Paquier implemented earlier designs that materially clarified the problem. Reviewed, in earlier designs, by Andrew Dunstan, Andres Freund, Alvaro Herrera, Tom Lane, Fujii Masao, and Simon Riggs. Reported by Martijn van Oosterhout. Discussion: https://postgr.es/m/20150702220524.GA9392@svana.org