Re: In-placre persistance change of a relation

Поиск
Список
Период
Сортировка
От Kyotaro Horiguchi
Тема Re: In-placre persistance change of a relation
Дата
Msg-id 20230207.134759.959357838700669165.horikyota.ntt@gmail.com
обсуждение исходный текст
Ответ на Re: In-placre persistance change of a relation  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: In-placre persistance change of a relation  ("Gregory Stark (as CFM)" <stark.cfm@gmail.com>)
Список pgsql-hackers
Thank you for the comment!

At Fri, 3 Feb 2023 08:42:52 +0100, Heikki Linnakangas <hlinnaka@iki.fi> wrote in 
> I want to call out this part of this patch:
> 
> > Also this allows for the cleanup of files left behind in the crash of
> > the transaction that created it.
> 
> This is interesting to a lot wider audience than ALTER TABLE SET
> LOGGED/UNLOGGED. It also adds most of the complexity, with the new
> marker files. Can you please split the first patch into two:
> 
> 1. Cleanup of newly created relations on crash
> 
> 2. ALTER TABLE SET LOGGED/UNLOGGED changes
> 
> Then we can review the first part independently.

Ah, indeed.  I'll do that.

> Regarding the first part, I'm not sure the marker files are the best
> approach to implement it. You need to create an extra file for every
> relation, just to delete it at commit. It feels a bit silly, but maybe

Agreed. (But I didn't come up with better idea..)

> it's OK in practice. The undo log patch set solved this problem with
> the undo log, but it looks like that patch set isn't going
> anywhere. Maybe invent a very lightweight version of the undo log for
> this?

I didn't thought on that line. Yes, indeed the marker files are a kind
of undo log.

Anyway, I'll split the current patch to two parts as suggested.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: tests against running server occasionally fail, postgres_fdw & tenk1
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Exit walsender before confirming remote flush in logical replication