Matthias van de Meent
Matthias van de Meent
> Simplified version of this rule: always redo all pages for wal records with multiple blocks. That would cause IO in redo, and we usually prefer to not do any...
@microsoft-github-policy-service agree company="Neon, Inc."
Fail-proof rollback code has not been released yet (introduced only with #12202), so I don't think we can safely default to 1.6 yet.
> I'm wondering if the metric names should be more human readable: > > `compute_transactions_since_last_vacuum_count` That's totally wrong. `datfrozenxid` is the xid before which all transaction IDs have been removed/frozen...
> how long it has been since a vacuum has run on those dbs. ... since a VACUUM has run on the least-recently-vacuumed table of that database; and even then...
CC @knizhnik My thoughts on improving the overall performance of our lastWrittenLsn infrastructure. This would lower the chance of an unnecessarily high lastWrittenLsn and thus having to wait for WAL.
Some more analysis on the "Probabilistic lastWrittenLsn": 1. Because a bucket's value is the largest of all blocks that hash to that bucket, the order of insertion doesn't matter for...
> 2. Backpressure. Right now lag between pageserver and compute is limited by 15Mb. It is just 2000 pages. I disagree with this calculation. Records that modify a page only...
Can't you just filter CREATE SCHEMA statements from the output?
Unrelated to the above: please use `--no-` instead of `---no-`, as that is easier to understand.