| From: | Jelte Fennema <postgres(at)jeltef(dot)nl> |
|---|---|
| To: | Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com> |
| Cc: | "shiy(dot)fnst(at)fujitsu(dot)com" <shiy(dot)fnst(at)fujitsu(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, "Takamichi Osumi (Fujitsu)" <osumi(dot)takamichi(at)fujitsu(dot)com>, Euler Taveira <euler(at)eulerto(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
| Subject: | Re: Allow logical replication to copy tables in binary format |
| Date: | 2023-02-23 12:17:33 |
| Message-ID: | CAGECzQS393xiME+EySLU7ceO4xOB81kPjPqNBjaeW3sLgfLhNw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> This is because copy_data is not something stored in pg_subscription
> or another catalog. But this is not an issue for copy_fornat since its
> value will be stored in the catalog. This can allow users to set the
> format even if copy_data=false and no initial sync is needed at that
> moment.
One other approach that might make sense is to expand the values that
copy_data accepts to include the value "binary" (and probably "text"
for clarity). That way people could easily choose for each sync if
they want to use binary copy, text copy or no copy. Based on your
message, this would mean that copy_format=binary would not be stored
in catalogs anymore, does that have any bad side-effects for the
implementation?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2023-02-23 12:56:13 | Re: logical decoding and replication of sequences, take 2 |
| Previous Message | Hayato Kuroda (Fujitsu) | 2023-02-23 12:09:58 | RE: Time delayed LR (WAS Re: logical replication restrictions) |