Re: Review for GetWALAvailability()

Alvaro Herrera <alvherre@2ndquadrant.com>

From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2020-06-25T03:57:18Z
Lists: pgsql-hackers
On 2020-Jun-25, Fujii Masao wrote:

> 	/*
> 	 * Find the oldest extant segment file. We get 1 until checkpoint removes
> 	 * the first WAL segment file since startup, which causes the status being
> 	 * wrong under certain abnormal conditions but that doesn't actually harm.
> 	 */
> 	oldestSeg = XLogGetLastRemovedSegno() + 1;
> 
> I see the point of the above comment, but this can cause wal_status to be
> changed from "lost" to "unreserved" after the server restart. Isn't this
> really confusing? At least it seems better to document that behavior.

Hmm.

> Or if we *can ensure* that the slot with invalidated_at set always means
> "lost" slot, we can judge that wal_status is "lost" without using fragile
> XLogGetLastRemovedSegno(). Thought?

Hmm, this sounds compelling -- I think it just means we need to ensure
we reset invalidated_at to zero if the slot's restart_lsn is set to a
correct position afterwards.  I don't think we have any operation that
does that, so it should be safe -- hopefully I didn't overlook anything?
Neither copy nor advance seem to work with a slot that has invalid
restart_lsn.

> Or XLogGetLastRemovedSegno() should be fixed so that it returns valid
> value even after the restart?

This seems more work to implement.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Commits

  1. Persist slot invalidation correctly

  2. Adjust max_slot_wal_keep_size behavior per review

  3. Save slot's restart_lsn when invalidated due to size

  4. Fix issues in invalidation of obsolete replication slots.