| From: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCH] Logical decoding of TRUNCATE |
| Date: | 2018-01-24 12:53:50 |
| Message-ID: | 3952d6e6-f438-f393-9a02-aae871d2fc3e@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
On 24/01/18 13:50, Peter Eisentraut wrote:
> I wonder whether this should be dealing with sequences at all. We are
> not currently publishing any information about sequences, so it seems
> weird to do it only here. Also, I'd imagine that if we ever get to
> publishing sequence events, then the sequence restarts would be
> published as independent events.
>
That depends on if we consider this to be part of sequence handling or
truncate statement replication handling. It's true that if we had
sequence replication, the restart would get propagated that way anyway.
OTOH, if we'll want to add option in the future to propagate cascade (to
any additional tables on downstream), it may need to reset sequences
which are not even present upstream and as such would not be handled by
sequence replication.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Adrian Klaver | 2018-01-24 13:42:29 | Re: PGSQL 10, many Random named DB |
| Previous Message | Peter Eisentraut | 2018-01-24 12:50:10 | Re: [PATCH] Logical decoding of TRUNCATE |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2018-01-24 12:58:28 | Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory |
| Previous Message | Peter Eisentraut | 2018-01-24 12:50:10 | Re: [PATCH] Logical decoding of TRUNCATE |