From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | robertmhaas(at)gmail(dot)com |
Cc: | dilipbalaut(at)gmail(dot)com, stark(dot)cfm(at)gmail(dot)com, michael(at)paquier(dot)xyz, andres(at)anarazel(dot)de, jchampion(at)timescale(dot)com, y(dot)sokolov(at)postgrespro(dot)ru, rjuju123(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Error "initial slot snapshot too large" in create replication slot |
Date: | 2024-01-16 02:18:54 |
Message-ID: | 20240116.111854.2149862884148325077.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Fri, 12 Jan 2024 11:28:09 -0500, Robert Haas <robertmhaas(at)gmail(dot)com> wrote in
> However, I wonder whether this whole area is in need of a bigger
> rethink. There seem to be a number of situations in which the split
> into xip and subxip arrays is not very convenient, and also some
> situations where it's quite important. Sometimes we want to record
> what's committed, and sometimes what isn't. It's all a bit messy and
> inconsistent. The necessity of limiting snapshot size is annoying,
> too. I have no real idea what can be done about all of this, but what
> strikes me is that the current system has grown up incrementally: we
> started with a data structure designed for the original use case, and
> now by gradually adding new use cases things have gotten complicated.
> If we were designing things over from scratch, maybe we'd do it
> differently and end up with something less messy. And maybe someone
> can imagine a redesign that is likewise less messy.
>
> But on the other hand, maybe not. Perhaps we can't really do any
> better than what we have. Then the question becomes whether this case
> is important enough to justify additional code complexity. I don't
> think I've personally seen users run into this problem so I have no
> special reason to think that it's important, but if it's causing
> issues for other people then maybe it is.
Thank you for the deep insights. I have understood your points. As I
can't think of any further simple modifications on this line, I will
withdraw this CF entry. At the moment, I also lack a fundamental,
comprehensive solution, but should if I or anyone else come up with
such a solution in the future, I believe it would worth a separate
discussion.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Junwang Zhao | 2024-01-16 02:32:55 | Re: make pg_ctl more friendly |
Previous Message | Peter Geoghegan | 2024-01-16 02:02:56 | Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan |