diff options
| author | Heikki Linnakangas <heikki.linnakangas@iki.fi> | 2024-11-22 16:28:24 +0200 |
|---|---|---|
| committer | Heikki Linnakangas <heikki.linnakangas@iki.fi> | 2024-11-22 16:28:24 +0200 |
| commit | ee937f0409d5c75855861bf31f88eeb77623b411 (patch) | |
| tree | af4046227495427a8e29d9b3f094a20d05b87039 /src/backend/access/gist | |
| parent | aac831cafa6f3106dfcbd3298757801c299351fc (diff) | |
| download | postgresql-ee937f0409d5c75855861bf31f88eeb77623b411.tar.gz postgresql-ee937f0409d5c75855861bf31f88eeb77623b411.zip | |
Fix data loss when restarting the bulk_write facility
If a user started a bulk write operation on a fork with existing data
to append data in bulk, the bulk_write machinery would zero out all
previously written pages up to the last page written by the new
bulk_write operation.
This is not an issue for PostgreSQL itself, because we never use the
bulk_write facility on a non-empty fork. But there are use cases where
it makes sense. TimescaleDB extension is known to do that to merge
partitions, for example.
Backpatch to v17, where the bulk_write machinery was introduced.
Author: Matthias van de Meent <boekewurm+postgres@gmail.com>
Reported-By: Erik Nordström <erik@timescale.com>
Reviewed-by: Erik Nordström <erik@timescale.com>
Discussion: https://www.postgresql.org/message-id/CACAa4VJ%2BQY4pY7M0ECq29uGkrOygikYtao1UG9yCDFosxaps9g@mail.gmail.com
Diffstat (limited to 'src/backend/access/gist')
0 files changed, 0 insertions, 0 deletions