Re: [HACKERS] Draft release notes for next week's back-branchreleases
От | Petr Jelinek |
---|---|
Тема | Re: [HACKERS] Draft release notes for next week's back-branchreleases |
Дата | |
Msg-id | 0a9c9cb9-cc67-5847-482b-f0efb50ec400@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Draft release notes for next week's back-branch releases (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Draft release notes for next week's back-branch releases
|
Список | pgsql-hackers |
On 06/05/17 18:16, Tom Lane wrote: > Petr Jelinek <petr.jelinek@2ndquadrant.com> writes: >> On 06/05/17 17:25, Tom Lane wrote: >>> OK, can you suggest better wording? > >> Something like the attached (it requires some polishing of English >> probably). > > Hmm, I'm hoping for something more user-oriented. Is the corruption > time-limited? What's an "exported snapshot" anyway, is it the same > thing as pg_export_snapshot(), and if so what's that got to do with > logical replication? > Well user does not care unless they use something like pglogical, or bottledwater, or wal2json, etc. Okay to explain what's happening. When you create logical replication slot via walsender, it exports snapshot (like the one exported by pg_export_snapshot() indeed) which corresponds to exact point in time where the decoding will start for the slot. You can import this snapshot to another backend and use it to copy any existing data before starting the replication. The bugs cause that these snapshots would be corrupted and you'd have inconsistent data (some tuples missing). One of them would export snapshot that's only valid for system catalogs but not user tables (the ondisk snapshot, this needs at least one preexisting slot). The other would not guarantee that tuples needed by the snapshot weren't removed by vacuum of HOT pruning (the window being only the time it took to generate the snapshot). -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: