On Thu, 12 Sep 2019 at 19:11, Robert Haas <robertmh...@gmail.com> wrote: > > On Thu, Sep 12, 2019 at 5:31 AM Tomas Vondra > <tomas.von...@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 mean tracking excess kernel fds right ? Yeah, we can use VFDs so that excess fds are automatically closed. But Alvaro seems to be talking in context of tracking of file seek position. VFD does not have a mechanism to track file offsets if one of the vfd cached file is closed and reopened. Robert, are you suggesting to add this capability to VFD ? I agree that we could do it, but for back-patching, offhand I couldn't think of a simpler way. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company
