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 1pUT1A-0001Na-OI for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Feb 2023 13:49:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pUT17-00082Z-OC for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Feb 2023 13:49:13 +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 1pUT17-00082P-Cl for pgsql-hackers@lists.postgresql.org; Tue, 21 Feb 2023 13:49:13 +0000 Received: from mail-lf1-x12f.google.com ([2a00:1450:4864:20::12f]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pUT14-000267-PU for pgsql-hackers@postgresql.org; Tue, 21 Feb 2023 13:49:13 +0000 Received: by mail-lf1-x12f.google.com with SMTP id s22so5710305lfi.9 for ; Tue, 21 Feb 2023 05:49:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fdkqsjpk71qUmx+CIqQmG0AaX8hTlqxD89EsSvW9XTU=; b=Zk0jZUxkau2yuj4wL+GjiJuVlMopSFSsbYDKfOKcSqOnd3vo8wKLv/6TQnLllT65/b tXLfhgBOXVkqLQQs/Q4NBzBRgt94sziASFIb3V23SWn6R9pb2eYm6c5IVf/6PxHnjPf7 R/aGVYOAKzzMIob2mHQL5uTnXniajgP6X5YqWpW9wt123znjGUk6z2KBOW8MhBNhQNwT yeccNVQoZdpxeqlxZ0lKzXnlXDWyvYY34+BgjXARr2HvqAoW3jOYu3leZW4wtZUc1HSL 5YUVCG+SrQeO7aEr9aVRATyRcb+q1xu5sL4LPYJruAjNo+5hnEMoL/DXapgWN4EaxYs4 47mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=fdkqsjpk71qUmx+CIqQmG0AaX8hTlqxD89EsSvW9XTU=; b=LNR7lWwMK7hm1LJ/HjbgB+y7joo89qIi2PfpPI/7GSKSktseEBlSpaIDGm1zL36Riy 4KZEX74qrqUqdFDx2TQVjWH6vc5lR8afVCS1Aia6Td3/+SwOd9Vyq5aIT/TAZ3yhat3t hksle5gC59Ueksb5oRFjsNg4dEjHtdtnVi1NJKtvkUpK0+thy3M/kUIOJPLfMcf3zqa6 raJkRy2miGgKTfczBpQANapBKEdp8cKYzFqj5CH/zVM+a29EXZaHn247B6SL1iEz49Hr hAtcOrw3dCVQ+Z/fE+yHbkbpN2Ij+SSrrU5dnposfyD2sJ5y6Uaf3IRp+RPKXU2nJbBx 0J+w== X-Gm-Message-State: AO0yUKUMQ/93tR/fJdidS/6+PjFzGJc+Cypr6eCIYx9Bt8TcRUeeSuFx sMBXY1KkIqNiEgxl6EWAagd7HTIRBiK72kHNIns= X-Google-Smtp-Source: AK7set9X9xA6o/eVtwZzCE5p+HsEgtG0xnNm9QH/4aVd1Di0kS/EtGpXRaEQ/loXblWubylswOqZ42IhWBIboVbXIWs= X-Received: by 2002:a05:6512:208:b0:4d5:ca32:9bdf with SMTP id a8-20020a056512020800b004d5ca329bdfmr1775170lfo.11.1676987348892; Tue, 21 Feb 2023 05:49:08 -0800 (PST) MIME-Version: 1.0 References: <2ebc7ea8-3c46-474e-aea7-5d73ff6165fb@www.fastmail.com> <7cf14e66-8cea-406f-9607-607a397292f6@www.fastmail.com> In-Reply-To: From: Bharath Rupireddy Date: Tue, 21 Feb 2023 19:18:00 +0530 Message-ID: Subject: Re: Allow logical replication to copy tables in binary format To: Melih Mutlu Cc: "Hayato Kuroda (Fujitsu)" , "Takamichi Osumi (Fujitsu)" , "shiy.fnst@fujitsu.com" , Euler Taveira , Amit Kapila , pgsql-hackers Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Feb 20, 2023 at 5:17 PM Melih Mutlu wrote: > > Thanks for letting me know. > Attached the fixed version of the patch. Thanks. I have few comments on v9 patch: 1. + /* Do not allow binary = false with copy_format = binary */ + if (!opts.binary && + sub->copyformat == LOGICALREP_COPY_AS_BINARY && + !IsSet(opts.specified_opts, SUBOPT_COPY_FORMAT)) + ereport(ERROR, + (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE), + errmsg("cannot set %s for a subscription with %s", + "binary = false", "copy_format = binary"))); I don't understand why we'd need to tie an option (binary) that deals with data types at column-level with another option (copy_format) that requests the entire table data to be in binary. This'd essentially make one to set binary = true to use copy_format = binary, no? IMHO, this inter-dependency is not good for better usability. 2. Why can't the tests that this patch adds be simple? Why would it need to change the existing tests at all? I'm thinking to create a new 00X_binary_copy_format.pl or such and setting up logical replication with copy_format = binary and letting table sync worker request publisher in binary format - you can verify this via publisher server logs - look for COPY with BINARY option. If required, have the table with different data types. This greatly reduces the patch's footprint. -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com