From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, simon(dot)riggs(at)enterprisedb(dot)com |
Subject: | Re: Logical Replication - behavior of TRUNCATE ... CASCADE |
Date: | 2021-05-24 08:48:43 |
Message-ID: | CALj2ACWdUWVFZJ0UtFZdoUVJT6B46-VgKbDkEYvC3d9Toic_UA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, May 24, 2021 at 11:22 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> I don't deny that this can allow some additional cases than we allow
> today but was just not sure whether users really need it. If we want
> to go with such an option then as mentioned earlier, we should
> consider another proposal for subscriber-side truncate [1] because we
> might need a cascade operation there as well but for a slightly
> different purpose.
I'm thinking how we can utilize the truncate option proposed at [1]
for the idea here. Because, currently the truncate option(proposed at
[1]) is boolean, (of course we can change this to take "cascade",
"restrict" options). But how can we differentiate the usage of the
truncate option at [1] for two purposes 1) for before copy
data/initial table sync operation and 2) for the replication of
TRUNCATE command as proposed here in this thread. Any thoughts?
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-05-24 08:53:51 | Re: Move pg_attribute.attcompression to earlier in struct for reduced size? |
Previous Message | Bharath Rupireddy | 2021-05-24 08:40:28 | Re: [PATCH] Add `truncate` option to subscription commands |