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

Commit7fbcee1

Browse files
committed
Log when GetNewOidWithIndex() fails to find unused OID many times.
GetNewOidWithIndex() generates a new OID one by one until it findsone not in the relation. If there are very long runs of consecutiveexisting OIDs, GetNewOidWithIndex() needs to iterate many timesin the loop to find unused OID. Since TOAST table can have a largenumber of entries and there can be such long runs of OIDs, there isthe case where it takes so many iterations to find new OID not inTOAST table. Furthermore if all (i.e., 2^32) OIDs are already used,GetNewOidWithIndex() enters something like busy loop and repeatsthe iterations until at least one OID is marked as unused.There are some reported troubles caused by a large number ofiterations in GetNewOidWithIndex(). For example, when insertinga billion of records into the table, all the backends doing thatinsertion operation got hang with 100% CPU usage at some point.Previously there was no easy way to detect that GetNewOidWithIndex()failed to find unused OID many times. So, for example, gdb fullbacktrace of hanged backends needed to be taken, in order toinvestigate that trouble. This is inconvenient and may not beavailable in some production environments.To provide easy way for that, this commit makes GetNewOidWithIndex()log that it iterates more than GETNEWOID_LOG_THRESHOLD but havenot yet found OID unused in the relation. Also this commit makesit repeat logging with exponentially increasing intervals untilit iterates more than GETNEWOID_LOG_MAX_INTERVAL, and makes itfinally repeat logging every GETNEWOID_LOG_MAX_INTERVAL unlessan unused OID is found. Those macro variables are used not tofill up the server log with the similar messages.In the discusion at pgsql-hackers, there was another idea to reportthe lots of iterations in GetNewOidWithIndex() via wait event.But since GetNewOidWithIndex() traverses indexes to find unusedOID and which will do I/O, acquire locks, etc, which will overwritethe wait event and reset it to nothing once done. So that ideadoesn't work well, and we didn't adopt it.Author: Tomohiro HiramitsuReviewed-by: Tatsuhito Kasahara, Kyotaro Horiguchi, Tom Lane, Fujii MasaoDiscussion:https://postgr.es/m/16722-93043fb459a41073@postgresql.org
1 parent99dd75f commit7fbcee1

File tree

1 file changed

+49
-0
lines changed

1 file changed

+49
-0
lines changed

‎src/backend/catalog/catalog.c

Lines changed: 49 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -47,6 +47,13 @@
4747
#include"utils/snapmgr.h"
4848
#include"utils/syscache.h"
4949

50+
/*
51+
* Parameters to determine when to emit a log message in
52+
* GetNewOidWithIndex()
53+
*/
54+
#defineGETNEWOID_LOG_THRESHOLD 1000000
55+
#defineGETNEWOID_LOG_MAX_INTERVAL 128000000
56+
5057
/*
5158
* IsSystemRelation
5259
*True iff the relation is either a system catalog or a toast table.
@@ -318,6 +325,8 @@ GetNewOidWithIndex(Relation relation, Oid indexId, AttrNumber oidcolumn)
318325
SysScanDescscan;
319326
ScanKeyDatakey;
320327
boolcollides;
328+
uint64retries=0;
329+
uint64retries_before_log=GETNEWOID_LOG_THRESHOLD;
321330

322331
/* Only system relations are supported */
323332
Assert(IsSystemRelation(relation));
@@ -353,8 +362,48 @@ GetNewOidWithIndex(Relation relation, Oid indexId, AttrNumber oidcolumn)
353362
collides=HeapTupleIsValid(systable_getnext(scan));
354363

355364
systable_endscan(scan);
365+
366+
/*
367+
* Log that we iterate more than GETNEWOID_LOG_THRESHOLD but have not
368+
* yet found OID unused in the relation. Then repeat logging with
369+
* exponentially increasing intervals until we iterate more than
370+
* GETNEWOID_LOG_MAX_INTERVAL. Finally repeat logging every
371+
* GETNEWOID_LOG_MAX_INTERVAL unless an unused OID is found. This
372+
* logic is necessary not to fill up the server log with the similar
373+
* messages.
374+
*/
375+
if (retries >=retries_before_log)
376+
{
377+
ereport(LOG,
378+
(errmsg("still finding an unused OID within relation \"%s\"",
379+
RelationGetRelationName(relation)),
380+
errdetail("OID candidates were checked \"%llu\" times, but no unused OID is yet found.",
381+
(unsigned long long)retries)));
382+
383+
/*
384+
* Double the number of retries to do before logging next until it
385+
* reaches GETNEWOID_LOG_MAX_INTERVAL.
386+
*/
387+
if (retries_before_log*2 <=GETNEWOID_LOG_MAX_INTERVAL)
388+
retries_before_log *=2;
389+
else
390+
retries_before_log+=GETNEWOID_LOG_MAX_INTERVAL;
391+
}
392+
393+
retries++;
356394
}while (collides);
357395

396+
/*
397+
* If at least one log message is emitted, also log the completion of OID
398+
* assignment.
399+
*/
400+
if (retries>GETNEWOID_LOG_THRESHOLD)
401+
{
402+
ereport(LOG,
403+
(errmsg("new OID has been assigned in relation \"%s\" after \"%llu\" retries",
404+
RelationGetRelationName(relation), (unsigned long long)retries)));
405+
}
406+
358407
returnnewOid;
359408
}
360409

0 commit comments

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