Re: No toast table for pg_shseclabel but for pg_seclabel

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: No toast table for pg_shseclabel but for pg_seclabel
Дата
Msg-id 20140704101148.GQ25909@awork2.anarazel.de
обсуждение исходный текст
Ответ на No toast table for pg_shseclabel but for pg_seclabel  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: No toast table for pg_shseclabel but for pg_seclabel  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: pg_xlogdump --stats
Следующее
От: "gotoschool6g"
Дата:
Сообщение: Re: pg_xlogdump --stats