Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qj3pE-0098G6-4J for pgsql-hackers@arkaria.postgresql.org; Wed, 20 Sep 2023 20:29:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qj3pC-002rTS-O8 for pgsql-hackers@arkaria.postgresql.org; Wed, 20 Sep 2023 20:29:30 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qj3pC-002rSo-DM for pgsql-hackers@lists.postgresql.org; Wed, 20 Sep 2023 20:29:30 +0000 Received: from mail-ot1-x331.google.com ([2607:f8b0:4864:20::331]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qj3p7-005gYQ-KX for pgsql-hackers@lists.postgresql.org; Wed, 20 Sep 2023 20:29:26 +0000 Received: by mail-ot1-x331.google.com with SMTP id 46e09a7af769-6c0a42a469dso166111a34.2 for ; Wed, 20 Sep 2023 13:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695241765; x=1695846565; darn=lists.postgresql.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=HKV5kiqvjqSMDoqLvWHoMvBHSqUohc1voy+hKxDSwVE=; b=Js9b+70mQc3vqUQ8cxrRjm+6MBKsnfu/qrcZxETMVBWmpQPzZRhRb3d2MxcOWyrgJg eurJ2T+KbKdGfZ8ur6LEBMzJPKwo9eJoMDbY/5PqbmCX2CIhrAipTGwuLUs2iElIfCFw 9xiQmGvB9Jzh/QV3Fl01Q3pefSsshTdyxS69Y9OtyYr9B7K7lXF7Xv7ZneL4Q3c2nY60 hEGRpilA27KTgUE+4og666EIyV8ysRbaT+8BuUvEOlNpHp3O+u0vKQTPKx2ZHdjn5olH E+bl2u+0b5SN1Ev1KIAzU8W6+38g9Z3eSEHYgAUSLpZeNq02GxIEpzpetcQrTngLiET2 CwqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695241765; x=1695846565; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=HKV5kiqvjqSMDoqLvWHoMvBHSqUohc1voy+hKxDSwVE=; b=Km9WDEi67+IEDhI4Qs0EVTQFNqX3IdeKYUZ9170N8FdWB65/QIdirJZuYmN9aVLMwS RpXwzbUocTPeKHnIPJdEY8tmt91onF5hRCpP0I2hTW43MXi+k7jCyr7DteVQk1CD6pYx HGbGWwUUvrFbzFr3UoriwZW5Bd/91MvfPxN/hYLe5Mh8IAfrdX6SC8bKQnjuXPL+X3ET vg7O9CJnHtITXqv4ROQMfQ/ckMHFd4e5lWR1044Y3xu+3aT1sJEF9sl8u5EJEXH+to4Z a1hzrnOZrgl8MSaqBwMul1CKzCC8dGQ2ySR+gooFlbQSqWpj2tF5B5x9diSR6HXIrctV 6S5w== X-Gm-Message-State: AOJu0YwHFUahJwK6bLZUTvpeqFR3cHPb/+D2jj8S1IrlZ0w42/yTtYtF MZ9iFm02hUsEhwiQrQYZ0wab2J7HHzE= X-Google-Smtp-Source: AGHT+IEAnvf03tBujGUgbUIeefv1vHdmYh1hNDnK1J6wrnGbiJZbBWY4n84orEeJ5/u07alr+V/cbA== X-Received: by 2002:a9d:4d10:0:b0:6b7:5086:2f59 with SMTP id n16-20020a9d4d10000000b006b750862f59mr3359138otf.23.1695241764865; Wed, 20 Sep 2023 13:29:24 -0700 (PDT) Received: from nathanxps13 ([2600:1700:48f8:340f:c587:3a48:c1bf:c35]) by smtp.gmail.com with ESMTPSA id c9-20020a9d6849000000b006b94aba1f0bsm19351oto.43.2023.09.20.13.29.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Sep 2023 13:29:24 -0700 (PDT) Date: Wed, 20 Sep 2023 13:29:22 -0700 From: Nathan Bossart To: Pierre Ducroquet Cc: pgsql-hackers@lists.postgresql.org Subject: Re: Improvements in pg_dump/pg_restore toc format and performances Message-ID: <20230920202922.GA3054233@nathanxps13> References: <2656000.KRxA6XjA2N@peanuts2> <20230918215247.GA2661288@nathanxps13> <20230918215442.GB2661288@nathanxps13> <2575263.Lt9SDvczpP@peanuts2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2575263.Lt9SDvczpP@peanuts2> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Sep 19, 2023 at 12:15:55PM +0200, Pierre Ducroquet wrote: > Attached updated patches fix this regression, I'm sorry I missed that. Thanks for the new patches. 0001 and 0002 look reasonable to me. This is a nitpick, but we might want to use atooid() in 0002, which is just shorthand for the strtoul() call you are using. > - WriteStr(AH, NULL); /* Terminate List */ > + WriteInt(AH, -1); /* Terminate List */ I think we need to be cautious about using WriteInt and ReadInt here. OIDs are unsigned, so we probably want to use InvalidOid (0) instead. > + if (AH->version >= K_VERS_1_16) > { > - depSize *= 2; > - deps = (DumpId *) pg_realloc(deps, sizeof(DumpId) * depSize); > + depId = ReadInt(AH); > + if (depId == -1) > + break; /* end of list */ > + if (depIdx >= depSize) > + { > + depSize *= 2; > + deps = (DumpId *) pg_realloc(deps, sizeof(DumpId) * depSize); > + } > + deps[depIdx] = depId; > + } > + else > + { > + tmp = ReadStr(AH); > + if (!tmp) > + break; /* end of list */ > + if (depIdx >= depSize) > + { > + depSize *= 2; > + deps = (DumpId *) pg_realloc(deps, sizeof(DumpId) * depSize); > + } > + deps[depIdx] = strtoul(tmp, NULL, 10); > + free(tmp); > } I would suggest making the resizing logic common. if (AH->version >= K_VERS_1_16) { depId = ReadInt(AH); if (depId == InvalidOid) break; /* end of list */ } else { tmp = ReadStr(AH); if (!tmp) break; /* end of list */ depId = strtoul(tmp, NULL, 10); free(tmp); } if (depIdx >= depSize) { depSize *= 2; deps = (DumpId *) pg_realloc(deps, sizeof(DumpId) * depSize); } deps[depIdx] = depId; Also, can we make depId more locally scoped? I have yet to look into 0004 still. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com