Re: [Patch] ALTER SYSTEM READ ONLY

From: Amul Sul <sulamul(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Prabhat Sahu <prabhat(dot)sahu(at)enterprisedb(dot)com>
Subject: Re: [Patch] ALTER SYSTEM READ ONLY
Date: 2021-08-31 12:15:40
Message-ID: CAAJ_b96cyJzeU-zxM9uOSdANVcXcnorN3o2uVpHUQHrQ3ahOsw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Attached is the rebased version for the latest master head. Also,
added tap tests to test some part of this feature and a separate patch
to test recovery_end_command execution.

I have also been through Prabhat's patch which helps me to write
current tests, but I am not sure about the few basic tests that he
included in the tap test which can be done using pg_regress otherwise,
e.g. checking permission to execute the pg_prohibit_wal() function.
Those basic tests I am yet to add, is it ok to add those tests in
pg_regress instead of TAP? The problem I see is that all the tests
covering a feature will not be together, which I think is not correct.

What is usual practice, can have a few tests in TAP and a few in
pg_regress for the same feature?

Regards,
Amul

On Wed, Aug 4, 2021 at 6:26 PM Amul Sul <sulamul(at)gmail(dot)com> wrote:
>
> Attached is the rebase version on top of the latest master head
> includes refactoring patches posted by Robert.
>
> On Thu, Jul 29, 2021 at 9:46 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >
> > On Wed, Jul 28, 2021 at 7:33 AM Amul Sul <sulamul(at)gmail(dot)com> wrote:
> > > I was too worried about how I could miss that & after thinking more
> > > about that, I realized that the operation for ArchiveRecoveryRequested
> > > is never going to be skipped in the startup process and that never
> > > left for the checkpoint process to do that later. That is the reason
> > > that assert was added there.
> > >
> > > When ArchiveRecoveryRequested, the server will no longer be in
> > > the wal prohibited mode, we implicitly change the state to
> > > wal-permitted. Here is the snip from the 0003 patch:
> >
> > Ugh, OK. That makes sense, but I'm still not sure that I like it. I've
> > kind of been wondering: why not have XLogAcceptWrites() be the
> > responsibility of the checkpointer all the time, in every case? That
> > would require fixing some more things, and this is one of them, but
> > then it would be consistent, which means that any bugs would be likely
> > to get found and fixed. If calling XLogAcceptWrites() from the
> > checkpointer is some funny case that only happens when the system
> > crashes while WAL is prohibited, then we might fail to notice that we
> > have a bug.
> >
>
> Unfortunately, I didn't get much time to think about this and don't
> have a strong opinion on it either.
>
> > This is especially true given that we have very little test coverage
> > in this area. Andres was ranting to me about this earlier this week,
> > and I wasn't sure he was right, but then I noticed that we have
> > exactly zero tests in the entire source tree that make use of
> > recovery_end_command. We really need a TAP test for that, I think.
> > It's too scary to do much reorganization of the code without having
> > any tests at all for the stuff we're moving around. Likewise, we're
> > going to need TAP tests for the stuff that is specific to this patch.
> > For example, we should have a test that crashes the server while it's
> > read only, brings it back up, checks that we still can't write WAL,
> > then re-enables WAL, and checks that we now can write WAL. There are
> > probably a bunch of other things that we should test, too.
> >
>
> Yes, my next plan is to work on the TAP tests and look into the patch
> posted by Prabhat to improve test coverage.
>
> Regards,
> Amul Sul

Attachment Content-Type Size
v32-0009-Test-check-recovery_end_command-execution.patch application/x-patch 1.6 KB
v32-0007-Documentation.patch application/x-patch 10.4 KB
v32-0008-Test-Few-tap-tests-for-wal-prohibited-system.patch application/x-patch 6.0 KB
v32-0005-Implement-wal-prohibit-state-using-global-barrie.patch application/x-patch 52.5 KB
v32-0006-Error-or-Assert-before-START_CRIT_SECTION-for-WA.patch application/x-patch 68.4 KB
v32-0004-Refactor-add-function-to-set-database-state-in-c.patch application/x-patch 3.1 KB
v32-0003-Create-XLogAcceptWrites-function-with-code-from-.patch application/x-patch 3.8 KB
v32-0002-Postpone-some-end-of-recovery-operations-relatin.patch application/x-patch 3.3 KB
v32-0001-Refactor-some-end-of-recovery-code-out-of-Startu.patch application/x-patch 14.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2021-08-31 12:21:50 Re: pg_receivewal starting position
Previous Message Joe Conway 2021-08-31 12:05:45 Re: Returning to Postgres community work