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

Commitf4e9a02

Browse files
committed
Merge branch 'REL9_5_STABLE' into PGPRO9_5
Conflicts:doc/src/sgml/ddl.sgml
2 parentsf4948f2 +1651b9a commitf4e9a02

File tree

21 files changed

+600
-305
lines changed

21 files changed

+600
-305
lines changed

‎contrib/pgrowlocks/pgrowlocks.c

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -158,8 +158,7 @@ pgrowlocks(PG_FUNCTION_ARGS)
158158

159159
values[Atnum_ismulti]=pstrdup("true");
160160

161-
allow_old= !(infomask&HEAP_LOCK_MASK)&&
162-
(infomask&HEAP_XMAX_LOCK_ONLY);
161+
allow_old=HEAP_LOCKED_UPGRADED(infomask);
163162
nmembers=GetMultiXactIdMembers(xmax,&members,allow_old,
164163
false);
165164
if (nmembers==-1)

‎doc/src/sgml/catalogs.sgml

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -8892,6 +8892,16 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
88928892
null if no expiration</entry>
88938893
</row>
88948894

8895+
<row>
8896+
<entry><structfield>rolbypassrls</structfield></entry>
8897+
<entry><type>bool</type></entry>
8898+
<entry></entry>
8899+
<entry>
8900+
Role bypasses every row level security policy, see
8901+
<xref linkend="ddl-rowsecurity"> for more information.
8902+
</entry>
8903+
</row>
8904+
88958905
<row>
88968906
<entry><structfield>rolconfig</structfield></entry>
88978907
<entry><type>text[]</type></entry>

‎doc/src/sgml/ddl.sgml

Lines changed: 39 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -3571,14 +3571,14 @@ ANALYZE measurement;
35713571
To ensure the integrity of the entire database structure,
35723572
<productname>&productname;</productname> makes sure that you cannot
35733573
drop objects that other objects still depend on. For example,
3574-
attempting to drop the products table wehadconsidered in <xref
3574+
attempting to drop the products table we considered in <xref
35753575
linkend="ddl-constraints-fk">, with the orders table depending on
3576-
it, would result in an error messagesuch as this:
3576+
it, would result in an error messagelike this:
35773577
<screen>
35783578
DROP TABLE products;
35793579

3580-
NOTICE: constraint orders_product_no_fkey on table orders depends on table products
35813580
ERROR: cannot drop table products because other objects depend on it
3581+
DETAIL: constraint orders_product_no_fkey on table orders depends on table products
35823582
HINT: Use DROP ... CASCADE to drop the dependent objects too.
35833583
</screen>
35843584
The error message contains a useful hint: if you do not want to
@@ -3589,7 +3589,8 @@ DROP TABLE products CASCADE;
35893589
and all the dependent objects will be removed. In this case, it
35903590
doesn't remove the orders table, it only removes the foreign key
35913591
constraint. (If you want to check what <command>DROP ... CASCADE</> will do,
3592-
run <command>DROP</> without <literal>CASCADE</> and read the <literal>NOTICE</> messages.)
3592+
run <command>DROP</> without <literal>CASCADE</> and read the
3593+
<literal>DETAIL</> output.)
35933594
</para>
35943595

35953596
<para>
@@ -3605,21 +3606,43 @@ DROP TABLE products CASCADE;
36053606
<para>
36063607
According to the SQL standard, specifying either
36073608
<literal>RESTRICT</literal> or <literal>CASCADE</literal> is
3608-
required. No database system actually enforces that rule, but
3609-
whether the default behavior is <literal>RESTRICT</literal> or
3610-
<literal>CASCADE</literal> varies across systems.
3609+
required in a <command>DROP</> command. No database system actually
3610+
enforces that rule, but whether the default behavior
3611+
is <literal>RESTRICT</literal> or <literal>CASCADE</literal> varies
3612+
across systems.
36113613
</para>
36123614
</note>
36133615

3614-
<note>
3615-
<para>
3616-
Foreign key constraint dependencies and serial column dependencies
3617-
from <productname>&productname;</productname> versions prior to 7.3
3618-
are <emphasis>not</emphasis> maintained or created during the
3619-
upgrade process. All other dependency types will be properly
3620-
created during an upgrade from a pre-7.3 database.
3621-
</para>
3622-
</note>
3616+
<para>
3617+
For user-defined functions, <productname>&productname;</productname> tracks
3618+
dependencies associated with a function's externally-visible properties,
3619+
such as its argument and result types, but <emphasis>not</> dependencies
3620+
that could only be known by examining the function body. As an example,
3621+
consider this situation:
3622+
3623+
<programlisting>
3624+
CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow',
3625+
'green', 'blue', 'purple');
3626+
3627+
CREATE TABLE my_colors (color rainbow, note text);
3628+
3629+
CREATE FUNCTION get_color_note (rainbow) RETURNS text AS
3630+
'SELECT note FROM my_colors WHERE color = $1'
3631+
LANGUAGE SQL;
3632+
</programlisting>
3633+
3634+
(See <xref linkend="xfunc-sql"> for an explanation of SQL-language
3635+
functions.) <productname>&productname;</productname> will be aware that
3636+
the <function>get_color_note</> function depends on the <type>rainbow</>
3637+
type: dropping the type would force dropping the function, because its
3638+
argument type would no longer be defined. But <productname>&productname;</>
3639+
will not consider <function>get_color_note</> to depend on
3640+
the <structname>my_colors</> table, and so will not drop the function if
3641+
the table is dropped. While there are disadvantages to this approach,
3642+
there are also benefits. The function is still valid in some sense if the
3643+
table is missing, though executing it would cause an error; creating a new
3644+
table of the same name would allow the function to work again.
3645+
</para>
36233646
</sect1>
36243647

36253648
</chapter>

‎src/backend/access/hash/hash.c

