| From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
|---|---|
| To: | David Steele <david(at)pgbackrest(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, solai v <solai(dot)cdac(at)gmail(dot)com> |
| Subject: | Re: Return pg_control from pg_backup_stop(). |
| Date: | 2026-10-23 15:47:24 |
| Message-ID: | 50308898-7fad-40d5-88dd-fa657938c2fe@iki.fi |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 23/10/2026 15:42, David Steele wrote:
> On 10/21/26 15:07, David Steele wrote:
>> Patch has been rebased.
>
> A committer pointed out to me that part of this patch fixes a bug and
> could be back-patched, so it should be separate.
>
> Patch 01 now fixes only the possibility of a torn pg_control file.
Looks good to me.
> It makes the copy out of memory to reduce the time the lock is held,
> but it could alternately read the pg_control file in the lock as was
> done by Thomas in c558e6fd92f. If the consensus is that the latter
> approach is preferred I'm happy to make that change.
+0.5 for following the example of c558e6fd92f. This isn't
performance-sensitive so that aspect doesn't matter. But it seems a
little surprising if a backup might have more up-to-date values of some
fields than what the SQL functions show.
- Heikki
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dongpo Liu | 2026-10-23 15:54:52 | Re: pg_*_advice: tsv load failure, etc. |
| Previous Message | Tom Lane | 2026-10-23 15:36:19 | Re: [PG19] Hash join writes null-keyed outer rows to temp files |