| From: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | Jacob Champion <jchampion(at)timescale(dot)com>, Nikita Malakhov <hukutoc(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Teodor Sigaev <teodor(at)sigaev(dot)ru> |
| Subject: | Re: Pluggable toaster |
| Date: | 2022-10-22 08:58:10 |
| Message-ID: | CAJ7c6TPApg12Ma4eLd04rwVQJQ1AkHa2SnnDyYBHgnoR5EhY1w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Nikita,
> Aleksander, we have had this in mind while developing this feature, and have checked it. Just a slight modification is needed
> to make it work with Pluggable Storage (Access Methods) API.
Could you please clarify this a little from the architectural point of view?
Let's say company A implements some specific TableAM (in-memory / the
one that uses undo logging / etc). Company B implements an alternative
TOAST mechanism.
How the TOAST extension is going to work without knowing any specifics
of the TableAM the user chooses for the given relation, and vice
versa? How one of the extensions is going to upgrade / downgrade
between the versions without knowing any implementation details of
another?
--
Best regards,
Aleksander Alekseev
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2022-10-22 09:42:02 | Re: Avoid memory leaks during base backups |
| Previous Message | Bharath Rupireddy | 2022-10-22 08:38:13 | Re: Crash after a call to pg_backup_start() |