pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix data loss when restarting the bulk_write facility 2+ messages / 1 participants [nested] [flat]
* pgsql: Fix data loss when restarting the bulk_write facility @ 2024-11-22 14:51 Heikki Linnakangas <heikki.linnakangas@iki.fi> 0 siblings, 0 replies; 2+ messages in thread From: Heikki Linnakangas @ 2024-11-22 14:51 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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.gma... Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9695835538c2c8e9cd0048028b8c85e1bbf5c79c Modified Files -------------- src/backend/storage/smgr/bulk_write.c | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
* pgsql: Fix data loss when restarting the bulk_write facility @ 2024-11-22 14:51 Heikki Linnakangas <heikki.linnakangas@iki.fi> 0 siblings, 0 replies; 2+ messages in thread From: Heikki Linnakangas @ 2024-11-22 14:51 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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.gma... Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/ee937f0409d5c75855861bf31f88eeb77623b411 Modified Files -------------- src/backend/storage/smgr/bulk_write.c | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2024-11-22 14:51 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-11-22 14:51 pgsql: Fix data loss when restarting the bulk_write facility Heikki Linnakangas <heikki.linnakangas@iki.fi> 2024-11-22 14:51 pgsql: Fix data loss when restarting the bulk_write facility Heikki Linnakangas <heikki.linnakangas@iki.fi>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox