pgsql: Remove arbitrary FUNC_MAX_ARGS limit in int2vectorin and oidvect
От | Tom Lane |
---|---|
Тема | pgsql: Remove arbitrary FUNC_MAX_ARGS limit in int2vectorin and oidvect |
Дата | |
Msg-id | E1pHBXy-003r9e-8H@gemulon.postgresql.org обсуждение исходный текст |
Список | pgsql-committers |
Remove arbitrary FUNC_MAX_ARGS limit in int2vectorin and oidvectorin. int2vectorin limited the number of array elements it'd take to FUNC_MAX_ARGS, which is probably fine for the traditional use-cases. But now that pg_publication_rel.prattrs is an int2vector, it's not fine at all: it's easy to construct cases where that can have up to about MaxTupleAttributeNumber entries. Trying to replicate such tables leads to logical-replication failures. As long as we have to touch this code anyway, let's just remove the a-priori limit altogether, and let it accept any size that'll be allowed by repalloc. (Note that since int2vector isn't toastable, we cannot store arrays longer than about BLCKSZ/2; but there is no good excuse for letting int2vectorin depend on that. Perhaps we will lift the no-toast restriction someday.) While at it, also improve the equivalent logic in oidvectorin. I don't know of any practical use-case for long oidvectors right now, but doing it right actually makes the code shorter. Per report from Erik Rijkers. Back-patch to v15 where pg_publication_rel.prattrs was added. Discussion: https://postgr.es/m/668ba539-33c5-8190-ca11-def2913cb94b@xs4all.nl Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/647fa500547fdf2a967412633a9f6f21ba69e144 Modified Files -------------- src/backend/utils/adt/int.c | 26 +++++++++++--------------- src/backend/utils/adt/oid.c | 25 +++++++++++-------------- 2 files changed, 22 insertions(+), 29 deletions(-)
В списке pgsql-committers по дате отправления: