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 1tzqtp-007YsI-Ok for pgsql-hackers@arkaria.postgresql.org; Wed, 02 Apr 2025 05:44:30 +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 1tzqtm-00A2hX-7a for pgsql-hackers@arkaria.postgresql.org; Wed, 02 Apr 2025 05:44:26 +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 1tzqtl-00A2fZ-LV for pgsql-hackers@lists.postgresql.org; Wed, 02 Apr 2025 05:44:25 +0000 Received: from mail-pl1-x632.google.com ([2607:f8b0:4864:20::632]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tzqtj-002Uka-0y for pgsql-hackers@lists.postgresql.org; Wed, 02 Apr 2025 05:44:24 +0000 Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-2295d78b45cso36645145ad.0 for ; Tue, 01 Apr 2025 22:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20230601.gappssmtp.com; s=20230601; t=1743572662; x=1744177462; darn=lists.postgresql.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=gLc0h27aBZL3NMjMUk8Pef9pmHdcgPMhxG110DgsIEg=; b=ciftSpTqpR9WWDiX24yHiDWZAJvm3VGwRGptK04Z4aVGTt93N/hKFIGADyr/sfUumU qveEZTGja2jwMtTAdoRIgn/s/VzIs32H57t3Du7qGBL4kqjh1pRqItyRl2xA/ddn3jpB yW0S7VBCOWqKZgICEFF06nNIUMRS47H9kJQjWosgro9qZhl+dvlpuvFc/x+DgJ30j4hE 3T0lyyNTgWqCxKbusGa1IQqmSUpmF2RXRqf6x+u0JytYpDfUrrwZLF8yhhxBBQiU7pSU SBkD/ZjLX44pGMUCNCDW87Tdr1rNT/MM9mVTll2F98/TstnbB/0hMNFvYRV4XaLHwrqi mDdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743572662; x=1744177462; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=gLc0h27aBZL3NMjMUk8Pef9pmHdcgPMhxG110DgsIEg=; b=XS8GVoAxbfg8vKXnyquxVYuz0Fiv98/RjE9NR76v121N7v9bfDtF/+qJbiCOn7fCcR JsaeDXa8ulhqj2CLciNB5VNXVAq3xexWfV8hGPYQYbAkbphvXjnSOjFrMLFSjI9MrEMk Hi86sS5Mg6e7OSjdSTRJUfqbq5yJlFPFtj3FAueIxKVXD76xr9B4RkXNvAm26WfycJFA DAv6q0G5SmFQQqBK72krth20tDXPwKk6r4QyfBj4DtiAwFP4LE8HGhO0IRe6BqrOJzU+ z+d7K7JFcVTT9uNZtvNbK6d/NhUxaahr4ki+N+WDcZ7CpY3Ye+3Rvv3rmq1XQc4XQ4r9 EgJA== X-Forwarded-Encrypted: i=1; AJvYcCXnrSwUT0ICfz3TIkXUpI4jP5Sh2vsm8sdU8yZJgPaImwaSx36yJXBvHz4E2m3wgYBtleDFGOm8klATB9hL@lists.postgresql.org X-Gm-Message-State: AOJu0YydRygT8mTE1WrF2pq3vGY+6Cvso5uYdn1PHijk2wTw70BXJslH RjKa/6M4jT6m44PVgffAD3D3+jcXuQKthyu8tv4jC2cE94BVZPnVyEISZDy5GA== X-Gm-Gg: ASbGncuUyqkmad7f+Nve5Nx//0M5YEG4xqwnzrN0H+84NQOJz4UBi40yy0IKMYOvilk KcHn+3vsPihBBR94g2u/5R12bPcBvQvxCQ9NnV6ghujTvtsfDWqpdEFiN1wji8qIhQmTcs4SeRR a7N/mDYdtG3lMkoVc0kmLb6p9R2RSS2L7KVXy8/5o2nxCh8vDuhm5FAXB9Sl1U6XuXK1t15sV3F tCzCC0Tc7gLCoNxzUadT2wZUuzZiYULeyjaUO2HZl8mE3tvpAbXaOgA7LsREVLxJbii3+rHFfns 9vNp53uPAbWnAoXEK/J5GSRYV38+QQAATc5N/bmDLQujoA8+aVEmb9KaCtCAy5oLP8aaDMR0w1s 2Bqv7+55r X-Google-Smtp-Source: AGHT+IG/VPPKt2sNLglQsNym3htpRIzIqrOR0PK8D1mWqYwaY2rHqBRATbJ6TTxUrhRtDjI1iT61SQ== X-Received: by 2002:a17:902:eb8d:b0:21f:564:80a4 with SMTP id d9443c01a7336-2292f9e5139mr226216375ad.33.1743572662157; Tue, 01 Apr 2025 22:44:22 -0700 (PDT) Received: from ?IPv6:2601:642:4c01:6dcc:592d:6cb:573d:ae6? ([2601:642:4c01:6dcc:592d:6cb:573d:ae6]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2291f1dd1cdsm99397175ad.172.2025.04.01.22.44.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Apr 2025 22:44:21 -0700 (PDT) Message-ID: Subject: Re: Statistics Import and Export From: Jeff Davis To: Nathan Bossart Cc: Corey Huinker , Robert Treat , Robert Haas , Andres Freund , Tom Lane , Michael Paquier , jian he , Bruce Momjian , Matthias van de Meent , Magnus Hagander , Stephen Frost , Ashutosh Bapat , Peter Smith , PostgreSQL Hackers , alvherre@alvh.no-ip.org Date: Tue, 01 Apr 2025 22:44:19 -0700 In-Reply-To: References: <88af35fe0ff24cc4e0700b841aa60a0865f11648.camel@j-davis.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu2 MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, 2025-04-01 at 22:21 -0500, Nathan Bossart wrote: > It certainly feels risky.=C2=A0 I was able to avoid executing the queries > twice > in all cases by saving the definition length in the TOC entry and > skipping > that many bytes the second time round. That feels like a better approach. > =C2=A0 That's simple enough, but it relies > on various assumptions such as fseeko() being available (IIUC the > file will > only be open for writing so we cannot fall back on fread()) and > WriteStr() > returning an accurate value (which I'm skeptical of because some > formats > compress this data).=C2=A0 But AFAICT custom format is the only format > that does > a second WriteToc() pass at the moment, and it only does so when > fseeko() > is usable. Even with those assumptions, I think it's much better than querying twice and assuming that the results are the same. > =C2=A0 Plus, custom format doesn't appear to compress anything written > via WriteStr(). If WriteStr() was doing compression, that would make the second WriteToc() pass to update the data offsets scary even in the existing code. > We might be able to improve this by inventing a new callback that > fails for > all formats except for custom with feesko() available.=C2=A0 That would a= t > least > ensure hard failures if these assumptions change.=C2=A0 That problably > wouldn't > be terribly invasive.=C2=A0 I'm curious what you think. That sounds fine, I'd say do that if it feels reasonable, and if the extra callbacks get too messy, we can just document the assumptions instead. >=20 > Hm.=C2=A0 One thing we could do is to send the TocEntry to the callback > and > verify that matches the one we were expecting to see next (as set by > a > previous call).=C2=A0 Does that sound like a strong enough check? Again, I'd just be practical here and do the check if it feels natural, and if not, improve the comments so that someone modifying the code would know where to look. Regards, Jeff Davis