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 1npUSG-0003Xc-6D for pgsql-hackers@arkaria.postgresql.org; Fri, 13 May 2022 12:31:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1npUSE-0006iZ-Q7 for pgsql-hackers@arkaria.postgresql.org; Fri, 13 May 2022 12:31:34 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1npUSD-0006iQ-W6 for pgsql-hackers@lists.postgresql.org; Fri, 13 May 2022 12:31:34 +0000 Received: from mail-oi1-x231.google.com ([2607:f8b0:4864:20::231]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1npUS6-0007fZ-EI for pgsql-hackers@postgresql.org; Fri, 13 May 2022 12:31:33 +0000 Received: by mail-oi1-x231.google.com with SMTP id j12so9961468oie.1 for ; Fri, 13 May 2022 05:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bHgKj/XLEuumDeBAvxOE+06aSvp5L21P5aSaai+LcKo=; b=NTrSgMMYGkWrXl8q3d6xaPUOkbDK9rswcKX5VCKz3i9/I2ZEwbJxjs05DdIu8Nj4VQ 9Q5srDmCrmYcQ2oJKFhHvdxlmKz51hgI8jcmZ7Lk7bvaAf2Jm1fc3iPc0Ep74VEbLALZ E6JX0N38AtF29ktIpZr6kvXte/tLIX1X7MRZtaEY4AVyPUzsA9eVfeZ8V+3aprYJaDkf E2CuFUBstljDJLNm+gANvbAkomjKLHHR1LQGSqB85kO64r6dLVMoNkGmZHIyTyRTb/co qkG7dj5ME2hOWm0ZzcJlJD+FX8/U/N631Rv10479DBjDHLHGq8lKcIpCFJn1le2562LC 9ozg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bHgKj/XLEuumDeBAvxOE+06aSvp5L21P5aSaai+LcKo=; b=x6SV2Vfuj8uMJ/CPxBn9vvcSx35cKP5sPOUys2ucA+cUqXhSGknR25M1pY8Dn1dUap 0RBkuqR1KJ/hiamcU4lVMR3pvw/yGWuXjlKnk+pRim1yTWGXv3Uvxcu7UzG+cE1iribV D8iZNIvgIqxe3EdIjCQXneVwZu9Sbta4nC7N3XjmBVqN1/EfS+a+cKE62FApjGjziYTE ldlUVkkvIsUaRI+b60u5vxsX1wm6PHyBbKAsdrEBmnnFiMS/82TVXvveYLubqYI/l8le 3V2xfJltbXjO0+Yey+knnt9Yt4F73b6VOTwkWENOK9ueaUu2cNGgezDSVCZ4ODw0SbDg 6usg== X-Gm-Message-State: AOAM532W00wrSWoG4zVlsjMBD8xteerhvy1k/JmaF+guPsejcjBTVUPI T+Cn3LrsQlEMxQDQFWJQN4usDzULgC3EKT1VxsiDxRA7lcydec9coOzuXwX3wAV+xJitqz3WeZm /0E3elvjPfAITPGfHg4E6FMw3mSs+hWyu2mVlwnA6XMa8tqQaQWxmIZpmgtso7c2EXRLnRMVCCi 710FGrp41xomjCvk+m1PPuU6idMSpRt1mmuWEAv5cJHI/w0y4o672FjqNjVsPm X-Google-Smtp-Source: ABdhPJwVuE3/A5D9EqxU/GFkrWMv7BZc9qbk+sUmkzLQaZNk1RSSWzbdtbZhdt6xaZLjF9uA/FDsLK3AcDj9elHncCY= X-Received: by 2002:a05:6808:f8e:b0:328:a601:a425 with SMTP id o14-20020a0568080f8e00b00328a601a425mr2297946oiw.253.1652445084321; Fri, 13 May 2022 05:31:24 -0700 (PDT) MIME-Version: 1.0 References: <20220512034010.4oqa76pasrulkw32@alap3.anarazel.de> In-Reply-To: From: Simon Riggs Date: Fri, 13 May 2022 13:31:13 +0100 Message-ID: Subject: Re: Comments on Custom RMGRs To: Jeff Davis Cc: Andres Freund , PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" X-CLOUD-SEC-AV-Info: enterprisedb,google_mail,monitor X-CLOUD-SEC-AV-Sent: true X-Gm-Spam: 0 X-Gm-Phishy: 0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, 13 May 2022 at 05:13, Jeff Davis wrote: > > On Thu, 2022-05-12 at 22:26 +0100, Simon Riggs wrote: > > I see multiple uses for the rm_checkpoint() point proposed and I've > > been asked multiple times for a checkpoint hook. > > Can you elaborate and/or link to a discussion? Those were conversations away from Hackers, but I'm happy to share. The first was a discussion about a data structure needed by BDR about 4 years ago. In the absence of a pluggable checkpoint, the solution was forced to use a normal table, which wasn't very satisfactory. The second was a more recent conversation with Mike Stonebraker, at the end of 2021.. He was very keen to remove the buffer manager entirely, which requires that we have a new smgr, which then needs new code to allow it to be written to disk at checkpoint time, which then requires some kind of pluggable code at checkpoint time. (Mike was also keen to remove WAL, but that's another story entirely!). The last use case was unlogged indexes, which need to be read from disk at startup or rebuilt after crash, which requires RmgrStartup to work both with and without InRedo=true. -- Simon Riggs http://www.EnterpriseDB.com/