Skip to content

Commit d638aee

Browse files
committed
Fix ALTER TABLE ... SET TABLESPACE for unlogged relations.
Changing the tablespace of an unlogged relation did not WAL log the creation and content of the init fork. Thus, after a standby is promoted, unlogged relation cannot be accessed anymore, with errors like: ERROR: 58P01: could not open file "pg_tblspc/...": No such file or directory Additionally the init fork was not synced to disk, independent of the configured wal_level, a relatively small durability risk. Investigation of that problem also brought to light that, even for permanent relations, the creation of !main forks was not WAL logged, i.e. no XLOG_SMGR_CREATE record were emitted. That mostly turns out not to be a problem, because these files were created when the actual relation data is copied; nonexistent files are not treated as an error condition during replay. But that doesn't work for empty files, and generally feels a bit haphazard. Luckily, outside init and main forks, empty forks don't occur often or are not a problem. Add the required WAL logging and syncing to disk. Reported-By: Michael Paquier Author: Michael Paquier and Andres Freund Discussion: 20151210163230.GA11331@alap3.anarazel.de Backpatch: 9.1, where unlogged relations were introduced
1 parent 09824cd commit d638aee

File tree

1 file changed

+22
-2
lines changed

1 file changed

+22
-2
lines changed

src/backend/commands/tablecmds.c

Lines changed: 22 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -42,6 +42,7 @@
4242
#include "catalog/pg_type.h"
4343
#include "catalog/pg_type_fn.h"
4444
#include "catalog/storage.h"
45+
#include "catalog/storage_xlog.h"
4546
#include "catalog/toasting.h"
4647
#include "commands/cluster.h"
4748
#include "commands/comment.h"
@@ -9211,6 +9212,15 @@ ATExecSetTableSpace(Oid tableOid, Oid newTableSpace, LOCKMODE lockmode)
92119212
if (smgrexists(rel->rd_smgr, forkNum))
92129213
{
92139214
smgrcreate(dstrel, forkNum, false);
9215+
9216+
/*
9217+
* WAL log creation if the relation is persistent, or this is the
9218+
* init fork of an unlogged relation.
9219+
*/
9220+
if (rel->rd_rel->relpersistence == RELPERSISTENCE_PERMANENT ||
9221+
(rel->rd_rel->relpersistence == RELPERSISTENCE_UNLOGGED &&
9222+
forkNum == INIT_FORKNUM))
9223+
log_smgrcreate(&newrnode, forkNum);
92149224
copy_relation_data(rel->rd_smgr, dstrel, forkNum,
92159225
rel->rd_rel->relpersistence);
92169226
}
@@ -9427,6 +9437,7 @@ copy_relation_data(SMgrRelation src, SMgrRelation dst,
94279437
char *buf;
94289438
Page page;
94299439
bool use_wal;
9440+
bool copying_initfork;
94309441
BlockNumber nblocks;
94319442
BlockNumber blkno;
94329443

@@ -9439,11 +9450,20 @@ copy_relation_data(SMgrRelation src, SMgrRelation dst,
94399450
buf = (char *) palloc(BLCKSZ);
94409451
page = (Page) buf;
94419452

9453+
/*
9454+
* The init fork for an unlogged relation in many respects has to be
9455+
* treated the same as normal relation, changes need to be WAL logged and
9456+
* it needs to be synced to disk.
9457+
*/
9458+
copying_initfork = relpersistence == RELPERSISTENCE_UNLOGGED &&
9459+
forkNum == INIT_FORKNUM;
9460+
94429461
/*
94439462
* We need to log the copied data in WAL iff WAL archiving/streaming is
94449463
* enabled AND it's a permanent relation.
94459464
*/
9446-
use_wal = XLogIsNeeded() && relpersistence == RELPERSISTENCE_PERMANENT;
9465+
use_wal = XLogIsNeeded() &&
9466+
(relpersistence == RELPERSISTENCE_PERMANENT || copying_initfork);
94479467

94489468
nblocks = smgrnblocks(src, forkNum);
94499469

@@ -9498,7 +9518,7 @@ copy_relation_data(SMgrRelation src, SMgrRelation dst,
94989518
* wouldn't replay our earlier WAL entries. If we do not fsync those pages
94999519
* here, they might still not be on disk when the crash occurs.
95009520
*/
9501-
if (relpersistence == RELPERSISTENCE_PERMANENT)
9521+
if (relpersistence == RELPERSISTENCE_PERMANENT || copying_initfork)
95029522
smgrimmedsync(dst, forkNum);
95039523
}
95049524

0 commit comments

Comments
 (0)