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 1ltdu8-0007Kb-IZ for pgsql-hackers@arkaria.postgresql.org; Wed, 16 Jun 2021 22:21:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ltdu7-0002GI-HO for pgsql-hackers@arkaria.postgresql.org; Wed, 16 Jun 2021 22:20:59 +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 1ltdu7-0002G9-9Q for pgsql-hackers@lists.postgresql.org; Wed, 16 Jun 2021 22:20:59 +0000 Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ltdu4-0004J1-LI for pgsql-hackers@lists.postgresql.org; Wed, 16 Jun 2021 22:20:58 +0000 Received: by mail-ed1-x535.google.com with SMTP id z12so1211578edc.1 for ; Wed, 16 Jun 2021 15:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=LAkyE2WCpCcPaLHb6YJrCNOQotLfiEXnbOZ71a4E7Yc=; b=pS8Zomgct7WoOOw2tx/zpJZnUqB/qu4DfnCywRVTxTlKOjHzf8LpsCH/ePH3nLw4kU Y298oK8wHk2k8c8BWEOmleSwPTFuqZYXBO+Wznl7gfKlRU8jCorjSmnrzOvBvFCpnkRZ uIybqeW/obZZo8ib6QBw8/2IMKBT6ROwIFF+SoBDEldFtiF8nHhFhqCuMpzN04jOhtJV i8dE3UHbHXbrPaZyHtgTcTe0wJWsGt6ZE0LIZLkpe4ex81mw0VI0WkTlTSeFcZCJ5K3T UIvH3uhrZ/l51/IQzBk+nyl8PjuglMCfy9XTV+yojyFZxm1oj5SsWlqOn0GzivxW9lPX NOIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=LAkyE2WCpCcPaLHb6YJrCNOQotLfiEXnbOZ71a4E7Yc=; b=tTpSAuWDbHCTzqgeGofZgJXBmgRQ2GZrpzgIe1+d5TL0KpUvpWo/Xze+halj8W10Rn sKCx9buRlQk8zAcgnGFZ+g2NU0ruC7YHxRESIUiq7pOYG8LeBUE7++XC2HBCZdyNUds+ hxiMGTYdPNBiXB2k+1fGRYbqTa6nsZbFIT3/IqXkJsryqlkri1cWJNq3D2IPFhZm3frl pwITmbHh44rzs+dG3rkKU8YRvVR4MzyZm7IEGyoqzO48ZmCTiDRi6Zt7OOkqjQtvb+dN Issfhf2Zio6A1sEz8wSARSZGpgUmOqIvoUqOoxgWzyqSxAXDcefTFcKGyCQgNHWteHQi QoVQ== X-Gm-Message-State: AOAM533TPVWTmUAXy/Siml9tixVgruhkGDmKZbVwIQi2cHB2eJ4dsr9C x0h0kunQ1DtkW/EdKtgxM0a3xX0GDLbYY6qCGMLP3RG40WJGS9fV3CAlaA8j1EC3H05GRW+m79f 5ncG4eKoM/JFU8dTWGOTXbeVuir/Q14TJPeY1G92t2j/4dzw5n3VhEVTT/yM+Xowalsi2AXDtA8 CCz07/19nEoJMy5d9U3Iw0/0swA66l3nxJ9vdAZssBjt2n2HLHYhcad0I/vVCrw4UgJk6gx+5JW mWCZa4wB6M1Vrr799+d9xySuPeEacxFTtE3hCMRNZTp4vpAtjpJBwO1 X-Google-Smtp-Source: ABdhPJz38V1Xxyhjdu29/Lnn3DipxQc5xf9xcB6Ww8t53fGl40edubH65Aawwmll9sqZ0Xd3p7pxiw== X-Received: by 2002:a05:6402:1644:: with SMTP id s4mr2386403edx.190.1623882054827; Wed, 16 Jun 2021 15:20:54 -0700 (PDT) Received: from [10.137.0.18] (ip-86-49-254-183.net.upcbroadband.cz. [86.49.254.183]) by smtp.gmail.com with ESMTPSA id jo13sm2397552ejb.91.2021.06.16.15.20.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Jun 2021 15:20:54 -0700 (PDT) Subject: Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints To: Andrew Dunstan , Heikki Linnakangas , Dilip Kumar , PostgreSQL Hackers References: From: Tomas Vondra Message-ID: <20943f82-4a21-d7b0-3336-ca0872062d84@enterprisedb.com> Date: Thu, 17 Jun 2021 00:20:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 6/15/21 3:31 PM, Andrew Dunstan wrote: > > On 6/15/21 8:04 AM, Heikki Linnakangas wrote: >> >> Yeah, WAL-logging the contents of the source database would certainly >> be less weird than the current system. As Julien also pointed out, the >> question is, are there people using on "CREATE DATABASE foo TEMPLATE >> bar" to copy a large source database, on the premise that it's fast >> because it skips WAL-logging? > > > I'm 100% certain there are. It's not even a niche case. > > >> >> In principle, we could have both mechanisms, and use the new >> WAL-logged system if the database is small, and the old system with >> checkpoints if it's large. But I don't like idea of having to maintain >> both. >> >> > > Rather than use size, I'd be inclined to say use this if the source > database is marked as a template, and use the copydir approach for > anything that isn't. > I think we should be asking what is the benefit of that use case, and perhaps try addressing that without having to maintain two entirely different ways to do CREATE DATABASE. It's not like we're sure the current code is 100% reliable in various corner cases, I doubt having two separate approaches will improve the situation :-/ I can see three reasons why people want to skip the WAL logging: 1) it's faster, because there's no CPU and I/O for building the WAL I wonder if some optimization / batching could help with (1), as suggested by Andres elsewhere in this thread. 2) it saves the amount of WAL (could matter with large template databases and WAL archiving, etc.) We can't really do much about this - we need to log all the data. But the batching from (1) might help a bit too, I guess. 3) saves the amount of WAL that needs to be copied to standby, so that there's no increase of replication lag, etc. particularly when the network link has limited bandwidth I think this is a more general issue - some operations that may generate a lot of WAL, and we generally assume it's better to do that rather than hold exclusive locks for long time. But maybe we could have some throttling, to limit the amount of WAL per second, similarly to what we have to plain vacuum. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company