[WIP] Add extension for wal-g incremental backups

[debebantur]

Here are some reminders before you submit the pull request

• Add tests for the change
• Document changes
• Communicate in the mailing list if needed
• Pass make installcheck
• Review a PR in return to support the community

[Alena0704]

Hi Stepan, thanks for working on this!
A few questions on the design before I look at the code.

1. Why an extension rather than core?
2. How is the record made crash-safe? VACUUM can't run inside a transaction block, so the compaction and the INSERT into possible_vacuum_list are two separate commits. If the server crashes in between, the segfile is already rewritten but the vacuum is not recorded and it will corrupt an incremental backup.
3. Why a new table instead of pg_aoseg? Did you consider deriving info from existing catalog/stats instead of a new table - e.g. pg_stat_all_tables.last_vacuum, or the eof/modcount in pg_aoseg?

Also, I'm worried that the module that installs a utility hook probably shouldn't be installable by a non-superuser.

[reshke]

Hi Stepan, thanks for working on this! A few questions on the design before I look at the code.

1. Why an extension rather than core?

Why vise versa?

2. How is the record made crash-safe? VACUUM can't run inside a transaction block, so the compaction and the INSERT into possible_vacuum_list are two separate commits. If the server crashes in between, the segfile is already rewritten but the vacuum is not recorded and it will corrupt an incremental backup.

Yes, this is for wal-g incremental backup relfilenode invalidation, if vacuum fails after this we dont care. INSERT should go before VACUUM

3. Why a new table instead of pg_aoseg? Did you consider deriving info from existing catalog/stats instead of a new table - e.g. pg_stat_all_tables.last_vacuum, or the eof/modcount in pg_aoseg?

pg_stat doesnt work for exact same issue as in your p.2 . modcount (in some cases eof too) in pg_aoseg do not change in usable way after vacuum and we learned this hard way.

Also, I'm worried that the module that installs a utility hook probably shouldn't be installable by a non-superuser.

I'm not. pg_start_backup is already very hazardous if running user is not superuser. Also, if you have access to datadir on fs you better be superuser