Re: logical decoding : exceeded maxAllocatedDescs for .spill files
От | Andres Freund |
---|---|
Тема | Re: logical decoding : exceeded maxAllocatedDescs for .spill files |
Дата | |
Msg-id | 20190912183137.cr65jj6cq6qkinty@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: logical decoding : exceeded maxAllocatedDescs for .spill files (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
Hi, On 2019-09-12 09:41:02 -0400, Robert Haas wrote: > On Thu, Sep 12, 2019 at 5:31 AM Tomas Vondra > <tomas.vondra@2ndquadrant.com> wrote: > > I don't see how the current API could do that transparently - it does > > track the files, but the user only gets a file descriptor. With just a > > file descriptor, how could the code know to do reopen/seek when it's going > > just through the regular fopen/fclose? > > > > Anyway, I agree we need to do something, to fix this corner case (many > > serialized in-progress transactions). ISTM we have two options - either do > > something in the context of reorderbuffer.c, or extend the transient file > > API somehow. I'd say the second option is the right thing going forward, > > because it does allow doing it transparently and without leaking details > > about maxAllocatedDescs etc. There are two issues, though - it does > > require changes / extensions to the API, and it's not backpatchable. > > > > So maybe we should start with the localized fix in reorderbuffer, and I > > agree tracking offset seems reasonable. > > We've already got code that knows how to track this sort of thing. > You just need to go through the File abstraction (PathNameOpenFile or > PathNameOpenFilePerm or OpenTemporaryFile) rather than using the > functions that deal directly with fds (OpenTransientFile, > BasicOpenFile, etc.). It seems like it would be better to reuse the > existing VFD layer than to invent a whole new one specific to logical > replication. Yea, I agree that that is the right fix. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: