From: | Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Missing TOAST table for pg_class |
Date: | 2020-09-23 21:11:06 |
Message-ID: | CAFcNs+oTi=nzD8YxpKSkg+idKxXjaswKNM1fm4SXP-0P6_T8SA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 22, 2020 at 10:57 PM Michael Paquier <michael(at)paquier(dot)xyz>
wrote:
>
> On Tue, Sep 22, 2020 at 05:35:48PM -0400, Tom Lane wrote:
> > What exactly do you argue has changed since the previous decision
> > that should cause us to change it? In particular, where is the
> > additional data to change our minds about the safety of such a thing?
>
From a technical perspective I really don't know how to solve it, but my
intention here is to raise a hand and demonstrate there are real scenarios
where Postgres breaks so easily.
And unfortunately for the user perspective it sounds a bit fragile. Ok it's
not a very common use case and the solution isn't easy, because if it is
I'm sure it was already solved before.
> Not sure that's safe, as we also want to avoid circular dependencies
> similarly for pg_class, pg_index and pg_attribute.
>
Adding a TOAST can cause circular dependencies between those relations?? If
you don't mind can you explain more about it?
Regards,
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2020-09-23 21:51:46 | Re: Transactions involving multiple postgres foreign servers, take 2 |
Previous Message | Tom Lane | 2020-09-23 19:33:51 | Re: Lift line-length limit for pg_service.conf |