From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | robertmhaas(at)gmail(dot)com |
Cc: | bharath(dot)rupireddyforpostgres(at)gmail(dot)com, nathandbossart(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: thinko in basic_archive.c |
Date: | 2022-10-20 00:41:28 |
Message-ID: | 20221020.094128.2063938937614066769.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Wed, 19 Oct 2022 10:48:03 -0400, Robert Haas <robertmhaas(at)gmail(dot)com> wrote in
> On Tue, Oct 18, 2022 at 11:28 PM Kyotaro Horiguchi
> <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> > > > Yeah, leaving a potentially unbounded number of files around after
> > > > system crashes seems pretty unfriendly. I'm not sure how to fix that,
> > > > exactly.
> >
> > Unbounded number of sequential crash-restarts itself is a more serious
> > problem..
(Sorry, this was just a kidding.)
> They don't have to be sequential. Garbage could accumulate over weeks,
> months, or years.
Sure. Users' archive cleanup facilities don't work if they only
handles the files that with legit WAL file names.
> Anyway, I agree we should hope that the system doesn't crash often,
> but we cannot prevent the system administrator from removing the power
> whenever they like. We can however try to reduce the number of
> database-related things that go wrong if this happens, and I think we
> should. Bharath's patch seems like it's probably a good idea, and if
> we can do better, we should.
Yeah, I don't deny this, rather agree. So, we should name temporary
files so that they are identifiable as garbage unconditionally at the
next startup. (They can be being actually active otherwise.)
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2022-10-20 00:56:58 | Re: GUC values - recommended way to declare the C variables? |
Previous Message | Robert Haas | 2022-10-19 23:47:24 | Re: Logical WAL sender unresponsive during decoding commit |