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 1tE9tW-005ZFy-RT for pgsql-hackers@arkaria.postgresql.org; Thu, 21 Nov 2024 16:19:03 +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 1tE9tV-00HEE6-Hy for pgsql-hackers@arkaria.postgresql.org; Thu, 21 Nov 2024 16:19:01 +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 1tE9t4-00H8fu-BH for pgsql-hackers@lists.postgresql.org; Thu, 21 Nov 2024 16:18:34 +0000 Received: from mail-ej1-x62e.google.com ([2a00:1450:4864:20::62e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tE9jq-0034oi-K9 for pgsql-hackers@lists.postgresql.org; Thu, 21 Nov 2024 16:09:04 +0000 Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-aa4cb5fcc06so202280666b.0 for ; Thu, 21 Nov 2024 08:09:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timescale.com; s=google; t=1732205341; x=1732810141; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=uyOG7xPgIk3q6r3o6ppsrRZ/QZE8OGYeQpWoFgzwkvw=; b=lzfG0MM8BythKk9tBmLPSmhKjq+Z61tZxwmiKYi2+iJEAMMiBOZVcMmiXeWZbarShg 8sKeVVxTFbTrikIzkmY66vWYr/WCEQxi2hivA12zUvJ0GuqcU7LEKy7BcwCMNO3ZLgt7 3V3/4SXeTDtgUyjgeXYjuNYLL4WzlbDIw/Yuy9S/LM3NdWAFNwS6nazO9uzoINcKpBdo +nSAroHSVRiV7XYyGfWN3gNBJ2nZm1e8rIS5S/3cZ8r98R9L2hlSiEFcTnbnVuJtH/Ap WPxGZ2pZFIP9dVVi6l00jidEc8pMvI7N7w/oDEh6LRJzQWf/G/QUpDBx1FfcYJRePYHi 96aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732205341; x=1732810141; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=uyOG7xPgIk3q6r3o6ppsrRZ/QZE8OGYeQpWoFgzwkvw=; b=KVWv3dgwmpvsWBxZxS96lRC/p9RuUY7Hb30K19qty9l84sEPUkobigNXiF2XmksMhn jinoH+RKBAcN27h0P+kPrBsSLN+ZJWKuP3i+eBAl25OX45QUzi8e/MQXoIRBO7xHlrxf 3eP2fglbguNjVfZKr9j7jf52fv74LtW3zyeqnG9vBaF1JG8bbwEyghV7B+bsiceMFu6O ny9eQWjv7UIxoTlSZBs/yRlQ03ZoenPu7IOQHpWeECX6yQVm8W3kLexVYm71n8A6CjT8 WxbpvgzrEPPV+ky/gta9074ZOEyx0wKD/7jFMGNs2CqorVq9HOa0JE5ms/7GsVNWTocp kDHQ== X-Gm-Message-State: AOJu0Yy+UxwyuseK/zhoo5etFI8VvX3vb1OJ9P3sCFGqvSYFcPoIp9ux 5lOSuDd/tmKRIuJlnbhdwVf+rAWQwJ/RQ7R+roYzUVzGiG8cVLm2aepWKMCUeIr+pFIGCULD0YY d2QXyRzplBJCHaQ9HuFuXVdJUf9Y0ZP9bWpALmH7X67JCY3e0Liamvg== X-Gm-Gg: ASbGncvcvIffjLamBqmHLd23u2Wg7ky6bBgMe3cLxgpetUHTeHq0kuGjsCWbTOi5Lom tSr/RCOCp7J1wHgxfG869dg552mFyeLE= X-Google-Smtp-Source: AGHT+IGJ1qYoFMIynlOT/nW4Q1EbV+JZZG1/RH5ZTZpVwggdiHlT5mdHaihSdM6VNh+by/otd6ZuolUkzZSxCO6T8Zw= X-Received: by 2002:a17:907:9623:b0:a99:5f2a:444d with SMTP id a640c23a62f3a-aa4dd74a0a7mr810584266b.56.1732205340382; Thu, 21 Nov 2024 08:09:00 -0800 (PST) MIME-Version: 1.0 From: =?UTF-8?Q?Erik_Nordstr=C3=B6m?= Date: Thu, 21 Nov 2024 17:08:49 +0100 Message-ID: Subject: Changed behavior in rewriteheap To: pgsql-hackers@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000fdf91706276e7b32" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000fdf91706276e7b32 Content-Type: text/plain; charset="UTF-8" Hello, I've noticed a change in behavior of the heap rewrite functionality in PostgreSQL 17, used by, e.g., CLUSTER. I've been experimenting with the functionality to implement a way to merge partitions in TimescaleDB. I am using table_relation_copy_for_cluster() to write the data of several tables to a single merged table, and then I do a heap swap on one of the original tables while dropping the others. So, if you have 3 partitions and want to merge them to one, then I write all three partitions to a temporary heap, swap the new heap on partition 1 and then drop partitions 2 and 3. Now, this approach worked fine for PostgreSQL 15 and 16, but 17 introduced some changes that altered the behavior so that I only see data from one of the partitions after merge (the last one written). The commit that I think is responsible is the following: https://github.com/postgres/postgres/commit/8af256524893987a3e534c6578dd60edfb782a77 Now, I realize that this is not a problem for PostgreSQL itself since the rewrite functionality isn't used for the purpose I am using it. To my defense, the rewrite code seems to imply that it should be possible to write more data to an existing heap according to this comment in begin_heap_rewrite: /* new_heap needn't be empty, just locked */. I've also tried recompiling PG17 with the rewriteheap.c file from PG16 and then it works again. I haven't yet been able to figure out exactly what is different but I will continue to try to narrow it down. In the meantime, maybe someone on the mailing list has some insight on what could be the issue and whether my approach is viable? Regards, Erik -- Database Architect, Timescale --000000000000fdf91706276e7b32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I've noticed a ch= ange in behavior of the heap rewrite functionality in PostgreSQL 17, used b= y, e.g., CLUSTER. I've been experimenting with the functionality to imp= lement a way to merge partitions in TimescaleDB. I am using table_relation_= copy_for_cluster() to write the data of several tables to a single merged t= able, and then I do a heap swap on one of the original tables while droppin= g the others. So, if you have 3 partitions and want to merge them to one, t= hen I write all three partitions to a temporary heap, swap the new heap on = partition 1 and then drop partitions 2 and 3.

Now,= this approach worked fine for PostgreSQL 15 and 16, but 17 introduced some= changes that altered the behavior so that I only see data from one of the = partitions after merge (the last one written).

The commit that I think is responsible is the following: https://github.com/postgres/postgres/commit/8af256524893987a3e534c6578= dd60edfb782a77

Now, I realize that this is not= a problem for PostgreSQL itself since the rewrite functionality isn't = used for the purpose I am using it. To my defense, the rewrite code seems t= o imply that it should be possible to write more data to an existing heap a= ccording to this comment in begin_heap_rewrite: /* new_heap n= eedn't be empty, just locked */.

I've a= lso tried recompiling PG17 with the rewriteheap.c file from PG16 and then i= t works again. I haven't yet been able to figure out exactly what is di= fferent but I will continue to try to narrow it down. In the meantime, mayb= e someone on the mailing list has some insight on what could be the issue a= nd whether my approach is viable?

Regards,
Erik

<= div>--
Database Architect, Timescale
--000000000000fdf91706276e7b32--