database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-26 12:21:12 +03:00
Code Activity

Check for conflicting queries during replay of gistvacuumpage()

Browse Source 
013ebc0a7b implements so-called GiST microvacuum.  That is gistgettuple() marks
index tuples as dead when kill_prior_tuple is set.  Later, when new tuple
insertion claims page space, those dead index tuples are physically deleted
from page.  When this deletion is replayed on standby, it might conflict with
read-only queries.  But 013ebc0a7b doesn't handle this.  That may lead to
disappearance of some tuples from read-only snapshots on standby.

This commit implements resolving of conflicts between replay of GiST microvacuum
and standby queries.  On the master we implement new WAL record type
XLOG_GIST_DELETE, which comprises necessary information.  On stable releases
we've to be tricky to keep WAL compatibility.  Information required for conflict
processing is just appended to data of XLOG_GIST_PAGE_UPDATE record.  So,
PostgreSQL version, which doesn't know about conflict processing, will just
ignore that.

Reported-by: Andres Freund
Diagnosed-by: Andres Freund
Discussion: https://postgr.es/m/20181212224524.scafnlyjindmrbe6%40alap3.anarazel.de
Author: Alexander Korotkov
Backpatch-through: 9.6
This commit is contained in:
Alexander Korotkov
2018-12-21 02:33:37 +03:00
parent e13d8a783d
commit 1b02807457
5 changed files with 220 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
src/backend/access/gist/gistbuild.c
View File

@ -55,6 +55,7 @@ typedef enum
typedef struct
{
Relation indexrel;
Relation heaprel;
GISTSTATE *giststate;
int64 indtuples; /* number of tuples indexed */
@ -121,6 +122,7 @@ gistbuild(Relation heap, Relation index, IndexInfo *indexInfo)
int fillfactor;
buildstate.indexrel = index;
buildstate.heaprel = heap;
if (index->rd_options)
{
/* Get buffering mode from the options string */
@ -483,7 +485,7 @@ gistBuildCallback(Relation index,
* locked, we call gistdoinsert directly.
*/
gistdoinsert(index, itup, buildstate->freespace,
buildstate->giststate);
buildstate->giststate, buildstate->heaprel);
}
/* Update tuple count and total size. */
@ -689,7 +691,8 @@ gistbufferinginserttuples(GISTBuildState *buildstate, Buffer buffer, int level,
itup, ntup, oldoffnum, &placed_to_blk,
InvalidBuffer,
&splitinfo,
false);
false,
buildstate->heaprel);
/*
* If this is a root split, update the root path item kept in memory. This