Remove unnecessary smgrimmedsync() when creating unlogged table.
This became safe after commit 4b4798e138
. The smgrcreate() call will
now register the segment for syncing at the next checkpoint, so we
don't need to sync it here. If a checkpoint happens before the
creation is WAL-logged, the records will be replayed when starting
recovery from the checkpoint. If a checkpoint happens after the WAL
logging, the checkpoint will fsync() it.
In the passing, clarify a comment in smgrDoPendingSyncs().
Discussion: https://www.postgresql.org/message-id/6e5bbc08-cdfc-b2b3-9e23-1a914b9850a9%40iki.fi
Reviewed-by: Robert Haas
This commit is contained in:
parent
b0ec61c9c2
commit
18724af9e8
|
@ -606,12 +606,9 @@ heapam_relation_set_new_filelocator(Relation rel,
|
|||
|
||||
/*
|
||||
* If required, set up an init fork for an unlogged table so that it can
|
||||
* be correctly reinitialized on restart. An immediate sync is required
|
||||
* even if the page has been logged, because the write did not go through
|
||||
* shared_buffers and therefore a concurrent checkpoint may have moved the
|
||||
* redo pointer past our xlog record. Recovery may as well remove it
|
||||
* while replaying, for example, XLOG_DBASE_CREATE* or XLOG_TBLSPC_CREATE
|
||||
* record. Therefore, logging is necessary even if wal_level=minimal.
|
||||
* be correctly reinitialized on restart. Recovery may remove it while
|
||||
* replaying, for example, an XLOG_DBASE_CREATE* or XLOG_TBLSPC_CREATE
|
||||
* record. Therefore, logging is necessary even if wal_level=minimal.
|
||||
*/
|
||||
if (persistence == RELPERSISTENCE_UNLOGGED)
|
||||
{
|
||||
|
@ -620,7 +617,6 @@ heapam_relation_set_new_filelocator(Relation rel,
|
|||
rel->rd_rel->relkind == RELKIND_TOASTVALUE);
|
||||
smgrcreate(srel, INIT_FORKNUM, false);
|
||||
log_smgrcreate(newrlocator, INIT_FORKNUM);
|
||||
smgrimmedsync(srel, INIT_FORKNUM);
|
||||
}
|
||||
|
||||
smgrclose(srel);
|
||||
|
|
|
@ -764,7 +764,7 @@ smgrDoPendingSyncs(bool isCommit, bool isParallelWorker)
|
|||
/*
|
||||
* We emit newpage WAL records for smaller relations.
|
||||
*
|
||||
* Small WAL records have a chance to be emitted along with other
|
||||
* Small WAL records have a chance to be flushed along with other
|
||||
* backends' WAL records. We emit WAL records instead of syncing for
|
||||
* files that are smaller than a certain threshold, expecting faster
|
||||
* commit. The threshold is defined by the GUC wal_skip_threshold.
|
||||
|
|
Loading…
Reference in New Issue