Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitf01011c

Browse files
committed
Merge branch 'master' into anyelement
2 parentsc9aa996 +fba12c8 commitf01011c

File tree

8 files changed

+95
-144
lines changed

8 files changed

+95
-144
lines changed

‎doc/src/sgml/postgres-fdw.sgml

Lines changed: 12 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -309,8 +309,8 @@
309309
using <xref linkend="sql-importforeignschema">. This command creates
310310
foreign table definitions on the local server that match tables or
311311
views present on the remote server. If the remote tables to be imported
312-
have columns of user-defined data types, the local server must have types
313-
of the same names.
312+
have columns of user-defined data types, the local server must have
313+
compatible typesof the same names.
314314
</para>
315315

316316
<para>
@@ -361,9 +361,16 @@
361361

362362
<para>
363363
Note that constraints other than <literal>NOT NULL</> will never be
364-
imported from the remote tables, since <productname>PostgreSQL</>
365-
does not support any other type of constraint on a foreign table.
366-
Checking other types of constraints is always left to the remote server.
364+
imported from the remote tables. Although <productname>PostgreSQL</>
365+
does support <literal>CHECK</> constraints on foreign tables, there is no
366+
provision for importing them automatically, because of the risk that a
367+
constraint expression could evaluate differently on the local and remote
368+
servers. Any such inconsistency in the behavior of a <literal>CHECK</>
369+
constraint could lead to hard-to-detect errors in query optimization.
370+
So if you wish to import <literal>CHECK</> constraints, you must do so
371+
manually, and you should verify the semantics of each one carefully.
372+
For more detail about the treatment of <literal>CHECK</> constraints on
373+
foreign tables, see <xref linkend="sql-createforeigntable">.
367374
</para>
368375
</sect3>
369376
</sect2>

