Re: making relfilenodes 56 bits

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: making relfilenodes 56 bits
Дата
Msg-id CA+TgmobbEVGgqwvqH7dTkdofTiXt-v5ru4BZoxfjcsXtxE8Y4g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: making relfilenodes 56 bits  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Tue, Jun 28, 2022 at 11:25 AM Robert Haas <robertmhaas@gmail.com> wrote:
> But the primary problem we're trying to solve here is that right now
> we sometimes reuse the same filename for a whole new file, and that
> results in bugs that only manifest themselves in obscure
> circumstances, e.g. see 4eb2176318d0561846c1f9fb3c68bede799d640f.
> There are residual failure modes even now related to the "tombstone"
> files that are created when you drop a relation: remove everything but
> the first file from the main fork but then keep that file (only)
> around until after the next checkpoint. OID wraparound is another
> annoyance that has influenced the design of quite a bit of code over
> the years and where we probably still have bugs. If we don't reuse
> relfilenodes, we can avoid a lot of that pain. Combining the DB OID
> and TS OID fields doesn't solve that problem.

Oh wait, I'm being stupid. You were going to combine those fields but
then also widen the relfilenode, so that would solve this problem
after all. Oops, I'm dumb.

I still think this is a lot more complicated though, to the point
where I'm not sure we can really make it work at all.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



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

Предыдущее
От: vignesh C
Дата:
Сообщение: Re: Support logical replication of DDLs
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: Hardening PostgreSQL via (optional) ban on local file system access