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 1uwMR0-000f3a-3C for pgsql-general@arkaria.postgresql.org; Wed, 10 Sep 2025 15:08:34 +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 1uwMQx-001nN6-1e for pgsql-general@arkaria.postgresql.org; Wed, 10 Sep 2025 15:08:31 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uwMQw-001nMx-Mt for pgsql-general@lists.postgresql.org; Wed, 10 Sep 2025 15:08:31 +0000 Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uwMQt-0001b1-0o for pgsql-general@postgresql.org; Wed, 10 Sep 2025 15:08:30 +0000 Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-621b8b0893bso8977784a12.2 for ; Wed, 10 Sep 2025 08:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757516908; x=1758121708; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0TcGoM6AlcG1fwopz7PdsEtm8WiHTkqeHYctImqWwN4=; b=M2ngHIygLCfaPFL0asRPWg/BN4nAYnf4x26+Ul/x/ngBYdQiEiz6WGWNJC9EwDHtsV hZBpR8mmrU0cK4l9vm1U7mXFu5VhJ3SEFnIm/N+86+3ZR0uUnvDFlm0lPFXD4P3eU8ic 5pYHliQUILZP6yHYne0xg2kOy2j67B20NnzakOMwxua6JP1Bci8A64toypLsTPCvA5c3 g1eR4EaW+wNKRhluxplFcpv8AG0/G9sW5w/6/sf8QlRrtwSD8vLS9uIXupH2WPNHWIF7 UIxZzsx5ehJrmfRBE2sqns7/hTbPy67d9el82EiAtq7NOzK/jiIxuolcI+PM5calhZYR 5MiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757516908; x=1758121708; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0TcGoM6AlcG1fwopz7PdsEtm8WiHTkqeHYctImqWwN4=; b=fPqwLDSHbAbiKdnUbBn6B92PKplq8rRaTFEXMSmVY77k62IRE5jcDOFjI5uWwWohq7 LY048PIYZyh0kbVnztEj3HCH41dDGLbDuMW/4XoSUv59IpQKxKwzkVKYGxL34k+KJzeE Ty66UUWrQ5CDxZzMwOL6NHWg+5Z4DTDMu06RkpERH5pZ60sN0B/J39ip6BBPSqhPdm9v tLhymln6klNnwfBfNncltgcWNcx/Kx6EAbxiRq5vGFL0jLKa2dNDCEI4rHeT+95DPJzO sQwMZM8I5ZBKoXSwigR+EKTh3bIAgXR1G54xWfoQ+Vxew03llFcRaw3STlAed6f/m/G9 j4eA== X-Forwarded-Encrypted: i=1; AJvYcCWH63IdnlCHjGyb8THA/1NiM967Hvefi5xIisDDbD7wzW0LmmhONbHKgoXZc6KBEFif3l282T8VI+FcoXHM@postgresql.org X-Gm-Message-State: AOJu0YySbuCrn7V5Bd1JfU+ZLiqv8pN9bX22F0GqCs5YdI8C6Xpgc2/Z u/rPst+nirEvBhc3XdMRo2rzmre3A2RC5aPGDeydG3xkLmZ1/HV0o7GFhjzI9ZWWWSF9N4ACi/+ nEqNQmBqPeW9WWOdNJWScKUJw7AqLJJc= X-Gm-Gg: ASbGncsybxg+1buMuEjixgtgZ1Djrsia/O7bk83Jzh6uymgaYDSQFF13ZHaoO7q4w3G CpX6j5EFDfY4BAhHZiHlzNNJVGp56se1fcQzmwZuerwM4zbxVQC/ssy/HI+rXxlkO1tA9TEh5X8 pzCpx3syyQ2h/WIs5OJEAk4mt2+ST7TMT9DliZgakD8fVguoW2L8l0jeWeaNYxO2Hvkm2L/uq7z MxJvqA= X-Google-Smtp-Source: AGHT+IEGKwsKFtFRA0BLejA4iVb4AvTt0aAXhuDT2hAo5rQoscnfW4EcdDk6H8v7TYYnanN2jF0bdHjbe16CYbjAVZI= X-Received: by 2002:a05:6402:2681:b0:62a:a4f0:7e4f with SMTP id 4fb4d7f45d1cf-62aa4ffcbbfmr8896369a12.29.1757516907912; Wed, 10 Sep 2025 08:08:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ellen Allhatatlan Date: Wed, 10 Sep 2025 16:08:15 +0100 X-Gm-Features: AS18NWA89uJUaV_M6wYS_w-unaKQ5QytQvROX7p5nkb2x7Vqsv8S7RbCYHKDjbQ Message-ID: Subject: Re: MVCC and all that... To: Adrian Klaver Cc: Justin , Merlin Moncure , pgsql-general Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > Though I would like to know what happened in mid 2010?: > https://github.com/FirebirdSQL/firebird/graphs/contributors Yes, indeed, WTF? I'm not a member of the FB Illuminati - so I can't say! > > OK again. I'm just wondering if the single file per database isn't a > > fundamental architectural flaw in itself? AIUI, you could have > > mulitple files (back in 32-bit land) "chained" - but (again AIUI) the > > same table could be spread over x files - all "intermingled"... weird. > What are you referring to above? I'm sorry - the single file flaw I was referring to occurs in FB and has nothing to do with PG. FB dbs are single files - or were - 32 bit - up to 2GB and then there was another file. I don't know what happens for 64 bit - (note to self - find out)! So, you have table X - it has 2M rows (say, 0.5 GB) in the first file (along with all the other tables). The 2GB limit is hit, more data is added. 0.7 GB is added to table X - these records go into a new database file - the table is split in two - you have 2 "extents" of 2GB with X split 0.5 - in extent1, 0.7 in extent2. All mixed up with other tables as well! That was the architectural flaw to which I was referring. Nothing to do with PG, backups or anything like that - again, apologies for any confusion - my phraseology wasn't the best! And I should have put what I wrote elsewhere anyway! -- El!