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.
Thanks,
2014-07-04 19:11 GMT+09:00 Andres Freund <and...@2ndquadrant.com>:
> 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
> http://archives.postgresql.org/message-id/1309888389-sup-3853%40alvh.no-ip.org
>
> 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 http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
--
KaiGai Kohei <kai...@kaigai.gr.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
