Re: logical decoding : exceeded maxAllocatedDescs for .spill files

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: logical decoding : exceeded maxAllocatedDescs for .spill files
Дата
Msg-id CA+TgmoZBGXTUdyR88EgtyukG5Ne3s6=y83k1M8ZMCZWte1qCjg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: logical decoding : exceeded maxAllocatedDescs for .spill files  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: logical decoding : exceeded maxAllocatedDescs for .spill files  (Amit Khandekar <amitdkhan.pg@gmail.com>)
Список pgsql-hackers
On Fri, Sep 13, 2019 at 12:14 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Amit Khandekar <amitdkhan.pg@gmail.com> writes:
> > 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.
>
> Hm.  It used to, but somebody got rid of that on the theory that
> we could use pread/pwrite instead.  I'm inclined to think that that
> was the right tradeoff, but it'd mean that getting logical decoding
> to adhere to the VFD API requires extra work to track file position
> on the caller side.

Oops.  I forgot that we'd removed that.

> Again, though, the advice that's been given here is that we should
> fix logical decoding to use the VFD API as it stands, not change
> that API.  I concur with that.

A reasonable position.  So I guess logical decoding has to track the
file position itself, but perhaps use the VFD layer for managing FD
pooling.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: logical decoding : exceeded maxAllocatedDescs for .spill files
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] CLUSTER command progress monitor