Lines changed: 18 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -140,19 +140,25 @@ hashbuildCallback(Relation index,
140140
void*state)
141141
{
142142
HashBuildState*buildstate= (HashBuildState*)state;
143+
Datumindex_values[1];
144+
boolindex_isnull[1];
143145
IndexTupleitup;
144146

145-
/* Hash indexes don't index nulls, see notes in hashinsert */
146-
if (isnull[0])
147+
/* convert data to a hash key; on failure, do not insert anything */
148+
if (!_hash_convert_tuple(index,
149+
values,isnull,
150+
index_values,index_isnull))
147151
return;
148152

149153
/* Either spool the tuple for sorting, or just put it into the index */
150154
if (buildstate->spool)
151-
_h_spool(buildstate->spool,&htup->t_self,values,isnull);
155+
_h_spool(buildstate->spool,&htup->t_self,
156+
index_values,index_isnull);
152157
else
153158
{
154159
/* form an index tuple and point it at the heap tuple */
155-
itup=_hash_form_tuple(index,values,isnull);
160+
itup=index_form_tuple(RelationGetDescr(index),
161+
index_values,index_isnull);
156162
itup->t_tid=htup->t_self;
157163
_hash_doinsert(index,itup);
158164
pfree(itup);
@@ -179,22 +185,18 @@ hashinsert(PG_FUNCTION_ARGS)
179185
RelationheapRel= (Relation)PG_GETARG_POINTER(4);
180186
IndexUniqueCheckcheckUnique= (IndexUniqueCheck)PG_GETARG_INT32(5);
181187
#endif
188+
Datumindex_values[1];
189+
boolindex_isnull[1];
182190
IndexTupleitup;
183191

184-
/*
185-
* If the single index key is null, we don't insert it into the index.
186-
* Hash tables support scans on '='. Relational algebra says that A = B
187-
* returns null if either A or B is null. This means that no
188-
* qualification used in an index scan could ever return true on a null
189-
* attribute. It also means that indices can't be used by ISNULL or
190-
* NOTNULL scans, but that's an artifact of the strategy map architecture
191-
* chosen in 1986, not of the way nulls are handled here.
192-
*/
193-
if (isnull[0])
192+
/* convert data to a hash key; on failure, do not insert anything */
193+
if (!_hash_convert_tuple(rel,
194+
values,isnull,
195+
index_values,index_isnull))
194196
PG_RETURN_BOOL(false);
195197

196-
/*generate an index tuple */
197-
itup=_hash_form_tuple(rel,values,isnull);
198+
/*form an index tuple and point it at the heap tuple */
199+
itup=index_form_tuple(RelationGetDescr(rel),index_values,index_isnull);
198200
itup->t_tid=*ht_ctid;
199201

200202
_hash_doinsert(rel,itup);

‎src/backend/access/hash/hashutil.c

Lines changed: 27 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -248,27 +248,37 @@ _hash_get_indextuple_hashkey(IndexTuple itup)
248248
}
249249

250250
/*
251-
* _hash_form_tuple - form an index tuple containing hash code only
251+
* _hash_convert_tuple - convert raw index data to hash key
252+
*
253+
* Inputs: values and isnull arrays for the user data column(s)
254+
* Outputs: values and isnull arrays for the index tuple, suitable for
255+
*passing to index_form_tuple().
256+
*
257+
* Returns true if successful, false if not (because there are null values).
258+
* On a false result, the given data need not be indexed.
259+
*
260+
* Note: callers know that the index-column arrays are always of length 1.
261+
* In principle, there could be more than one input column, though we do not
262+
* currently support that.
252263
*/
253-
IndexTuple
254-
_hash_form_tuple(Relationindex,Datum*values,bool*isnull)
264+
bool
265+
_hash_convert_tuple(Relationindex,
266+
Datum*user_values,bool*user_isnull,
267+
Datum*index_values,bool*index_isnull)
255268
{
256-
IndexTupleitup;
257269
uint32hashkey;
258-
Datumhashkeydatum;
259-
TupleDeschashdesc;
260270

261-
if (isnull[0])
262-
hashkeydatum= (Datum)0;
263-
else
264-
{
265-
hashkey=_hash_datum2hashkey(index,values[0]);
266-
hashkeydatum=UInt32GetDatum(hashkey);
267-
}
268-
hashdesc=RelationGetDescr(index);
269-
Assert(hashdesc->natts==1);
270-
itup=index_form_tuple(hashdesc,&hashkeydatum,isnull);
271-
returnitup;
271+
/*
272+
* We do not insert null values into hash indexes. This is okay because
273+
* the only supported search operator is '=', and we assume it is strict.
274+
*/
275+
if (user_isnull[0])
276+
return false;
277+
278+
hashkey=_hash_datum2hashkey(index,user_values[0]);
279+
index_values[0]=UInt32GetDatum(hashkey);
280+
index_isnull[0]=false;
281+
returntrue;
272282
}
273283

274284
/*

‎src/backend/access/heap/heapam.c

Lines changed: 28 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -3621,6 +3621,7 @@ heap_update(Relation relation, ItemPointer otid, HeapTuple newtup,
36213621
* HEAP_XMAX_INVALID bit set; that's fine.)
36223622
*/
36233623
if ((oldtup.t_data->t_infomask&HEAP_XMAX_INVALID)||
3624+
HEAP_LOCKED_UPGRADED(oldtup.t_data->t_infomask)||
36243625
(checked_lockers&& !locker_remains))
36253626
xmax_new_tuple=InvalidTransactionId;
36263627
else
@@ -5002,8 +5003,7 @@ compute_new_xmax_infomask(TransactionId xmax, uint16 old_infomask,
50025003
* pg_upgrade; both MultiXactIdIsRunning and MultiXactIdExpand assume
50035004
* that such multis are never passed.
50045005
*/
5005-
if (!(old_infomask&HEAP_LOCK_MASK)&&
5006-
HEAP_XMAX_IS_LOCKED_ONLY(old_infomask))
5006+
if (HEAP_LOCKED_UPGRADED(old_infomask))
50075007
{
50085008
old_infomask &= ~HEAP_XMAX_IS_MULTI;
50095009
old_infomask |=HEAP_XMAX_INVALID;
@@ -5363,6 +5363,17 @@ heap_lock_updated_tuple_rec(Relation rel, ItemPointer tid, TransactionId xid,
53635363
inti;
53645364
MultiXactMember*members;
53655365

5366+
/*
5367+
* We don't need a test for pg_upgrade'd tuples: this is only
5368+
* applied to tuples after the first in an update chain. Said
5369+
* first tuple in the chain may well be locked-in-9.2-and-
5370+
* pg_upgraded, but that one was already locked by our caller,
5371+
* not us; and any subsequent ones cannot be because our
5372+
* caller must necessarily have obtained a snapshot later than
5373+
* the pg_upgrade itself.
5374+
*/
5375+
Assert(!HEAP_LOCKED_UPGRADED(mytup.t_data->t_infomask));
5376+
53665377
nmembers=GetMultiXactIdMembers(rawxmax,&members, false,
53675378
HEAP_XMAX_IS_LOCKED_ONLY(old_infomask));
53685379
for (i=0;i<nmembers;i++)
@@ -5921,14 +5932,14 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
59215932
boolhas_lockers;
59225933
TransactionIdupdate_xid;
59235934
boolupdate_committed;
5924-
boolallow_old;
59255935

59265936
*flags=0;
59275937

59285938
/* We should only be called in Multis */
59295939
Assert(t_infomask&HEAP_XMAX_IS_MULTI);
59305940

5931-
if (!MultiXactIdIsValid(multi))
5941+
if (!MultiXactIdIsValid(multi)||
5942+
HEAP_LOCKED_UPGRADED(t_infomask))
59325943
{
59335944
/* Ensure infomask bits are appropriately set/reset */
59345945
*flags |=FRM_INVALIDATE_XMAX;
@@ -5941,14 +5952,8 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
59415952
* was a locker only, it can be removed without any further
59425953
* consideration; but if it contained an update, we might need to
59435954
* preserve it.
5944-
*
5945-
* Don't assert MultiXactIdIsRunning if the multi came from a
5946-
* pg_upgrade'd share-locked tuple, though, as doing that causes an
5947-
* error to be raised unnecessarily.
59485955
*/
5949-
Assert((!(t_infomask&HEAP_LOCK_MASK)&&
5950-
HEAP_XMAX_IS_LOCKED_ONLY(t_infomask))||
5951-
!MultiXactIdIsRunning(multi,
5956+
Assert(!MultiXactIdIsRunning(multi,
59525957
HEAP_XMAX_IS_LOCKED_ONLY(t_infomask)));
59535958
if (HEAP_XMAX_IS_LOCKED_ONLY(t_infomask))
59545959
{
@@ -5990,10 +5995,8 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
59905995
* anything.
59915996
*/
59925997

5993-
allow_old= !(t_infomask&HEAP_LOCK_MASK)&&
5994-
HEAP_XMAX_IS_LOCKED_ONLY(t_infomask);
59955998
nmembers=
5996-
GetMultiXactIdMembers(multi,&members,allow_old,
5999+
GetMultiXactIdMembers(multi,&members,false,
59976000
HEAP_XMAX_IS_LOCKED_ONLY(t_infomask));
59986001
if (nmembers <=0)
59996002
{
@@ -6535,14 +6538,15 @@ static bool
65356538
DoesMultiXactIdConflict(MultiXactIdmulti,uint16infomask,
65366539
LockTupleModelockmode)
65376540
{
6538-
boolallow_old;
65396541
intnmembers;
65406542
MultiXactMember*members;
65416543
boolresult= false;
65426544
LOCKMODEwanted=tupleLockExtraInfo[lockmode].hwlock;
65436545

6544-
allow_old= !(infomask&HEAP_LOCK_MASK)&&HEAP_XMAX_IS_LOCKED_ONLY(infomask);
6545-
nmembers=GetMultiXactIdMembers(multi,&members,allow_old,
6546+
if (HEAP_LOCKED_UPGRADED(infomask))
6547+
return false;
6548+
6549+
nmembers=GetMultiXactIdMembers(multi,&members, false,
65466550
HEAP_XMAX_IS_LOCKED_ONLY(infomask));
65476551
if (nmembers >=0)
65486552
{
@@ -6625,15 +6629,15 @@ Do_MultiXactIdWait(MultiXactId multi, MultiXactStatus status,
66256629
Relationrel,ItemPointerctid,XLTW_Operoper,
66266630
int*remaining)
66276631
{
6628-
boolallow_old;
66296632
boolresult= true;
66306633
MultiXactMember*members;
66316634
intnmembers;
66326635
intremain=0;
66336636

6634-
allow_old= !(infomask&HEAP_LOCK_MASK)&&HEAP_XMAX_IS_LOCKED_ONLY(infomask);
6635-
nmembers=GetMultiXactIdMembers(multi,&members,allow_old,
6636-
HEAP_XMAX_IS_LOCKED_ONLY(infomask));
6637+
/* for pre-pg_upgrade tuples, no need to sleep at all */
6638+
nmembers=HEAP_LOCKED_UPGRADED(infomask) ?-1 :
6639+
GetMultiXactIdMembers(multi,&members, false,
6640+
HEAP_XMAX_IS_LOCKED_ONLY(infomask));
66376641

66386642
if (nmembers >=0)
66396643
{
@@ -6765,20 +6769,19 @@ heap_tuple_needs_freeze(HeapTupleHeader tuple, TransactionId cutoff_xid,
67656769
/* no xmax set, ignore */
67666770
;
67676771
}
6772+
elseif (HEAP_LOCKED_UPGRADED(tuple->t_infomask))
6773+
return true;
67686774
elseif (MultiXactIdPrecedes(multi,cutoff_multi))
67696775
return true;
67706776
else
67716777
{
67726778
MultiXactMember*members;
67736779
intnmembers;
67746780
inti;
6775-
boolallow_old;
67766781

67776782
/* need to check whether any member of the mxact is too old */
67786783

6779-
allow_old= !(tuple->t_infomask&HEAP_LOCK_MASK)&&
6780-
HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask);
6781-
nmembers=GetMultiXactIdMembers(multi,&members,allow_old,
6784+
nmembers=GetMultiXactIdMembers(multi,&members, false,
67826785
HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask));
67836786

67846787
for (i=0;i<nmembers;i++)

0 commit comments

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