‎src/backend/access/brin/brin_pageops.c

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -55,7 +55,7 @@ brin_doupdate(Relation idxrel, BlockNumber pagesPerRange,
5555
Buffernewbuf;
5656
boolextended= false;
5757

58-
newsz=MAXALIGN(newsz);
58+
Assert(newsz==MAXALIGN(newsz));
5959

6060
/* make sure the revmap is long enough to contain the entry we need */
6161
brinRevmapExtend(revmap,heapBlk);
@@ -273,7 +273,7 @@ brin_doinsert(Relation idxrel, BlockNumber pagesPerRange,
273273
ItemPointerDatatid;
274274
boolextended= false;
275275

276-
itemsz=MAXALIGN(itemsz);
276+
Assert(itemsz==MAXALIGN(itemsz));
277277

278278
/* Make sure the revmap is long enough to contain the entry we need */
279279
brinRevmapExtend(revmap,heapBlk);

‎src/backend/access/brin/brin_tuple.c

Lines changed: 11 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -103,9 +103,10 @@ brin_form_tuple(BrinDesc *brdesc, BlockNumber blkno, BrinMemTuple *tuple,
103103

104104
Assert(brdesc->bd_totalstored>0);
105105

106-
values=palloc(sizeof(Datum)*brdesc->bd_totalstored);
107-
nulls=palloc0(sizeof(bool)*brdesc->bd_totalstored);
108-
phony_nullbitmap=palloc(sizeof(bits8)*BITMAPLEN(brdesc->bd_totalstored));
106+
values= (Datum*)palloc(sizeof(Datum)*brdesc->bd_totalstored);
107+
nulls= (bool*)palloc0(sizeof(bool)*brdesc->bd_totalstored);
108+
phony_nullbitmap= (bits8*)
109+
palloc(sizeof(bits8)*BITMAPLEN(brdesc->bd_totalstored));
109110

110111
/*
111112
* Set up the values/nulls arrays for heap_fill_tuple
@@ -144,6 +145,9 @@ brin_form_tuple(BrinDesc *brdesc, BlockNumber blkno, BrinMemTuple *tuple,
144145
values[idxattno++]=tuple->bt_columns[keyno].bv_values[datumno];
145146
}
146147

148+
/* Assert we did not overrun temp arrays */
149+
Assert(idxattno <=brdesc->bd_totalstored);
150+
147151
/* compute total space needed */
148152
len=SizeOfBrinTuple;
149153
if (anynulls)
@@ -160,12 +164,15 @@ brin_form_tuple(BrinDesc *brdesc, BlockNumber blkno, BrinMemTuple *tuple,
160164

161165
data_len=heap_compute_data_size(brtuple_disk_tupdesc(brdesc),
162166
values,nulls);
163-
164167
len+=data_len;
165168

169+
len=MAXALIGN(len);
170+
166171
rettuple=palloc0(len);
167172
rettuple->bt_blkno=blkno;
168173
rettuple->bt_info=hoff;
174+
175+
/* Assert that hoff fits in the space available */
169176
Assert((rettuple->bt_info&BRIN_OFFSET_MASK)==hoff);
170177

171178
/*

‎src/backend/access/heap/README.tuplock

Lines changed: 10 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -100,11 +100,12 @@ that pg_multixact needs to retain pages of its data until we're certain that
100100
the MultiXacts in them are no longer of interest.
101101

102102
VACUUM is in charge of removing old MultiXacts at the time of tuple freezing.
103-
This works in the same way that pg_clog segments are removed: we have a
104-
pg_class column that stores the earliest multixact that could possibly be
105-
stored in the table; the minimum of all such values is stored in a pg_database
106-
column. VACUUM computes the minimum across all pg_database values, and
107-
removes pg_multixact segments older than the minimum.
103+
The lower bound used by vacuum (that is, the value below which all multixacts
104+
are removed) is stored as pg_class.relminmxid for each table; the minimum of
105+
all such values is stored in pg_database.datminmxid. The minimum across
106+
all databases, in turn, is recorded in checkpoint records, and CHECKPOINT
107+
removes pg_multixact/ segments older than that value once the checkpoint
108+
record has been flushed.
108109

109110
Infomask Bits
110111
-------------
@@ -124,14 +125,15 @@ The following infomask bits are applicable:
124125
the XMAX is a plain Xid that locked the tuple, as well.
125126

126127
- HEAP_XMAX_KEYSHR_LOCK
128+
- HEAP_XMAX_SHR_LOCK
127129
- HEAP_XMAX_EXCL_LOCK
128130
These bits indicate the strength of the lock acquired; they are useful when
129131
the XMAX is not a MultiXactId. If it's a multi, the info is to be found in
130132
the member flags. If HEAP_XMAX_IS_MULTI is not set and HEAP_XMAX_LOCK_ONLY
131133
is set, then one of these *must* be set as well.
132-
Note there is no infomask bit for a SELECT FOR SHARE lock. Also there is no
133-
separate bit for a SELECTFOR NO KEY UPDATElock; this is implemented by the
134-
HEAP_KEYS_UPDATED bit.
134+
135+
Note that HEAP_XMAX_EXCL_LOCK does not distinguishFOR NO KEY UPDATEfrom
136+
FOR UPDATE; this is implemented by theHEAP_KEYS_UPDATED bit.
135137

136138
- HEAP_KEYS_UPDATED
137139
This bit lives in t_infomask2. If set, indicates that the XMAX updated

‎src/backend/executor/nodeIndexscan.c

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -532,10 +532,18 @@ ExecReScanIndexScan(IndexScanState *node)
532532
}
533533
node->iss_RuntimeKeysReady= true;
534534

535+
/* flush the reorder queue */
536+
if (node->iss_ReorderQueue)
537+
{
538+
while (!pairingheap_is_empty(node->iss_ReorderQueue))
539+
reorderqueue_pop(node);
540+
}
541+
535542
/* reset index scan */
536543
index_rescan(node->iss_ScanDesc,
537544
node->iss_ScanKeys,node->iss_NumScanKeys,
538545
node->iss_OrderByKeys,node->iss_NumOrderByKeys);
546+
node->iss_ReachedEnd= false;
539547

540548
ExecScanReScan(&node->ss);
541549
}

‎src/backend/utils/adt/jsonb_util.c

Lines changed: 9 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -509,8 +509,8 @@ fillJsonbValue(JsonbContainer *container, int index,
509509
* "raw scalar" pseudo array to append it - the actual scalar should be passed
510510
* next and it will be added as the only member of the array.
511511
*
512-
*Values of typejvbBinary,which are rolled up arrays and objects,
513-
* are unpacked before being added to the result.
512+
*All non-scalar types (jvbBinary,jbvArray and jbvObject) passed as
513+
*elements or valuesare unpacked before being added to the result.
514514
*/
515515
JsonbValue*
516516
pushJsonbValue(JsonbParseState**pstate,JsonbIteratorTokenseq,
@@ -522,14 +522,18 @@ pushJsonbValue(JsonbParseState **pstate, JsonbIteratorToken seq,
522522
JsonbIteratorTokentok;
523523

524524
if (!jbval|| (seq!=WJB_ELEM&&seq!=WJB_VALUE)||
525-
jbval->type!=jbvBinary)
525+
IsAJsonbScalar(jbval))
526526
{
527527
/* drop through */
528528
returnpushJsonbValueScalar(pstate,seq,jbval);
529529
}
530530

531-
/* unpack the binary and add each piece to the pstate */
532-
it=JsonbIteratorInit(jbval->val.binary.data);
531+
/* unpack the data and add each piece to the pstate */
532+
if (jbval->type==jbvBinary)
533+
it=JsonbIteratorInit(jbval->val.binary.data);
534+
else
535+
it=JsonbIteratorInit(jbval);
536+
533537
while ((tok=JsonbIteratorNext(&it,&v, false))!=WJB_DONE)
534538
res=pushJsonbValueScalar(pstate,tok,
535539
tok<WJB_BEGIN_ARRAY ?&v :NULL);

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp