Re: Skipping logical replication transactions on subscriber side
От | Robert Haas |
---|---|
Тема | Re: Skipping logical replication transactions on subscriber side |
Дата | |
Msg-id | CA+TgmoY+8qji_MNSaU7FYGusTVAzcX+KYzP8UZ1p=jGyzG6rJg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Skipping logical replication transactions on subscriber side (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: Skipping logical replication transactions on subscriber side
|
Список | pgsql-hackers |
On Tue, Jun 14, 2022 at 3:54 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > AFAICS, we could do that by: > > > > 1. De-supporting platforms that have this problem, or > > 2. Introducing new typalign values, as Noah proposed back on April 2, or > > 3. Somehow forcing values that are sometimes 4-byte aligned and > > sometimes 8-byte aligned to be 8-byte alignment on all platforms > > Introducing new typalign values seems a good idea to me as it's more > future-proof. Will this item be for PG16, right? The main concern > seems that what this test case enforces would be nuisance when > introducing a new system catalog or a new column to the existing > catalog but given we're in post PG15-beta1 it is unlikely to happen in > PG15. I agree that we're not likely to introduce a new typalign value any sooner than v16. There are a couple of things that bother me about that solution. One is that I don't know how many different behaviors exist out there in the wild. If we distinguish the alignment of double from the alignment of int8, is that good enough, or are there other data types whose properties aren't necessarily the same as either of those? The other is that 32-bit systems are already relatively rare and probably will become more rare until they disappear completely. It doesn't seem like a ton of fun to engineer solutions to problems that may go away by themselves with the passage of time. On the other hand, if the alternative is to live with this kind of ugliness for another 5 years, maybe the time it takes to craft a solution is effort well spent. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: