Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To:

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Subject: Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To:
Date: 2022-04-02 05:04:09
Message-ID: CA+hUKG+uPTQiLYOz7FDwHtnoPjBh+Y8VUvuhjHPNW-y1oi7WZg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Apr 2, 2022 at 10:03 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> Another idea would be to call a new function DropPendingWritebacks(),
> and also tell all the SMgrRelation objects to close all their internal
> state (ie the fds + per-segment objects) but not free the main
> SMgrRelationData object, and for good measure also invalidate the
> small amount of cached state (which hasn't been mentioned in this
> thread, but it kinda bothers me that that state currently survives, so
> it was one unspoken reason I liked the smgrcloseall() idea). Since
> DropPendingWritebacks() is in a rather different module, perhaps if we
> were to do that we'd want to rename PROCSIGNAL_BARRIER_SMGRRELEASE to
> something else, because it's not really a SMGR-only thing anymore.

Here's a sketch of that idea.

Attachment Content-Type Size
0001-WIP-Rethink-PROCSIGNAL_BARRIER_SMGRRELEASE.patch text/x-patch 7.2 KB
0002-WIP-fix-old-fd-issues-using-global-barriers-everywhe.patch text/x-patch 2.1 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-04-02 05:10:39 Re: A test for replay of regression tests
Previous Message Amit Kapila 2022-04-02 04:08:32 Re: Skipping logical replication transactions on subscriber side