Re: thinko in basic_archive.c

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

In response to

Browse pgsql-hackers by date

  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