From: Antonin Houska <ah@cybertec.at>
To: pgsql-hackers@lists.postgresql.org
Subject: Re: Logical replication row filtering and TOAST
In-reply-to: <84638.1649152255@antos>
References: <84638.1649152255@antos>
Comments: In-reply-to Antonin Houska <ah@cybertec.at>
   message dated "Tue, 05 Apr 2022 11:50:55 +0200."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <85261.1649154136.1@antos>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 05 Apr 2022 12:22:16 +0200
Message-ID: <85262.1649154136@antos>
Archived-At: <https://www.postgresql.org/message-id/85262.1649154136%40antos>
Precedence: bulk

Antonin Houska <ah@cybertec.at> wrote:

> I spent some time thinking about a special case of evaluation of the row
> filter and wrote a comment that might be useful (see the attachment). Ho=
wever
> now I think that it's not perfect if the code really relies on the fact =
that
> value of an indexed column cannot be TOASTed due to size restrictions.
> =

> I could hit two different error messages when trying activate TOAST on a=
n
> index column (in this case PG was build with 16kB pages), but still I th=
ink
> the code is unnecessarily fragile if it relies on such errors:
> =

> =

> ERROR:  index row requires 8224 bytes, maximum size is 8191
> =

> ERROR:  index row size 8048 exceeds btree version 4 maximum 5432 for ind=
ex "b_pkey"
> DETAIL:  Index row references tuple (0,3) in relation "b".
> HINT:  Values larger than 1/3 of a buffer page cannot be indexed.
> =

> =

> Note that at least in ExtractReplicaIdentity() we do expect that an inde=
xed
> column value can be TOASTed.
> =

> 	/*
> 	 * If the tuple, which by here only contains indexed columns, still has
> 	 * toasted columns, force them to be inlined. This is somewhat unlikely
> 	 * since there's limits on the size of indexed columns, so we don't
> 	 * duplicate toast_flatten_tuple()s functionality in the above loop ove=
r
> 	 * the indexed columns, even if it would be more efficient.
> 	 */
> 	if (HeapTupleHasExternal(key_tuple))
> 	{
> 		HeapTuple	oldtup =3D key_tuple;
> =

> 		key_tuple =3D toast_flatten_tuple(oldtup, desc);
> 		heap_freetuple(oldtup);
> 	}
> =

> Do I miss anything?

Well, I see now that the point might be that, in heap_update(),
"id_has_external" would be true the indexed value could be TOASTed, so tha=
t
the (flattened) old tuple would be WAL logged:

	old_key_tuple =3D ExtractReplicaIdentity(relation, &oldtup,
										   bms_overlap(modified_attrs, id_attrs) ||
										   id_has_external,
										   &old_key_copied);

Nevertheless, a comment in pgoutput_row_filter(), saying that TOASTed valu=
es
are not expected if old_slot is NULL, might be useful.


-- =

Antonin Houska
Web: https://www.cybertec-postgresql.com