> On Jun 16, 2020, at 6:55 AM, amul sul <sulamul@gmail.com> wrote:
>
> (2) if the session is idle, we also need the top-level abort
> record to be written immediately, but can't send an error to the client until the next
> command is issued without losing wire protocol synchronization. For now, we just use
> FATAL to kill the session; maybe this can be improved in the future.
Andres,
I'd like to have a patch that tests the impact of a vacuum running for xid wraparound purposes, blocked on a pinned
pageheld by the cursor, when another session disables WAL. It would be very interesting to test how the vacuum handles
thatspecific change. I have not figured out the cleanest way to do this, though, as we don't as a project yet have a
standardway of setting up xid exhaustion in a regression test, do we? The closest I saw to it was your work in [1],
butthat doesn't seem to have made much headway recently, and is designed for the TAP testing infrastructure, which
isn'tuseable from inside an isolation test. Do you have a suggestion how best to continue developing out the test
infrastructure?
Amul,
The most obvious way to test how your ALTER SYSTEM READ ONLY feature interacts with concurrent sessions is using the
isolationtester in src/test/isolation/, but as it stands now, the first permutation that gets a FATAL causes the test
toabort and all subsequent permutations to not run. Attached patch v34-0009 fixes that.
Attached patch v34-0010 adds a test of cursors opened FOR UPDATE interacting with a system that is set read-only by a
differentsession. The expected output is worth reviewing to see how this plays out. I don't see anything in there
whichis obviously wrong, but some of it is a bit clunky. For example, by the time the client sees an error "FATAL:
WALis now prohibited", the system may already have switched back to read-write. Also, it is a bit strange to get one
ofthese errors on an attempted ROLLBACK. Once again, not wrong as such, but clunky.
[1]
https://www.postgresql.org/message-id/flat/CAP4vRV5gEHFLB7NwOE6_dyHAeVfkvqF8Z_g5GaCQZNgBAE0Frw%40mail.gmail.com#e10861372aec22119b66756ecbac581c
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
