al table data because it
uses the tables with their initial data on the target server. It only
does the synchronization phase, which ensures each table is brought up
to a synchronized state by applying changes using standard logical
replication.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
supported versions), at least until such limitation is
> > lifted.
>
> Here is a patch for that,
The patch adds the description in the autovacuum_work_mem section.
Isn't it better to add it in mantenance_work section or VACUUM command
section since this limitation is not onl
ks view
> don't appear in our documentation. The attached patches adds the
> pg_locks names after each lock name. You can see the doc output here:
>
> https://momjian.us/tmp/pgsql/explicit-locking.html
>
> If people like this, I can apply it to all supported branches.
+1
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
t;
> There is a "bbb" and "ccc" to by pass the error.
You said you added 2 extra columns to the example in PG14 doc but both
pglog table definitions you mentioned above have the same number of
columns, 26. The first table definition worked with PG14 in my
environment. Could you try using the first example again and share the
error message if an error occurs?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
* # bytes requested for the structure */
> Sizeallocated_size; /* # bytes actually allocated */
> } ShmemIndexEnt;
>
> The unit is bytes. A patch is attached to add such information.
+1
The patch looks good to me.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
h the slot synchronization."
> >
>
> Hi Nisha,
>
> I have addressed the comments and attached the updated v2 patch.
IIUC the two_phase field is also not copied from the source slot. I
think we can clarify in the doc that these two fields are not copied.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
>
>
> I suspect that "datatype-uuid" is a copy-paste error and should be
> "functions-uuid" to reflect the correct section. The attached patch
> updates this accordingly.
>
> Thoughts?
+1. I think it also makes sense that &
