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 1nADrM-00060X-ES for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Jan 2022 16:30:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nADrL-0007P5-6E for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Jan 2022 16:30:55 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nADrK-0007Ov-Eu for pgsql-hackers@lists.postgresql.org; Wed, 19 Jan 2022 16:30:54 +0000 Received: from mail-qk1-x732.google.com ([2607:f8b0:4864:20::732]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nADrG-0002qE-Io for pgsql-hackers@postgresql.org; Wed, 19 Jan 2022 16:30:54 +0000 Received: by mail-qk1-x732.google.com with SMTP id j85so3280951qke.2 for ; Wed, 19 Jan 2022 08:30:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=g/2CvfZf6HUKsCesqvenW16INn+9D4gYyk0i4a5IhSQ=; b=VSfT/jf6fl3XBv2eBXITgmzFLO3PPzx7OuLR59xQTlNYe8C1CpGgkn6uO0mM8gF0Ae iEJ6DhBLHmpU6Iw3ry4pEzD4N50IHADyumR5Qdp+SlpB8IzNYtOA/5jSSx905amFhQTd QMrSNG9lVt2UqL4tx4peeLVqkIWvLyvti5+z2i/Wf+EjjynwXc3KqcYi+MoGrvGOfJP5 AETUxMFQBZa07XkctgX/H+18j9VdwBLs8Ja8wPlaWF6SsoutxQi7BSI6tQgOXH9ILBdR g3k0Av3IhLLdXfa8sm758XOMMrfDrYe6qTNoFd8N3Gs1ov9jCwFrn1A3MATASWwxcqBr K8lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=g/2CvfZf6HUKsCesqvenW16INn+9D4gYyk0i4a5IhSQ=; b=k3GCVMT994WNRPb3gGA6UYFuUOZi9/pry74Jy988M1gbwTcSo6+7l0SF+L7eB+PuDp mx9f0bnQ4jppZz24rrI2NVJWALPZLvuEVwjvAQiSALMbtXBNm22FywtPWQme5dnS4Nck GHnBNIujgxcI65rbQNldXn2mhMv0dPTLQkzLh/ixmNoG9mU+//9OB8Czp3RRaENGYm3m mhXnh0gEuocRd+Xw9xKYW1gqquOxDF8QFS9rOKm9BoK4+vFHYr5UwNw/vevJthMH9KpG cRtZNGeTzTVUX7XtabBRY1+cAFR32P5tefjKpUBwhCBeFFpbFfVn9lZ7zc6LJe76slGi x+dg== X-Gm-Message-State: AOAM5309Y1MgpGK06pY/C7qBf7VY+CjrOOZN349o+EHxSTMhq0iULPJl 9URUXXODLAArUYMUw72EQ+V4dZPltlQxUBhmizXIvV8eYLr81TSra294P1w9wguSuJCKQHW5wJr nIQGB9jaW9d3ieFpR6+VQ1maB6wQCrjKpvLRZpzh4x5Rt20Llk3osBovlvJsC2df2CXX24ZSFW0 WF+Ffdl6AgKe56M9Wtb+2S34g3fLYdhRjxbjVJeX7kJmC+WQnPYrM2JQ3D/iWOvabaAX5JJAnF7 jj8CZcLPdZLlEiGpqe04CRZi7GwHKCn4yoqLA== X-Google-Smtp-Source: ABdhPJwl7pQHSk586N3Q2NdoBISPL5AwZQKAo5oSJDMgGWXyt2GroJgWTQWZ/BTPrG2ZtiIW0W9Teg== X-Received: by 2002:a37:8945:: with SMTP id l66mr22139746qkd.776.1642609848021; Wed, 19 Jan 2022 08:30:48 -0800 (PST) Received: from localhost.localdomain ([45.113.251.168]) by smtp.gmail.com with ESMTPSA id d10sm154920qkn.1.2022.01.19.08.30.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Jan 2022 08:30:46 -0800 (PST) Subject: Re: refactoring basebackup.c To: Jeevan Ladhe Cc: Robert Haas , Dmitry Dolgov <9erthalion6@gmail.com>, Mark Dilger , "pgsql-hackers@postgresql.org" References: <20211115162641.dmo6l32fklh64gnw@localhost> From: tushar Message-ID: <6c3f1558-1e56-9946-78a2-c59340da1dbf@enterprisedb.com> Date: Wed, 19 Jan 2022 22:00:42 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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 1/18/22 8:12 PM, Jeevan Ladhe wrote: > Similar to LZ4 server-side compression, I have also tried to add a ZSTD > server-side compression in the attached patch. Thanks Jeevan. while testing found one scenario where the server is getting crash while performing pg_basebackup against server-compression=zstd for a huge data second time Steps to reproduce --PG sources ( apply v11-0001,v11-0001,v9-0001,v9-0002 , configure --with-lz4,--with-zstd, make/install, initdb, start server) --insert huge data (./pgbench -i -s 2000 postgres) --restart the server (./pg_ctl -D data restart) --pg_basebackup ( ./pg_basebackup  -t server:/tmp/yc1 --server-compression=zstd -R  -Xnone -n -N -l 'ccc' --no-estimate-size -v) --insert huge data (./pgbench -i -s 1000 postgres) --restart the server (./pg_ctl -D data restart) --run pg_basebackup again (./pg_basebackup  -t server:/tmp/yc11 --server-compression=zstd -v  -Xnone ) [edb@centos7tushar bin]$ ./pg_basebackup  -t server:/tmp/yc11 --server-compression=zstd -v  -Xnone pg_basebackup: initiating base backup, waiting for checkpoint to complete 2022-01-19 21:23:26.508 IST [30219] LOG:  checkpoint starting: force wait 2022-01-19 21:23:26.608 IST [30219] LOG:  checkpoint complete: wrote 0 buffers (0.0%); 0 WAL file(s) added, 1 removed, 0 recycled; write=0.001 s, sync=0.001 s, total=0.101 s; sync files=0, longest=0.000 s, average=0.000 s; distance=16369 kB, estimate=16369 kB pg_basebackup: checkpoint completed TRAP: FailedAssertion("len > 0 && len <= sink->bbs_buffer_length", File: "../../../src/include/replication/basebackup_sink.h", Line: 208, PID: 30226) postgres: walsender edb [local] sending backup "pg_basebackup base backup"(ExceptionalCondition+0x7a)[0x94ceca] postgres: walsender edb [local] sending backup "pg_basebackup base backup"[0x7b9a08] postgres: walsender edb [local] sending backup "pg_basebackup base backup"[0x7b9be2] postgres: walsender edb [local] sending backup "pg_basebackup base backup"[0x7b5b30] postgres: walsender edb [local] sending backup "pg_basebackup base backup"(SendBaseBackup+0x563)[0x7b7053] postgres: walsender edb [local] sending backup "pg_basebackup base backup"(exec_replication_command+0x961)[0x7c9a41] postgres: walsender edb [local] sending backup "pg_basebackup base backup"(PostgresMain+0x92f)[0x81ca3f] postgres: walsender edb [local] sending backup "pg_basebackup base backup"[0x48e430] postgres: walsender edb [local] sending backup "pg_basebackup base backup"(PostmasterMain+0xfd2)[0x785702] postgres: walsender edb [local] sending backup "pg_basebackup base backup"(main+0x1c6)[0x48fb96] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f63642c8555] postgres: walsender edb [local] sending backup "pg_basebackup base backup"[0x48feb5] pg_basebackup: error: could not read COPY data: server closed the connection unexpectedly     This probably means the server terminated abnormally     before or while processing the request. 2022-01-19 21:25:34.485 IST [30205] LOG:  server process (PID 30226) was terminated by signal 6: Aborted 2022-01-19 21:25:34.485 IST [30205] DETAIL:  Failed process was running: BASE_BACKUP ( LABEL 'pg_basebackup base backup', PROGRESS,  MANIFEST 'yes',  TABLESPACE_MAP,  TARGET 'server', TARGET_DETAIL '/tmp/yc11',  COMPRESSION 'zstd') 2022-01-19 21:25:34.485 IST [30205] LOG:  terminating any other active server processes [edb@centos7tushar bin]$ 2022-01-19 21:25:34.489 IST [30205] LOG: all server processes terminated; reinitializing 2022-01-19 21:25:34.536 IST [30228] LOG:  database system was interrupted; last known up at 2022-01-19 21:23:26 IST 2022-01-19 21:25:34.669 IST [30228] LOG:  database system was not properly shut down; automatic recovery in progress 2022-01-19 21:25:34.671 IST [30228] LOG:  redo starts at 9/7000028 2022-01-19 21:25:34.671 IST [30228] LOG:  invalid record length at 9/7000148: wanted 24, got 0 2022-01-19 21:25:34.671 IST [30228] LOG:  redo done at 9/7000110 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s 2022-01-19 21:25:34.673 IST [30229] LOG:  checkpoint starting: end-of-recovery immediate wait 2022-01-19 21:25:34.713 IST [30229] LOG:  checkpoint complete: wrote 3 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.003 s, sync=0.001 s, total=0.041 s; sync files=2, longest=0.001 s, average=0.001 s; distance=0 kB, estimate=0 kB 2022-01-19 21:25:34.718 IST [30205] LOG:  database system is ready to accept connections Observation - if we change server-compression method to lz4 from zstd then it is NOT happening. [edb@centos7tushar bin]$ ./pg_basebackup  -t server:/tmp/ycc1 --server-compression=lz4 -v  -Xnone pg_basebackup: initiating base backup, waiting for checkpoint to complete 2022-01-19 21:27:51.642 IST [30229] LOG:  checkpoint starting: force wait 2022-01-19 21:27:51.687 IST [30229] LOG:  checkpoint complete: wrote 0 buffers (0.0%); 0 WAL file(s) added, 1 removed, 0 recycled; write=0.001 s, sync=0.001 s, total=0.046 s; sync files=0, longest=0.000 s, average=0.000 s; distance=16383 kB, estimate=16383 kB pg_basebackup: checkpoint completed NOTICE:  WAL archiving is not enabled; you must ensure that all required WAL segments are copied through other means to complete the backup pg_basebackup: base backup completed [edb@centos7tushar bin]$ -- regards,tushar EnterpriseDB https://www.enterprisedb.com/ The Enterprise PostgreSQL Company