Horton

Re: Race condition in recovery?

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: Dilip Kumar <dilipbalaut@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, hlinnaka <hlinnaka@iki.fi>
Date: 2021-06-01T20:45:52Z
Lists: pgsql-hackers 
On Fri, May 28, 2021 at 2:05 AM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
> Mmmm.  That looks like meaning that we don't intend to support the
> Dilip's case, and means that we support the use of
> archive-command-copies-only-other-than-wal-segments?

Actually, I think Dilip's case ought to be supported, but I also think
that somebody else might disagree, so it's better for me if the test
doesn't need to rely on it.

> Agreed. I often annoyed by a long-lasting TAP script when I wanted to
> do one of the test items in it. However, I was not sure which is our
> policy here, consolidating all related tests into one script or having
> separate scripts containing tests up to a "certain" number or a set of
> tests that would take a certain time, or limiting by number the of
> lines.  I thought that we are on the first way as I have told several
> times to put new tests into an existing script.

Different people might have different opinions about this, but my
opinion is that when it's possible to combine the test cases in a way
that feels natural, it's good to do. For example if I have two tests
that require the same setup and teardown but do different things in
the middle, and if those things seem related, then it's great to set
up once, try both things, and tear down once. However I don't support
combining test cases where it's just concatenating them one after
another, because that sort of thing seems to have no benefit. Fewer
files in the source tree is not a goal of itself.

> No. Thanks for the words, Robert. I might be a bit too naive, but I
> had an anxious feeling that I might have been totally pointless or my
> words might have been too cryptic/broken (my fingers are quite fat),
> or I might have done something wrong or anything other.  Anyway I
> thought I might have done something wrong here.

No, I don't think so. I think the difficulty is more that the three of
us who are mostly involved in this conversation all have different
native languages, and we are trying to discuss an issue which is very
subtle. Sometimes I am having difficulty understanding precisely what
either you or Dilip are intending to say, and it would not surprise me
to learn that there are difficulties in the other direction also. If
we seem to be covering the same topics multiple times or if any
important points seem to be getting ignored, that's probably the
reason.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

Commits

  1. Further refinement of stuck_on_old_timeline recovery test

  2. Adjust new test case to set wal_keep_segments.

  3. Adjust new test case to set wal_keep_size.

  4. Fix corner case failure of new standby to follow new primary.

  5. Back-port a few PostgresNode.pm methods.

  6. Allow PostgresNode.pm's backup method to accept backup_options.

  7. Add end-to-end testing of pg_basebackup's tar-format output.

  8. Allow PostgresNode.pm tests to wait for catchup

  9. Delay reading timeline history file until it's fetched from master.