From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | robertmhaas(at)gmail(dot)com, michael(at)paquier(dot)xyz, rjuju123(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: standby recovery fails (tablespace related) (tentative patch and discussion) |
Date: | 2022-03-29 11:37:34 |
Message-ID: | 202203291137.ys7fq7g4ehte@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2022-Mar-29, Kyotaro Horiguchi wrote:
> > That's going to result in a call to
> > XLogReadBufferForRedoExtended() which will call
> > XLogReadBufferExtended() which will do smgrcreate(smgr, forknum, true)
> > which will in turn call TablespaceCreateDbspace() to fill in all the
> > missing directories.
>
> Right. I thought that recovery avoids that but that's wrong. This
> behavior creates a bare (non-linked) directly within pg_tblspc. The
> directory would dissapear soon if recovery proceeds to the consistency
> point, though.
Hmm, this is not good.
> No. I agree that mixing them is not good. On the other hand we
> already doing that by heapam. AFAICS sometimes it avoid creating a
> new page but sometimes creates it. But I don't mean to use the fact
> for justifying this patch to do that, or denying to do that.
I think we should revert this patch and do it again using the other
approach: create a stub directory during recovery that can be deleted
later.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"Porque francamente, si para saber manejarse a uno mismo hubiera que
rendir examen... ¿Quién es el machito que tendría carnet?" (Mafalda)
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2022-03-29 11:47:18 | Re: Column Filtering in Logical Replication |
Previous Message | Erik Rijkers | 2022-03-29 11:29:15 | Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403) |