On Sun, May 26, 2019 at 10:11 PM Michael Paquier wrote:
> If we should do something about such cases, then this brings us back
> to do (INIT | CLEANUP) at the end of recovery anyway?
I believe that could fix problems #1 and #2, but we'd have to think
about what new issues it would introduce.
#3
On Thu, May 23, 2019 at 09:14:59AM -0400, Robert Haas wrote:
> Suppose we create an unlogged table and then crash. The main fork
> makes it to disk, and the init fork does not. Before WAL replay, we
> remove any main forks that have init forks, but because the init fork
> was lost, that does not h
On Thu, May 23, 2019 at 2:43 AM Michael Paquier wrote:
> On Tue, May 21, 2019 at 08:39:18AM -0400, Robert Haas wrote:
> > Yes. I thought I had described it. You create an unlogged table,
> > with an index of a type that does not smgrimmedsync(), your
> > transaction commits, and then the system
On Tue, May 21, 2019 at 08:39:18AM -0400, Robert Haas wrote:
> Yes. I thought I had described it. You create an unlogged table,
> with an index of a type that does not smgrimmedsync(), your
> transaction commits, and then the system crashes, losing the _init
> fork for the index.
The init forks
On Tue, May 21, 2019 at 4:17 AM Michael Paquier wrote:
> > 2. Suppose the system reaches the end of
> > heapam_relation_set_new_filenode and then the system crashes. Because
> > of the smgrimmedsync(), and only because of the smgrimmedsync(), the
> > init fork would exist at the start of recovery
On Mon, May 20, 2019 at 09:16:32AM -0400, Robert Haas wrote:
> Based on the discussion so far, I think there are a number of related
> problems here:
Thanks for the summary.
> 1. A base backup might copy the main fork but not the init fork. I
> think that's a problem that nobody's thought about b
On Tue, May 14, 2019 at 2:19 AM Andres Freund wrote:
> How would this protect against the issues I mentioned where recovery
> starts from an earlier checkpoint and the basebackup could pick up a
> random set of version of the different forks?
>
> I don't like the idea of expanding the use of delay
Hi,
On 2019-05-14 14:22:15 +0900, Michael Paquier wrote:
> On Mon, May 13, 2019 at 09:33:52PM -0700, Andres Freund wrote:
> > On 2019-05-14 13:23:28 +0900, Michael Paquier wrote:
> >> What's actually the reason preventing us from delaying the
> >> checkpointer like the index AMs for the logging of
On Mon, May 13, 2019 at 09:33:52PM -0700, Andres Freund wrote:
> On 2019-05-14 13:23:28 +0900, Michael Paquier wrote:
>> What's actually the reason preventing us from delaying the
>> checkpointer like the index AMs for the logging of heap init fork?
>
> I'm not following. What do you mean by "dela
Hi,
On 2019-05-14 13:23:28 +0900, Michael Paquier wrote:
> On Mon, May 13, 2019 at 10:37:35AM -0700, Andres Freund wrote:
> > Ugh, this is all such a mess. But, isn't this broken independently of
> > the smgrimmedsync() issue? In a basebackup case, the basebackup could
> > have included the main f
Hi,
On 2019-05-14 12:50:09 +0900, Michael Paquier wrote:
> On Mon, May 13, 2019 at 10:52:21AM -0700, Andres Freund wrote:
> > I was wrong here - I thought we WAL logged the main fork creation even
> > for unlogged tables. I think it's foolish that we don't, but we don't.
>
> Why? The main fork is
On Mon, May 13, 2019 at 10:37:35AM -0700, Andres Freund wrote:
> Ugh, this is all such a mess. But, isn't this broken independently of
> the smgrimmedsync() issue? In a basebackup case, the basebackup could
> have included the main fork, but not the init fork, and the reverse. WAL
> replay *solely*
On Mon, May 13, 2019 at 11:28:32AM -0400, Robert Haas wrote:
> 1. The comment added in that commit says "Recover may as well remove
> it while replaying..." but what is really meant is "Recovery may well
> remove it well replaying..." The phrase "may as well" means that
> there isn't really any re
On Mon, May 13, 2019 at 10:52:21AM -0700, Andres Freund wrote:
> I was wrong here - I thought we WAL logged the main fork creation even
> for unlogged tables. I think it's foolish that we don't, but we don't.
Why? The main fork is not actually necessary, and the beginning of
recovery would make s
Hi,
On 2019-05-13 13:33:00 -0400, Alvaro Herrera wrote:
> On 2019-May-13, Andres Freund wrote:
>
> > On 2019-05-13 13:07:30 -0400, Alvaro Herrera wrote:
> > > On 2019-May-13, Andres Freund wrote:
>
> > > The first ResetUnloggedRelations call occurs before any WAL is replayed,
> > > so the data d
Hi,
On 2019-05-13 13:21:33 -0400, Alvaro Herrera wrote:
> On 2019-May-13, Robert Haas wrote:
> > If that's the scenario, I'm not sure the smgrimmedsync() call is
> > sufficient. Suppose we log_smgrcreate() but then crash before
> > smgrimmedsync()... seems like we'd need to do them in the other o
On 2019-05-13 13:09:17 -0400, Robert Haas wrote:
> On Mon, May 13, 2019 at 12:50 PM Andres Freund wrote:
> > > AFAICS ResetUnloggedRelations copies the init fork after replaying WAL,
> > > so it would be sufficient to have the init fork be recovered from WAL
> > > for that to work. However, we al
On 2019-May-13, Andres Freund wrote:
> On 2019-05-13 13:07:30 -0400, Alvaro Herrera wrote:
> > On 2019-May-13, Andres Freund wrote:
> > The first ResetUnloggedRelations call occurs before any WAL is replayed,
> > so the data dir certainly still in inconsistent state. At that point,
> > we need t
Hi,
On 2019-05-13 13:07:30 -0400, Alvaro Herrera wrote:
> On 2019-May-13, Andres Freund wrote:
>
> > On 2019-05-13 12:24:05 -0400, Alvaro Herrera wrote:
>
> > > AFAICS ResetUnloggedRelations copies the init fork after replaying WAL,
> > > so it would be sufficient to have the init fork be recove
On 2019-May-13, Robert Haas wrote:
> I think I see what Alvaro is talking about, or at least I think I see
> *a* possible problem based on his remarks.
>
> Suppose we create an unlogged table and then crash. The main fork
> makes it to disk, and the init fork does not. Before WAL replay, we
> re
On Mon, May 13, 2019 at 12:50 PM Andres Freund wrote:
> > AFAICS ResetUnloggedRelations copies the init fork after replaying WAL,
> > so it would be sufficient to have the init fork be recovered from WAL
> > for that to work. However, we also do ResetUnloggedRelations *before*
> > replaying WAL i
On 2019-May-13, Andres Freund wrote:
> On 2019-05-13 12:24:05 -0400, Alvaro Herrera wrote:
> > AFAICS ResetUnloggedRelations copies the init fork after replaying WAL,
> > so it would be sufficient to have the init fork be recovered from WAL
> > for that to work. However, we also do ResetUnlogged
Hi,
On 2019-05-13 12:24:05 -0400, Alvaro Herrera wrote:
> > My guess, just shooting from the hip, is that the smgrimmedsync call
> > can be removed here. If that's wrong, then we need a better
> > explanation for why it's needed, and we possibly need to add it to
> > every single place that does
I agree that the wording "recovery may as well" is incorrect and that
"may well" makes it correct.
On 2019-May-13, Robert Haas wrote:
> My guess, just shooting from the hip, is that the smgrimmedsync call
> can be removed here. If that's wrong, then we need a better
> explanation for why it's ne
On Thu, Dec 8, 2016 at 7:49 PM Michael Paquier
wrote:
> On Fri, Dec 9, 2016 at 4:54 AM, Robert Haas wrote:
> > On Wed, Dec 7, 2016 at 11:20 PM, Michael Paquier
> > wrote:
> >> OK, I rewrote a bit the patch as attached. What do you think?
> >
> > Committed and back-patched all the way back to 9.2
25 matches
Mail list logo
