Re: Error with index on unlogged table
От | Michael Paquier |
---|---|
Тема | Re: Error with index on unlogged table |
Дата | |
Msg-id | CAB7nPqSD4yw=p39Ei4gjf=HN_8kD=npSOKa1fQT3q3O2cTYDHQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Error with index on unlogged table (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Error with index on unlogged table
Re: Error with index on unlogged table |
Список | pgsql-hackers |
On Fri, Nov 20, 2015 at 7:03 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Thu, Nov 19, 2015 at 7:19 AM, Thom Brown <thom@linux.com> wrote: >> This bug still exists. > > Hmm. This probably should have been on the open items list. I have added an open item for 9.5. That's not a cool bug to release the next GA even if that's not limited to 9.5, it is easily reproducible in older stable branches as well. > I didn't > pay too much attention this to this before because it seemed like > Andres and Michael were all over it. This completely fell off my radar. Sorry about that. For back-branches, I tend to agree with what Horiguchi-san mentioned upthread: we had better issue an unconditional fsync on the relation when INIT_FORKNUM is used for it when replaying XLOG_FPI record. That would rather localize the impact. An example of patch is attached that applies on top of REL9_4_STABLE. That's rather ugly but it shows the idea and fixes the issue. For master and perhaps 9.5, I would think that a dedicated WAL record type enforcing the fsync is the way to go. This special treatment would go only for btree and spgist when they use INIT_FORKNUM and we would not impact other relation types and code paths with this behavior. Thoughts? -- Michael
Вложения
В списке pgsql-hackers по дате отправления: