[COMMITTERS] pgsql: Log the creation of an init fork unconditionally.
Log the creation of an init fork unconditionally. Previously, it was thought that this only needed to be done for the benefit of possible standbys, so wal_level = minimal skipped it. But that's not safe, because during crash recovery we might replay XLOG_DBASE_CREATE or XLOG_TBLSPC_CREATE record which recursively removes the directory that contains the new init fork. So log it always. The user-visible effect of this bug is that if you create a database or tablespace, then create an unlogged table, then crash without checkpointing, then restart, accessing the table will fail, because the it won't have been properly reset. This commit fixes that. Michael Paquier, per a report from Konstantin Knizhnik. Wording of the comments per a suggestion from me. Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/1ed3c6ff9ef411771d4a9fc9a82c3adea0d6ab3b Modified Files -- contrib/bloom/blinsert.c | 13 + src/backend/access/nbtree/nbtree.c| 13 + src/backend/access/spgist/spginsert.c | 23 +-- src/backend/catalog/heap.c| 13 +++-- 4 files changed, 38 insertions(+), 24 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Log the creation of an init fork unconditionally.
Log the creation of an init fork unconditionally. Previously, it was thought that this only needed to be done for the benefit of possible standbys, so wal_level = minimal skipped it. But that's not safe, because during crash recovery we might replay XLOG_DBASE_CREATE or XLOG_TBLSPC_CREATE record which recursively removes the directory that contains the new init fork. So log it always. The user-visible effect of this bug is that if you create a database or tablespace, then create an unlogged table, then crash without checkpointing, then restart, accessing the table will fail, because the it won't have been properly reset. This commit fixes that. Michael Paquier, per a report from Konstantin Knizhnik. Wording of the comments per a suggestion from me. Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/141ad68964f739c6543dc48143829c2cd0dd0c86 Modified Files -- src/backend/access/nbtree/nbtree.c| 13 + src/backend/access/spgist/spginsert.c | 23 +-- src/backend/catalog/heap.c| 13 +++-- 3 files changed, 29 insertions(+), 20 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Log the creation of an init fork unconditionally.
Log the creation of an init fork unconditionally. Previously, it was thought that this only needed to be done for the benefit of possible standbys, so wal_level = minimal skipped it. But that's not safe, because during crash recovery we might replay XLOG_DBASE_CREATE or XLOG_TBLSPC_CREATE record which recursively removes the directory that contains the new init fork. So log it always. The user-visible effect of this bug is that if you create a database or tablespace, then create an unlogged table, then crash without checkpointing, then restart, accessing the table will fail, because the it won't have been properly reset. This commit fixes that. Michael Paquier, per a report from Konstantin Knizhnik. Wording of the comments per a suggestion from me. Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/8e403f2151995595a8f24c6c90adc331a8353289 Modified Files -- src/backend/access/nbtree/nbtree.c| 13 + src/backend/access/spgist/spginsert.c | 23 +-- src/backend/catalog/heap.c| 13 +++-- 3 files changed, 29 insertions(+), 20 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Log the creation of an init fork unconditionally.
Log the creation of an init fork unconditionally. Previously, it was thought that this only needed to be done for the benefit of possible standbys, so wal_level = minimal skipped it. But that's not safe, because during crash recovery we might replay XLOG_DBASE_CREATE or XLOG_TBLSPC_CREATE record which recursively removes the directory that contains the new init fork. So log it always. The user-visible effect of this bug is that if you create a database or tablespace, then create an unlogged table, then crash without checkpointing, then restart, accessing the table will fail, because the it won't have been properly reset. This commit fixes that. Michael Paquier, per a report from Konstantin Knizhnik. Wording of the comments per a suggestion from me. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/fa0f466d5329e10b16f3b38c8eaf5306f7e234e8 Modified Files -- contrib/bloom/blinsert.c | 13 + src/backend/access/nbtree/nbtree.c| 13 + src/backend/access/spgist/spginsert.c | 23 +-- src/backend/catalog/heap.c| 13 +++-- 4 files changed, 38 insertions(+), 24 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Log the creation of an init fork unconditionally.
Log the creation of an init fork unconditionally. Previously, it was thought that this only needed to be done for the benefit of possible standbys, so wal_level = minimal skipped it. But that's not safe, because during crash recovery we might replay XLOG_DBASE_CREATE or XLOG_TBLSPC_CREATE record which recursively removes the directory that contains the new init fork. So log it always. The user-visible effect of this bug is that if you create a database or tablespace, then create an unlogged table, then crash without checkpointing, then restart, accessing the table will fail, because the it won't have been properly reset. This commit fixes that. Michael Paquier, per a report from Konstantin Knizhnik. Wording of the comments per a suggestion from me. Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/68e56eef655af48acc2d171fb724a803debe37f3 Modified Files -- src/backend/access/nbtree/nbtree.c| 13 + src/backend/access/spgist/spginsert.c | 23 +-- src/backend/catalog/heap.c| 13 +++-- 3 files changed, 29 insertions(+), 20 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Log the creation of an init fork unconditionally.
Log the creation of an init fork unconditionally. Previously, it was thought that this only needed to be done for the benefit of possible standbys, so wal_level = minimal skipped it. But that's not safe, because during crash recovery we might replay XLOG_DBASE_CREATE or XLOG_TBLSPC_CREATE record which recursively removes the directory that contains the new init fork. So log it always. The user-visible effect of this bug is that if you create a database or tablespace, then create an unlogged table, then crash without checkpointing, then restart, accessing the table will fail, because the it won't have been properly reset. This commit fixes that. Michael Paquier, per a report from Konstantin Knizhnik. Wording of the comments per a suggestion from me. Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/a00ac62991fc9cce309e40979ca74ad54bf97b15 Modified Files -- src/backend/access/nbtree/nbtree.c| 13 + src/backend/access/spgist/spginsert.c | 23 +-- src/backend/catalog/heap.c| 13 +++-- 3 files changed, 29 insertions(+), 20 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
