| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "tanghy(dot)fnst(at)fujitsu(dot)com" <tanghy(dot)fnst(at)fujitsu(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Greg Nancarrow <gregn4422(at)gmail(dot)com>, "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com>, Alexey Lesovsky <lesovsky(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Skipping logical replication transactions on subscriber side |
| Date: | 2022-02-15 10:35:15 |
| Message-ID: | 56e64628-940b-dca9-1388-872a914f8ea0@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 14.02.22 10:16, Amit Kapila wrote:
> I think exposing LSN is a better approach as it doesn't have the
> dangers of wraparound. And, I think users can use it with the existing
> function pg_replication_origin_advance() which will save us from
> adding additional code for this feature. We can explain/expand in docs
> how users can use the error information from view/error_logs and use
> the existing function to skip conflicting transactions. We might want
> to even expose error_origin to make it a bit easier for users but not
> sure. I feel the need for the new syntax (and then added code
> complexity due to that) isn't warranted if we expose error_LSN and let
> users use it with the existing functions.
Well, the whole point of this feature is to provide a higher-level
interface instead of pg_replication_origin_advance(). Replication
origins are currently not something the users have to deal with
directly. We already document that you can use
pg_replication_origin_advance() to skip erroring transactions. But that
seems unsatisfactory. It'd be like using pg_surgery to fix unique
constraint violations.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ranier Vilela | 2022-02-15 11:04:06 | Re: Postgres 14.2 Windows can't rename temporary statistics file |
| Previous Message | Juan José Santamaría Flecha | 2022-02-15 10:21:42 | Re: pg_receivewal.exe unhandled exception in zlib1.dll |