fix: only showing LSN for static computes in neon endpoint list

[thesuhas]

Problem

neon endpoint list shows a different LSN than what the state of the replica is. This is mainly down to what we define as LSN in this output. If we define it as the LSN that a compute was started with, it only makes sense to show it for static computes.

Summary of changes

Removed the output of last_record_lsn for primary/hot standby computes.

Closes: #5825

[github-actions]

If this PR added a GUC in the Postgres fork or neon extension,
please regenerate the Postgres settings in the cloud repo:

make NEON_WORKDIR=path/to/neon/checkout \
  -C goapp/internal/shareddomain/postgres generate

If you're an external contributor, a Neon employee will assist in
making sure this step is done.

[MMeent]

If we define it as the LSN that a compute was started with, it only makes sense to show it for static computes.

That doesn't make sense at all. We can know what LSN a read-only compute started with, why hide it?

[thesuhas]

If we define it as the LSN that a compute was started with, it only makes sense to show it for static computes.

That doesn't make sense at all. We can know what LSN a read-only compute started with, why hide it?

From my understanding, the LSN currently being shown is the last_record_lsn which specifies the last LSN persisted to the disk.
When it comes to read-only computes that are not static, how do you get the LSN that it starts from? This only contains info that a compute was started at if it is a read-only static compute. There are no LSNs in the TimelineInfo that specify the LSN that a compute was started at (if it is not static).

[MMeent]

Not in TLI, no, but the logs of the compute will contain the LSN of the basebackup (which is as good as the last_record_lsn)

But why change this? I don't get the need to hide this info?

neon endpoint list shows a different LSN than what the state of the replica is.

I'd say that's expected; data will change while you're still receiving it. We can't instantly teleport data into the terminal, but I think this is the next best thing.

[thesuhas]

Not in TLI, no, but the logs of the compute will contain the LSN of the basebackup (which is as good as the last_record_lsn)

But why change this? I don't get the need to hide this info?

neon endpoint list shows a different LSN than what the state of the replica is.

I'd say that's expected; data will change while you're still receiving it. We can't instantly teleport data into the terminal, but I think this is the next best thing.

I think it stemmed from the fact that what the LSN table means differs based on the type of compute, as discussed here.
I'm open to either, based on whatever is determined to be most appropriate.

[hlinnaka]

I agree that displaying pageserver's last_record_lsn for a replica makes little sense. It's very misleading if the replica is lagging behind.

If we can easily display the last replay LSN (i.e. select pg_last_wal_replay_lsn ()), that would be best. For consistency with that, though, it'd then be nice to show last written LSN for the primary, rather than the pageserver's last_record_lsn.

If that's non-trivial, then I agree it's better to hide the LSN field than display a misleading value like we do today.

[skyzh]

If we can easily display the last replay LSN

Then we need to use Postgres client to do that. I don't think it's trivial. And given the neon_local tool is supposed to replicate the real cplane, and cplane doesn't have/use this functionality, I'd rather just hide the field.

[skyzh]

And we can also have inactive primary/hotstandbys in the list, which we cannot connect with psql...

[github-actions]

7755 tests run: 7375 passed, 0 failed, 380 skipped (full report)

---

Flaky tests (4)

Postgres 17

• test_crafted_wal_end[vanilla-last_wal_record_crossing_segment]: release-x86-64-with-lfc
• test_location_conf_churn[2]: release-x86-64-without-lfc
• test_tx_abort_with_many_relations[v2]: release-arm64-with-lfc

Postgres 15

• test_tx_abort_with_many_relations[v2]: release-arm64-with-lfc

Code coverage* (full report)

• functions: 32.8% (8638 of 26360 functions)
• lines: 48.6% (72947 of 150077 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
5e90b06 at 2025-02-25T19:33:05.457Z :recycle:}

[ololobus]

LGTM, unless there are strong objections, but looks like Chi and Heikki +1'ed as well

Showing it for primary and replica is more confusing than useful. And making to to follow the actual compute LSN is tricky