From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Khandekar <amitdkhan.pg@gmail.com>
cc: Robert Haas <robertmhaas@gmail.com>,
        Tomas Vondra <tomas.vondra@2ndquadrant.com>,
        Alvaro Herrera from 2ndQuadrant <alvherre@alvh.no-ip.org>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: logical decoding : exceeded maxAllocatedDescs for .spill files
In-reply-to: 
 <CAJ3gD9fBMFwrDpLWpQpJDnJObAd+npBFqYKL4VV22G--YLmTPA@mail.gmail.com>
References: 
 <CAJ3gD9c-sECEn79zXw4yBnBdOttacoE-6gAyP0oy60nfs_sabQ@mail.gmail.com>
 <20190911125140.GA21034@alvherre.pgsql>
 <20190912093055.exeatfemzr3f25yx@development>
 <CA+TgmobZM1-0c2WZ0xy9hrwh-m18xem0+xGmAt9BA2o7zb9jDg@mail.gmail.com>
 <CAJ3gD9fmQ8Vd_YbvTt2u_HsBmpKBN9OvZP0hSXhVrS4n21aQQQ@mail.gmail.com>
 <7005.1568391272@sss.pgh.pa.us>
 <CA+TgmoZBGXTUdyR88EgtyukG5Ne3s6=y83k1M8ZMCZWte1qCjg@mail.gmail.com>
 <CAJ3gD9fBMFwrDpLWpQpJDnJObAd+npBFqYKL4VV22G--YLmTPA@mail.gmail.com>
Comments: In-reply-to Amit Khandekar <amitdkhan.pg@gmail.com>
	message dated "Sat, 14 Sep 2019 20:35:25 +0530"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <31834.1568486061.1@sss.pgh.pa.us>
Date: Sat, 14 Sep 2019 14:34:21 -0400
Message-ID: <31835.1568486061@sss.pgh.pa.us>
Precedence: bulk

Amit Khandekar <amitdkhan.pg@gmail.com> writes:
> On Fri, 13 Sep 2019 at 22:01, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Fri, Sep 13, 2019 at 12:14 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> 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.

> Yeah, something like the attached patch. I think this tracking of
> offsets would have been cleaner if we add in-built support in VFD. But
> yeah, for bank branches at least, we need to handle it outside of VFD.
> Or may be we would add it if we find one more use-case.

Again, we had that and removed it, for what seem to me to be solid
reasons.  It adds cycles when we're forced to close/reopen a file,
and it also adds failure modes that we could do without (ie, failure
of either the ftell or the lseek, which are particularly nasty because
they shouldn't happen according to the VFD abstraction).  I do not
think there is going to be any argument strong enough to make us
put it back, especially not for non-mainstream callers like logical
decoding.

			regards, tom lane