On 9/10/25 00:41, Ellen Allhatatlan wrote:
> Hi, and thanks for your input,
>
>> The author brings up threaded vs multi-process. That's an old old old old old conversation that has been shown there
isno clear better way.
>
> This is where things become interesting. Firebird actually has 3
> process/threading models - and they manage to maintain these with a
> team that is *_much_* smaller than the PostgreSQL one - FB is a minnow
> compared to PG!
Though I would like to know what happened in mid 2010?:
https://github.com/FirebirdSQL/firebird/graphs/contributors
>
>> Backup argument is cherry picking and not discussing pgBackrest and other solutions or the use of tablespaces to
isolatedatabases in a cluster at the disk layer or disk snapshots.
>
> OK again. I'm just wondering if the single file per database isn't a
> fundamental architectural flaw in itself? AIUI, you could have
> mulitple files (back in 32-bit land) "chained" - but (again AIUI) the
> same table could be spread over x files - all "intermingled"... weird.
>
What are you referring to above?
At any rate from the article:
"pg_basebackup always dumps the entire cluster, when restoring one
database, your entire PostgreSQL cluster will be restored, which will
contain only one database. The files of all your other databases will be
zero size."
AFAIK there is no option to restore one database with pg_basebackup.
I think the author is referring to pgBackRest:
https://pgbackrest.org/user-guide.html#restore/option-db-include
" The test1 database, despite successful recovery, is not accessible.
This is because the entire database was restored as sparse, zeroed files."
--
Adrian Klaver
adrian.klaver@aklaver.com
