Here is no other reason than what Alvaro mentioned in the upthread.
We intended to store security label of SELinux (less than 100bytes at most),
so I didn't think it leads any problem actually.

On the other hands, pg_seclabel was merged in another development cycle.
We didn't have deep discussion about necessity of toast table of pg_seclabel.
I added its toast table mechanically.

It never means we need toast table for local object but don't need it for shared
database object.


2014-07-04 19:11 GMT+09:00 Andres Freund <>:
> On 2014-07-04 11:50:17 +0200, Andres Freund wrote:
>> Hi,
>> postgres=# SELECT oid::regclass, reltoastrelid FROM pg_class WHERE relname 
>> IN ('pg_seclabel', 'pg_shseclabel');
>>       oid      | reltoastrelid
>> ---------------+---------------
>>  pg_seclabel   |          3598
>>  pg_shseclabel |             0
>> (2 rows)
>> Isn't that a somewhat odd choice? Why do we assume that there cannot be
>> lengthy seclabels on shared objects? Granted, most shared objects aren't
>> candidates for large amounts of data, but both users and databases don't
>> seem to fall into that category.
> Hm. It seems they were explicitly removed around
> I don't understand the reasoning there. There's a toast table for
> non-shared objects. Why would we expect less data for the shared ones,
> even though they're pretty basic objects and more likely to be used to
> store policies and such?
> Greetings,
> Andres Freund
> --
>  Andres Freund           
>  PostgreSQL Development, 24x7 Support, Training & Services

KaiGai Kohei <>

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to