| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: logical decoding and replication of sequences, take 2 |
| Date: | 2023-01-11 20:58:10 |
| Message-ID: | 20230111205810.6dikfcbaqep5jcdm@awork3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2023-01-11 15:41:45 -0500, Robert Haas wrote:
> I wonder, then, what happens if somebody wants to do parallel apply. That
> would seem to require some relaxation of this rule, but then doesn't that
> break what this patch wants to do?
I don't think it'd pose a direct problem - presumably you'd only parallelize
applying changes, not committing the transactions containing them. You'd get a
lot of inconsistencies otherwise.
If you're thinking of decoding changes in parallel (rather than streaming out
large changes before commit when possible), you'd only be able to do that in
cases when transaction haven't performed catalog changes, I think. In which
case there'd also be no issue wrt transactional sequence changes.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2023-01-11 20:58:11 | Re: ATTACH PARTITION seems to ignore column generation status |
| Previous Message | Andres Freund | 2023-01-11 20:48:36 | Re: low wal_retrieve_retry_interval causes missed signals on Windows |