2017-08-22 02:43:00 +08:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* autoprewarm.c
|
|
|
|
* Periodically dump information about the blocks present in
|
|
|
|
* shared_buffers, and reload them on server restart.
|
|
|
|
*
|
|
|
|
* Due to locking considerations, we can't actually begin prewarming
|
|
|
|
* until the server reaches a consistent state. We need the catalogs
|
|
|
|
* to be consistent so that we can figure out which relation to lock,
|
|
|
|
* and we need to lock the relations so that we don't try to prewarm
|
|
|
|
* pages from a relation that is in the process of being dropped.
|
|
|
|
*
|
|
|
|
* While prewarming, autoprewarm will use two workers. There's a
|
2020-06-15 05:22:47 +08:00
|
|
|
* leader worker that reads and sorts the list of blocks to be
|
2017-08-22 02:43:00 +08:00
|
|
|
* prewarmed and then launches a per-database worker for each
|
|
|
|
* relevant database in turn. The former keeps running after the
|
|
|
|
* initial prewarm is complete to update the dump file periodically.
|
|
|
|
*
|
2022-01-08 08:04:57 +08:00
|
|
|
* Copyright (c) 2016-2022, PostgreSQL Global Development Group
|
2017-08-22 02:43:00 +08:00
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
|
|
|
* contrib/pg_prewarm/autoprewarm.c
|
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "postgres.h"
|
Avoid portability issues in autoprewarm.c.
autoprewarm.c mostly considered the number of blocks it might be dealing
with as being int64. This is unnecessary, because NBuffers is declared
as int, and there's been no suggestion that we might widen it in the
foreseeable future. Moreover, using int64 is problematic because the
code expected INT64_FORMAT to work with fscanf(), something we don't
guarantee, and which indeed fails on some older buildfarm members.
On top of that, the module randomly used uint32 rather than int64 variables
to hold block counters in several places, so it would fail anyway if we
ever did have NBuffers wider than that; and it also supposed that pg_qsort
could sort an int64 number of elements, which is wrong on 32-bit machines
(though no doubt a 32-bit machine couldn't actually have that many
buffers).
Hence, change all these variables to plain int.
In passing, avoid shadowing one variable named i with another,
and avoid casting away const in apw_compare_blockinfo.
Discussion: https://postgr.es/m/7773.1525288909@sss.pgh.pa.us
2018-05-04 00:50:27 +08:00
|
|
|
|
2017-08-22 02:43:00 +08:00
|
|
|
#include <unistd.h>
|
|
|
|
|
2019-01-22 02:18:20 +08:00
|
|
|
#include "access/relation.h"
|
2017-08-22 02:43:00 +08:00
|
|
|
#include "access/xact.h"
|
|
|
|
#include "catalog/pg_class.h"
|
|
|
|
#include "catalog/pg_type.h"
|
|
|
|
#include "miscadmin.h"
|
|
|
|
#include "pgstat.h"
|
|
|
|
#include "postmaster/bgworker.h"
|
2020-11-07 01:08:06 +08:00
|
|
|
#include "postmaster/interrupt.h"
|
2017-08-22 02:43:00 +08:00
|
|
|
#include "storage/buf_internals.h"
|
|
|
|
#include "storage/dsm.h"
|
2022-02-16 15:30:38 +08:00
|
|
|
#include "storage/fd.h"
|
2017-08-22 02:43:00 +08:00
|
|
|
#include "storage/ipc.h"
|
|
|
|
#include "storage/latch.h"
|
|
|
|
#include "storage/lwlock.h"
|
|
|
|
#include "storage/proc.h"
|
|
|
|
#include "storage/procsignal.h"
|
|
|
|
#include "storage/shmem.h"
|
|
|
|
#include "storage/smgr.h"
|
|
|
|
#include "tcop/tcopprot.h"
|
|
|
|
#include "utils/acl.h"
|
2020-08-17 15:50:13 +08:00
|
|
|
#include "utils/datetime.h"
|
2017-08-22 02:43:00 +08:00
|
|
|
#include "utils/guc.h"
|
|
|
|
#include "utils/memutils.h"
|
|
|
|
#include "utils/rel.h"
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 23:39:09 +08:00
|
|
|
#include "utils/relfilenumbermap.h"
|
2017-08-22 02:43:00 +08:00
|
|
|
#include "utils/resowner.h"
|
|
|
|
|
|
|
|
#define AUTOPREWARM_FILE "autoprewarm.blocks"
|
|
|
|
|
|
|
|
/* Metadata for each block we dump. */
|
|
|
|
typedef struct BlockInfoRecord
|
|
|
|
{
|
|
|
|
Oid database;
|
|
|
|
Oid tablespace;
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 23:39:09 +08:00
|
|
|
RelFileNumber filenumber;
|
2017-08-22 02:43:00 +08:00
|
|
|
ForkNumber forknum;
|
|
|
|
BlockNumber blocknum;
|
|
|
|
} BlockInfoRecord;
|
|
|
|
|
|
|
|
/* Shared state information for autoprewarm bgworker. */
|
|
|
|
typedef struct AutoPrewarmSharedState
|
|
|
|
{
|
|
|
|
LWLock lock; /* mutual exclusion */
|
|
|
|
pid_t bgworker_pid; /* for main bgworker */
|
|
|
|
pid_t pid_using_dumpfile; /* for autoprewarm or block dump */
|
|
|
|
|
|
|
|
/* Following items are for communication with per-database worker */
|
|
|
|
dsm_handle block_info_handle;
|
|
|
|
Oid database;
|
Avoid portability issues in autoprewarm.c.
autoprewarm.c mostly considered the number of blocks it might be dealing
with as being int64. This is unnecessary, because NBuffers is declared
as int, and there's been no suggestion that we might widen it in the
foreseeable future. Moreover, using int64 is problematic because the
code expected INT64_FORMAT to work with fscanf(), something we don't
guarantee, and which indeed fails on some older buildfarm members.
On top of that, the module randomly used uint32 rather than int64 variables
to hold block counters in several places, so it would fail anyway if we
ever did have NBuffers wider than that; and it also supposed that pg_qsort
could sort an int64 number of elements, which is wrong on 32-bit machines
(though no doubt a 32-bit machine couldn't actually have that many
buffers).
Hence, change all these variables to plain int.
In passing, avoid shadowing one variable named i with another,
and avoid casting away const in apw_compare_blockinfo.
Discussion: https://postgr.es/m/7773.1525288909@sss.pgh.pa.us
2018-05-04 00:50:27 +08:00
|
|
|
int prewarm_start_idx;
|
|
|
|
int prewarm_stop_idx;
|
|
|
|
int prewarmed_blocks;
|
2017-08-22 02:43:00 +08:00
|
|
|
} AutoPrewarmSharedState;
|
|
|
|
|
2022-07-28 00:00:10 +08:00
|
|
|
PGDLLEXPORT void autoprewarm_main(Datum main_arg);
|
|
|
|
PGDLLEXPORT void autoprewarm_database_main(Datum main_arg);
|
2017-08-22 02:43:00 +08:00
|
|
|
|
|
|
|
PG_FUNCTION_INFO_V1(autoprewarm_start_worker);
|
|
|
|
PG_FUNCTION_INFO_V1(autoprewarm_dump_now);
|
|
|
|
|
|
|
|
static void apw_load_buffers(void);
|
Avoid portability issues in autoprewarm.c.
autoprewarm.c mostly considered the number of blocks it might be dealing
with as being int64. This is unnecessary, because NBuffers is declared
as int, and there's been no suggestion that we might widen it in the
foreseeable future. Moreover, using int64 is problematic because the
code expected INT64_FORMAT to work with fscanf(), something we don't
guarantee, and which indeed fails on some older buildfarm members.
On top of that, the module randomly used uint32 rather than int64 variables
to hold block counters in several places, so it would fail anyway if we
ever did have NBuffers wider than that; and it also supposed that pg_qsort
could sort an int64 number of elements, which is wrong on 32-bit machines
(though no doubt a 32-bit machine couldn't actually have that many
buffers).
Hence, change all these variables to plain int.
In passing, avoid shadowing one variable named i with another,
and avoid casting away const in apw_compare_blockinfo.
Discussion: https://postgr.es/m/7773.1525288909@sss.pgh.pa.us
2018-05-04 00:50:27 +08:00
|
|
|
static int apw_dump_now(bool is_bgworker, bool dump_unlogged);
|
2020-06-15 05:22:47 +08:00
|
|
|
static void apw_start_leader_worker(void);
|
2017-08-22 02:43:00 +08:00
|
|
|
static void apw_start_database_worker(void);
|
|
|
|
static bool apw_init_shmem(void);
|
|
|
|
static void apw_detach_shmem(int code, Datum arg);
|
|
|
|
static int apw_compare_blockinfo(const void *p, const void *q);
|
2022-05-13 21:31:06 +08:00
|
|
|
static void autoprewarm_shmem_request(void);
|
|
|
|
static shmem_request_hook_type prev_shmem_request_hook = NULL;
|
2017-08-22 02:43:00 +08:00
|
|
|
|
|
|
|
/* Pointer to shared-memory state. */
|
|
|
|
static AutoPrewarmSharedState *apw_state = NULL;
|
|
|
|
|
|
|
|
/* GUC variables. */
|
|
|
|
static bool autoprewarm = true; /* start worker? */
|
2022-10-31 11:44:48 +08:00
|
|
|
static int autoprewarm_interval = 300; /* dump interval */
|
2017-08-22 02:43:00 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Module load callback.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
_PG_init(void)
|
|
|
|
{
|
|
|
|
DefineCustomIntVariable("pg_prewarm.autoprewarm_interval",
|
|
|
|
"Sets the interval between dumps of shared buffers",
|
|
|
|
"If set to zero, time-based dumping is disabled.",
|
|
|
|
&autoprewarm_interval,
|
|
|
|
300,
|
|
|
|
0, INT_MAX / 1000,
|
|
|
|
PGC_SIGHUP,
|
|
|
|
GUC_UNIT_S,
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
NULL);
|
|
|
|
|
|
|
|
if (!process_shared_preload_libraries_in_progress)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* can't define PGC_POSTMASTER variable after startup */
|
|
|
|
DefineCustomBoolVariable("pg_prewarm.autoprewarm",
|
|
|
|
"Starts the autoprewarm worker.",
|
|
|
|
NULL,
|
|
|
|
&autoprewarm,
|
|
|
|
true,
|
|
|
|
PGC_POSTMASTER,
|
|
|
|
0,
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
NULL);
|
|
|
|
|
2022-02-22 03:10:15 +08:00
|
|
|
MarkGUCPrefixReserved("pg_prewarm");
|
2017-08-22 02:43:00 +08:00
|
|
|
|
2022-05-13 21:31:06 +08:00
|
|
|
prev_shmem_request_hook = shmem_request_hook;
|
|
|
|
shmem_request_hook = autoprewarm_shmem_request;
|
2017-08-22 02:43:00 +08:00
|
|
|
|
|
|
|
/* Register autoprewarm worker, if enabled. */
|
|
|
|
if (autoprewarm)
|
2020-06-15 05:22:47 +08:00
|
|
|
apw_start_leader_worker();
|
2017-08-22 02:43:00 +08:00
|
|
|
}
|
|
|
|
|
2022-05-13 21:31:06 +08:00
|
|
|
/*
|
|
|
|
* Requests any additional shared memory required for autoprewarm.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
autoprewarm_shmem_request(void)
|
|
|
|
{
|
|
|
|
if (prev_shmem_request_hook)
|
|
|
|
prev_shmem_request_hook();
|
|
|
|
|
|
|
|
RequestAddinShmemSpace(MAXALIGN(sizeof(AutoPrewarmSharedState)));
|
|
|
|
}
|
|
|
|
|
2017-08-22 02:43:00 +08:00
|
|
|
/*
|
2020-06-15 05:22:47 +08:00
|
|
|
* Main entry point for the leader autoprewarm process. Per-database workers
|
2017-08-22 02:43:00 +08:00
|
|
|
* have a separate entry point.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
autoprewarm_main(Datum main_arg)
|
|
|
|
{
|
|
|
|
bool first_time = true;
|
2020-12-23 02:23:49 +08:00
|
|
|
bool final_dump_allowed = true;
|
2017-08-22 02:43:00 +08:00
|
|
|
TimestampTz last_dump_time = 0;
|
|
|
|
|
|
|
|
/* Establish signal handlers; once that's done, unblock signals. */
|
2020-11-07 01:08:06 +08:00
|
|
|
pqsignal(SIGTERM, SignalHandlerForShutdownRequest);
|
|
|
|
pqsignal(SIGHUP, SignalHandlerForConfigReload);
|
2017-08-22 02:43:00 +08:00
|
|
|
pqsignal(SIGUSR1, procsignal_sigusr1_handler);
|
|
|
|
BackgroundWorkerUnblockSignals();
|
|
|
|
|
|
|
|
/* Create (if necessary) and attach to our shared memory area. */
|
|
|
|
if (apw_init_shmem())
|
|
|
|
first_time = false;
|
|
|
|
|
|
|
|
/* Set on-detach hook so that our PID will be cleared on exit. */
|
|
|
|
on_shmem_exit(apw_detach_shmem, 0);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Store our PID in the shared memory area --- unless there's already
|
|
|
|
* another worker running, in which case just exit.
|
|
|
|
*/
|
|
|
|
LWLockAcquire(&apw_state->lock, LW_EXCLUSIVE);
|
|
|
|
if (apw_state->bgworker_pid != InvalidPid)
|
|
|
|
{
|
|
|
|
LWLockRelease(&apw_state->lock);
|
|
|
|
ereport(LOG,
|
2022-10-14 14:37:12 +08:00
|
|
|
(errmsg("autoprewarm worker is already running under PID %d",
|
|
|
|
(int) apw_state->bgworker_pid)));
|
2017-08-22 02:43:00 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
apw_state->bgworker_pid = MyProcPid;
|
|
|
|
LWLockRelease(&apw_state->lock);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Preload buffers from the dump file only if we just created the shared
|
|
|
|
* memory region. Otherwise, it's either already been done or shouldn't
|
|
|
|
* be done - e.g. because the old dump file has been overwritten since the
|
|
|
|
* server was started.
|
|
|
|
*
|
|
|
|
* There's not much point in performing a dump immediately after we finish
|
|
|
|
* preloading; so, if we do end up preloading, consider the last dump time
|
|
|
|
* to be equal to the current time.
|
2020-12-23 02:23:49 +08:00
|
|
|
*
|
|
|
|
* If apw_load_buffers() is terminated early by a shutdown request,
|
|
|
|
* prevent dumping out our state below the loop, because we'd effectively
|
|
|
|
* just truncate the saved state to however much we'd managed to preload.
|
2017-08-22 02:43:00 +08:00
|
|
|
*/
|
|
|
|
if (first_time)
|
|
|
|
{
|
|
|
|
apw_load_buffers();
|
2020-12-23 02:23:49 +08:00
|
|
|
final_dump_allowed = !ShutdownRequestPending;
|
2017-08-22 02:43:00 +08:00
|
|
|
last_dump_time = GetCurrentTimestamp();
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Periodically dump buffers until terminated. */
|
2020-11-07 01:08:06 +08:00
|
|
|
while (!ShutdownRequestPending)
|
2017-08-22 02:43:00 +08:00
|
|
|
{
|
|
|
|
/* In case of a SIGHUP, just reload the configuration. */
|
2020-11-07 01:08:06 +08:00
|
|
|
if (ConfigReloadPending)
|
2017-08-22 02:43:00 +08:00
|
|
|
{
|
2020-11-07 01:08:06 +08:00
|
|
|
ConfigReloadPending = false;
|
2017-08-22 02:43:00 +08:00
|
|
|
ProcessConfigFile(PGC_SIGHUP);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (autoprewarm_interval <= 0)
|
|
|
|
{
|
|
|
|
/* We're only dumping at shutdown, so just wait forever. */
|
2020-11-07 01:08:06 +08:00
|
|
|
(void) WaitLatch(MyLatch,
|
2018-11-24 00:01:05 +08:00
|
|
|
WL_LATCH_SET | WL_EXIT_ON_PM_DEATH,
|
|
|
|
-1L,
|
|
|
|
PG_WAIT_EXTENSION);
|
2017-08-22 02:43:00 +08:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
Fix and simplify some usages of TimestampDifference().
Introduce TimestampDifferenceMilliseconds() to simplify callers
that would rather have the difference in milliseconds, instead of
the select()-oriented seconds-and-microseconds format. This gets
rid of at least one integer division per call, and it eliminates
some apparently-easy-to-mess-up arithmetic.
Two of these call sites were in fact wrong:
* pg_prewarm's autoprewarm_main() forgot to multiply the seconds
by 1000, thus ending up with a delay 1000X shorter than intended.
That doesn't quite make it a busy-wait, but close.
* postgres_fdw's pgfdw_get_cleanup_result() thought it needed to compute
microseconds not milliseconds, thus ending up with a delay 1000X longer
than intended. Somebody along the way had noticed this problem but
misdiagnosed the cause, and imposed an ad-hoc 60-second limit rather
than fixing the units. This was relatively harmless in context, because
we don't care that much about exactly how long this delay is; still,
it's wrong.
There are a few more callers of TimestampDifference() that don't
have a direct need for seconds-and-microseconds, but can't use
TimestampDifferenceMilliseconds() either because they do need
microsecond precision or because they might possibly deal with
intervals long enough to overflow 32-bit milliseconds. It might be
worth inventing another API to improve that, but that seems outside
the scope of this patch; so those callers are untouched here.
Given the fact that we are fixing some bugs, and the likelihood
that future patches might want to back-patch code that uses this
new API, back-patch to all supported branches.
Alexey Kondratov and Tom Lane
Discussion: https://postgr.es/m/3b1c053a21c07c1ed5e00be3b2b855ef@postgrespro.ru
2020-11-11 11:51:18 +08:00
|
|
|
TimestampTz next_dump_time;
|
|
|
|
long delay_in_ms;
|
2017-08-22 02:43:00 +08:00
|
|
|
|
|
|
|
/* Compute the next dump time. */
|
|
|
|
next_dump_time =
|
|
|
|
TimestampTzPlusMilliseconds(last_dump_time,
|
|
|
|
autoprewarm_interval * 1000);
|
Fix and simplify some usages of TimestampDifference().
Introduce TimestampDifferenceMilliseconds() to simplify callers
that would rather have the difference in milliseconds, instead of
the select()-oriented seconds-and-microseconds format. This gets
rid of at least one integer division per call, and it eliminates
some apparently-easy-to-mess-up arithmetic.
Two of these call sites were in fact wrong:
* pg_prewarm's autoprewarm_main() forgot to multiply the seconds
by 1000, thus ending up with a delay 1000X shorter than intended.
That doesn't quite make it a busy-wait, but close.
* postgres_fdw's pgfdw_get_cleanup_result() thought it needed to compute
microseconds not milliseconds, thus ending up with a delay 1000X longer
than intended. Somebody along the way had noticed this problem but
misdiagnosed the cause, and imposed an ad-hoc 60-second limit rather
than fixing the units. This was relatively harmless in context, because
we don't care that much about exactly how long this delay is; still,
it's wrong.
There are a few more callers of TimestampDifference() that don't
have a direct need for seconds-and-microseconds, but can't use
TimestampDifferenceMilliseconds() either because they do need
microsecond precision or because they might possibly deal with
intervals long enough to overflow 32-bit milliseconds. It might be
worth inventing another API to improve that, but that seems outside
the scope of this patch; so those callers are untouched here.
Given the fact that we are fixing some bugs, and the likelihood
that future patches might want to back-patch code that uses this
new API, back-patch to all supported branches.
Alexey Kondratov and Tom Lane
Discussion: https://postgr.es/m/3b1c053a21c07c1ed5e00be3b2b855ef@postgrespro.ru
2020-11-11 11:51:18 +08:00
|
|
|
delay_in_ms =
|
|
|
|
TimestampDifferenceMilliseconds(GetCurrentTimestamp(),
|
|
|
|
next_dump_time);
|
2017-08-22 02:43:00 +08:00
|
|
|
|
|
|
|
/* Perform a dump if it's time. */
|
|
|
|
if (delay_in_ms <= 0)
|
|
|
|
{
|
|
|
|
last_dump_time = GetCurrentTimestamp();
|
|
|
|
apw_dump_now(true, false);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Sleep until the next dump time. */
|
2020-11-07 01:08:06 +08:00
|
|
|
(void) WaitLatch(MyLatch,
|
2018-11-24 00:01:05 +08:00
|
|
|
WL_LATCH_SET | WL_TIMEOUT | WL_EXIT_ON_PM_DEATH,
|
|
|
|
delay_in_ms,
|
|
|
|
PG_WAIT_EXTENSION);
|
2017-08-22 02:43:00 +08:00
|
|
|
}
|
|
|
|
|
Add WL_EXIT_ON_PM_DEATH pseudo-event.
Users of the WaitEventSet and WaitLatch() APIs can now choose between
asking for WL_POSTMASTER_DEATH and then handling it explicitly, or asking
for WL_EXIT_ON_PM_DEATH to trigger immediate exit on postmaster death.
This reduces code duplication, since almost all callers want the latter.
Repair all code that was previously ignoring postmaster death completely,
or requesting the event but ignoring it, or requesting the event but then
doing an unconditional PostmasterIsAlive() call every time through its
event loop (which is an expensive syscall on platforms for which we don't
have USE_POSTMASTER_DEATH_SIGNAL support).
Assert that callers of WaitLatchXXX() under the postmaster remember to
ask for either WL_POSTMASTER_DEATH or WL_EXIT_ON_PM_DEATH, to prevent
future bugs.
The only process that doesn't handle postmaster death is syslogger. It
waits until all backends holding the write end of the syslog pipe
(including the postmaster) have closed it by exiting, to be sure to
capture any parting messages. By using the WaitEventSet API directly
it avoids the new assertion, and as a by-product it may be slightly
more efficient on platforms that have epoll().
Author: Thomas Munro
Reviewed-by: Kyotaro Horiguchi, Heikki Linnakangas, Tom Lane
Discussion: https://postgr.es/m/CAEepm%3D1TCviRykkUb69ppWLr_V697rzd1j3eZsRMmbXvETfqbQ%40mail.gmail.com,
https://postgr.es/m/CAEepm=2LqHzizbe7muD7-2yHUbTOoF7Q+qkSD5Q41kuhttRTwA@mail.gmail.com
2018-11-23 15:16:41 +08:00
|
|
|
/* Reset the latch, loop. */
|
2020-11-07 01:08:06 +08:00
|
|
|
ResetLatch(MyLatch);
|
2017-08-22 02:43:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Dump one last time. We assume this is probably the result of a system
|
|
|
|
* shutdown, although it's possible that we've merely been terminated.
|
|
|
|
*/
|
2020-12-23 02:23:49 +08:00
|
|
|
if (final_dump_allowed)
|
|
|
|
apw_dump_now(true, true);
|
2017-08-22 02:43:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Read the dump file and launch per-database workers one at a time to
|
|
|
|
* prewarm the buffers found there.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
apw_load_buffers(void)
|
|
|
|
{
|
|
|
|
FILE *file = NULL;
|
Avoid portability issues in autoprewarm.c.
autoprewarm.c mostly considered the number of blocks it might be dealing
with as being int64. This is unnecessary, because NBuffers is declared
as int, and there's been no suggestion that we might widen it in the
foreseeable future. Moreover, using int64 is problematic because the
code expected INT64_FORMAT to work with fscanf(), something we don't
guarantee, and which indeed fails on some older buildfarm members.
On top of that, the module randomly used uint32 rather than int64 variables
to hold block counters in several places, so it would fail anyway if we
ever did have NBuffers wider than that; and it also supposed that pg_qsort
could sort an int64 number of elements, which is wrong on 32-bit machines
(though no doubt a 32-bit machine couldn't actually have that many
buffers).
Hence, change all these variables to plain int.
In passing, avoid shadowing one variable named i with another,
and avoid casting away const in apw_compare_blockinfo.
Discussion: https://postgr.es/m/7773.1525288909@sss.pgh.pa.us
2018-05-04 00:50:27 +08:00
|
|
|
int num_elements,
|
2017-08-22 02:43:00 +08:00
|
|
|
i;
|
|
|
|
BlockInfoRecord *blkinfo;
|
|
|
|
dsm_segment *seg;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Skip the prewarm if the dump file is in use; otherwise, prevent any
|
|
|
|
* other process from writing it while we're using it.
|
|
|
|
*/
|
|
|
|
LWLockAcquire(&apw_state->lock, LW_EXCLUSIVE);
|
|
|
|
if (apw_state->pid_using_dumpfile == InvalidPid)
|
|
|
|
apw_state->pid_using_dumpfile = MyProcPid;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
LWLockRelease(&apw_state->lock);
|
|
|
|
ereport(LOG,
|
2022-10-14 14:37:12 +08:00
|
|
|
(errmsg("skipping prewarm because block dump file is being written by PID %d",
|
|
|
|
(int) apw_state->pid_using_dumpfile)));
|
2017-08-22 02:43:00 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
LWLockRelease(&apw_state->lock);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Open the block dump file. Exit quietly if it doesn't exist, but report
|
|
|
|
* any other error.
|
|
|
|
*/
|
|
|
|
file = AllocateFile(AUTOPREWARM_FILE, "r");
|
|
|
|
if (!file)
|
|
|
|
{
|
|
|
|
if (errno == ENOENT)
|
|
|
|
{
|
|
|
|
LWLockAcquire(&apw_state->lock, LW_EXCLUSIVE);
|
|
|
|
apw_state->pid_using_dumpfile = InvalidPid;
|
|
|
|
LWLockRelease(&apw_state->lock);
|
|
|
|
return; /* No file to load. */
|
|
|
|
}
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode_for_file_access(),
|
|
|
|
errmsg("could not read file \"%s\": %m",
|
|
|
|
AUTOPREWARM_FILE)));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* First line of the file is a record count. */
|
Avoid portability issues in autoprewarm.c.
autoprewarm.c mostly considered the number of blocks it might be dealing
with as being int64. This is unnecessary, because NBuffers is declared
as int, and there's been no suggestion that we might widen it in the
foreseeable future. Moreover, using int64 is problematic because the
code expected INT64_FORMAT to work with fscanf(), something we don't
guarantee, and which indeed fails on some older buildfarm members.
On top of that, the module randomly used uint32 rather than int64 variables
to hold block counters in several places, so it would fail anyway if we
ever did have NBuffers wider than that; and it also supposed that pg_qsort
could sort an int64 number of elements, which is wrong on 32-bit machines
(though no doubt a 32-bit machine couldn't actually have that many
buffers).
Hence, change all these variables to plain int.
In passing, avoid shadowing one variable named i with another,
and avoid casting away const in apw_compare_blockinfo.
Discussion: https://postgr.es/m/7773.1525288909@sss.pgh.pa.us
2018-05-04 00:50:27 +08:00
|
|
|
if (fscanf(file, "<<%d>>\n", &num_elements) != 1)
|
2017-08-22 02:43:00 +08:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode_for_file_access(),
|
|
|
|
errmsg("could not read from file \"%s\": %m",
|
|
|
|
AUTOPREWARM_FILE)));
|
|
|
|
|
|
|
|
/* Allocate a dynamic shared memory segment to store the record data. */
|
|
|
|
seg = dsm_create(sizeof(BlockInfoRecord) * num_elements, 0);
|
|
|
|
blkinfo = (BlockInfoRecord *) dsm_segment_address(seg);
|
|
|
|
|
|
|
|
/* Read records, one per line. */
|
|
|
|
for (i = 0; i < num_elements; i++)
|
|
|
|
{
|
|
|
|
unsigned forknum;
|
|
|
|
|
2022-09-28 21:45:27 +08:00
|
|
|
if (fscanf(file, "%u,%u,%u,%u,%u\n", &blkinfo[i].database,
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 23:39:09 +08:00
|
|
|
&blkinfo[i].tablespace, &blkinfo[i].filenumber,
|
2017-08-22 02:43:00 +08:00
|
|
|
&forknum, &blkinfo[i].blocknum) != 5)
|
|
|
|
ereport(ERROR,
|
Avoid portability issues in autoprewarm.c.
autoprewarm.c mostly considered the number of blocks it might be dealing
with as being int64. This is unnecessary, because NBuffers is declared
as int, and there's been no suggestion that we might widen it in the
foreseeable future. Moreover, using int64 is problematic because the
code expected INT64_FORMAT to work with fscanf(), something we don't
guarantee, and which indeed fails on some older buildfarm members.
On top of that, the module randomly used uint32 rather than int64 variables
to hold block counters in several places, so it would fail anyway if we
ever did have NBuffers wider than that; and it also supposed that pg_qsort
could sort an int64 number of elements, which is wrong on 32-bit machines
(though no doubt a 32-bit machine couldn't actually have that many
buffers).
Hence, change all these variables to plain int.
In passing, avoid shadowing one variable named i with another,
and avoid casting away const in apw_compare_blockinfo.
Discussion: https://postgr.es/m/7773.1525288909@sss.pgh.pa.us
2018-05-04 00:50:27 +08:00
|
|
|
(errmsg("autoprewarm block dump file is corrupted at line %d",
|
2017-08-22 02:43:00 +08:00
|
|
|
i + 1)));
|
|
|
|
blkinfo[i].forknum = forknum;
|
|
|
|
}
|
|
|
|
|
|
|
|
FreeFile(file);
|
|
|
|
|
|
|
|
/* Sort the blocks to be loaded. */
|
|
|
|
pg_qsort(blkinfo, num_elements, sizeof(BlockInfoRecord),
|
|
|
|
apw_compare_blockinfo);
|
|
|
|
|
|
|
|
/* Populate shared memory state. */
|
|
|
|
apw_state->block_info_handle = dsm_segment_handle(seg);
|
|
|
|
apw_state->prewarm_start_idx = apw_state->prewarm_stop_idx = 0;
|
|
|
|
apw_state->prewarmed_blocks = 0;
|
|
|
|
|
|
|
|
/* Get the info position of the first block of the next database. */
|
|
|
|
while (apw_state->prewarm_start_idx < num_elements)
|
|
|
|
{
|
Avoid portability issues in autoprewarm.c.
autoprewarm.c mostly considered the number of blocks it might be dealing
with as being int64. This is unnecessary, because NBuffers is declared
as int, and there's been no suggestion that we might widen it in the
foreseeable future. Moreover, using int64 is problematic because the
code expected INT64_FORMAT to work with fscanf(), something we don't
guarantee, and which indeed fails on some older buildfarm members.
On top of that, the module randomly used uint32 rather than int64 variables
to hold block counters in several places, so it would fail anyway if we
ever did have NBuffers wider than that; and it also supposed that pg_qsort
could sort an int64 number of elements, which is wrong on 32-bit machines
(though no doubt a 32-bit machine couldn't actually have that many
buffers).
Hence, change all these variables to plain int.
In passing, avoid shadowing one variable named i with another,
and avoid casting away const in apw_compare_blockinfo.
Discussion: https://postgr.es/m/7773.1525288909@sss.pgh.pa.us
2018-05-04 00:50:27 +08:00
|
|
|
int j = apw_state->prewarm_start_idx;
|
|
|
|
Oid current_db = blkinfo[j].database;
|
2017-08-22 02:43:00 +08:00
|
|
|
|
|
|
|
/*
|
2019-06-17 15:13:16 +08:00
|
|
|
* Advance the prewarm_stop_idx to the first BlockInfoRecord that does
|
2017-08-22 02:43:00 +08:00
|
|
|
* not belong to this database.
|
|
|
|
*/
|
Avoid portability issues in autoprewarm.c.
autoprewarm.c mostly considered the number of blocks it might be dealing
with as being int64. This is unnecessary, because NBuffers is declared
as int, and there's been no suggestion that we might widen it in the
foreseeable future. Moreover, using int64 is problematic because the
code expected INT64_FORMAT to work with fscanf(), something we don't
guarantee, and which indeed fails on some older buildfarm members.
On top of that, the module randomly used uint32 rather than int64 variables
to hold block counters in several places, so it would fail anyway if we
ever did have NBuffers wider than that; and it also supposed that pg_qsort
could sort an int64 number of elements, which is wrong on 32-bit machines
(though no doubt a 32-bit machine couldn't actually have that many
buffers).
Hence, change all these variables to plain int.
In passing, avoid shadowing one variable named i with another,
and avoid casting away const in apw_compare_blockinfo.
Discussion: https://postgr.es/m/7773.1525288909@sss.pgh.pa.us
2018-05-04 00:50:27 +08:00
|
|
|
j++;
|
|
|
|
while (j < num_elements)
|
2017-08-22 02:43:00 +08:00
|
|
|
{
|
Avoid portability issues in autoprewarm.c.
autoprewarm.c mostly considered the number of blocks it might be dealing
with as being int64. This is unnecessary, because NBuffers is declared
as int, and there's been no suggestion that we might widen it in the
foreseeable future. Moreover, using int64 is problematic because the
code expected INT64_FORMAT to work with fscanf(), something we don't
guarantee, and which indeed fails on some older buildfarm members.
On top of that, the module randomly used uint32 rather than int64 variables
to hold block counters in several places, so it would fail anyway if we
ever did have NBuffers wider than that; and it also supposed that pg_qsort
could sort an int64 number of elements, which is wrong on 32-bit machines
(though no doubt a 32-bit machine couldn't actually have that many
buffers).
Hence, change all these variables to plain int.
In passing, avoid shadowing one variable named i with another,
and avoid casting away const in apw_compare_blockinfo.
Discussion: https://postgr.es/m/7773.1525288909@sss.pgh.pa.us
2018-05-04 00:50:27 +08:00
|
|
|
if (current_db != blkinfo[j].database)
|
2017-08-22 02:43:00 +08:00
|
|
|
{
|
|
|
|
/*
|
2019-06-17 15:13:16 +08:00
|
|
|
* Combine BlockInfoRecords for global objects with those of
|
2017-08-22 02:43:00 +08:00
|
|
|
* the database.
|
|
|
|
*/
|
|
|
|
if (current_db != InvalidOid)
|
|
|
|
break;
|
Avoid portability issues in autoprewarm.c.
autoprewarm.c mostly considered the number of blocks it might be dealing
with as being int64. This is unnecessary, because NBuffers is declared
as int, and there's been no suggestion that we might widen it in the
foreseeable future. Moreover, using int64 is problematic because the
code expected INT64_FORMAT to work with fscanf(), something we don't
guarantee, and which indeed fails on some older buildfarm members.
On top of that, the module randomly used uint32 rather than int64 variables
to hold block counters in several places, so it would fail anyway if we
ever did have NBuffers wider than that; and it also supposed that pg_qsort
could sort an int64 number of elements, which is wrong on 32-bit machines
(though no doubt a 32-bit machine couldn't actually have that many
buffers).
Hence, change all these variables to plain int.
In passing, avoid shadowing one variable named i with another,
and avoid casting away const in apw_compare_blockinfo.
Discussion: https://postgr.es/m/7773.1525288909@sss.pgh.pa.us
2018-05-04 00:50:27 +08:00
|
|
|
current_db = blkinfo[j].database;
|
2017-08-22 02:43:00 +08:00
|
|
|
}
|
|
|
|
|
Avoid portability issues in autoprewarm.c.
autoprewarm.c mostly considered the number of blocks it might be dealing
with as being int64. This is unnecessary, because NBuffers is declared
as int, and there's been no suggestion that we might widen it in the
foreseeable future. Moreover, using int64 is problematic because the
code expected INT64_FORMAT to work with fscanf(), something we don't
guarantee, and which indeed fails on some older buildfarm members.
On top of that, the module randomly used uint32 rather than int64 variables
to hold block counters in several places, so it would fail anyway if we
ever did have NBuffers wider than that; and it also supposed that pg_qsort
could sort an int64 number of elements, which is wrong on 32-bit machines
(though no doubt a 32-bit machine couldn't actually have that many
buffers).
Hence, change all these variables to plain int.
In passing, avoid shadowing one variable named i with another,
and avoid casting away const in apw_compare_blockinfo.
Discussion: https://postgr.es/m/7773.1525288909@sss.pgh.pa.us
2018-05-04 00:50:27 +08:00
|
|
|
j++;
|
2017-08-22 02:43:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we reach this point with current_db == InvalidOid, then only
|
2019-06-17 15:13:16 +08:00
|
|
|
* BlockInfoRecords belonging to global objects exist. We can't
|
2017-08-22 02:43:00 +08:00
|
|
|
* prewarm without a database connection, so just bail out.
|
|
|
|
*/
|
|
|
|
if (current_db == InvalidOid)
|
|
|
|
break;
|
|
|
|
|
|
|
|
/* Configure stop point and database for next per-database worker. */
|
Avoid portability issues in autoprewarm.c.
autoprewarm.c mostly considered the number of blocks it might be dealing
with as being int64. This is unnecessary, because NBuffers is declared
as int, and there's been no suggestion that we might widen it in the
foreseeable future. Moreover, using int64 is problematic because the
code expected INT64_FORMAT to work with fscanf(), something we don't
guarantee, and which indeed fails on some older buildfarm members.
On top of that, the module randomly used uint32 rather than int64 variables
to hold block counters in several places, so it would fail anyway if we
ever did have NBuffers wider than that; and it also supposed that pg_qsort
could sort an int64 number of elements, which is wrong on 32-bit machines
(though no doubt a 32-bit machine couldn't actually have that many
buffers).
Hence, change all these variables to plain int.
In passing, avoid shadowing one variable named i with another,
and avoid casting away const in apw_compare_blockinfo.
Discussion: https://postgr.es/m/7773.1525288909@sss.pgh.pa.us
2018-05-04 00:50:27 +08:00
|
|
|
apw_state->prewarm_stop_idx = j;
|
2017-08-22 02:43:00 +08:00
|
|
|
apw_state->database = current_db;
|
|
|
|
Assert(apw_state->prewarm_start_idx < apw_state->prewarm_stop_idx);
|
|
|
|
|
|
|
|
/* If we've run out of free buffers, don't launch another worker. */
|
|
|
|
if (!have_free_buffer())
|
|
|
|
break;
|
|
|
|
|
2020-12-23 02:23:49 +08:00
|
|
|
/*
|
|
|
|
* Likewise, don't launch if we've already been told to shut down.
|
2020-12-25 06:00:43 +08:00
|
|
|
* (The launch would fail anyway, but we might as well skip it.)
|
2020-12-23 02:23:49 +08:00
|
|
|
*/
|
|
|
|
if (ShutdownRequestPending)
|
|
|
|
break;
|
|
|
|
|
2017-08-22 02:43:00 +08:00
|
|
|
/*
|
|
|
|
* Start a per-database worker to load blocks for this database; this
|
|
|
|
* function will return once the per-database worker exits.
|
|
|
|
*/
|
|
|
|
apw_start_database_worker();
|
|
|
|
|
|
|
|
/* Prepare for next database. */
|
|
|
|
apw_state->prewarm_start_idx = apw_state->prewarm_stop_idx;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Clean up. */
|
|
|
|
dsm_detach(seg);
|
|
|
|
LWLockAcquire(&apw_state->lock, LW_EXCLUSIVE);
|
|
|
|
apw_state->block_info_handle = DSM_HANDLE_INVALID;
|
|
|
|
apw_state->pid_using_dumpfile = InvalidPid;
|
|
|
|
LWLockRelease(&apw_state->lock);
|
|
|
|
|
2020-12-23 02:23:49 +08:00
|
|
|
/* Report our success, if we were able to finish. */
|
|
|
|
if (!ShutdownRequestPending)
|
|
|
|
ereport(LOG,
|
|
|
|
(errmsg("autoprewarm successfully prewarmed %d of %d previously-loaded blocks",
|
|
|
|
apw_state->prewarmed_blocks, num_elements)));
|
2017-08-22 02:43:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Prewarm all blocks for one database (and possibly also global objects, if
|
|
|
|
* those got grouped with this database).
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
autoprewarm_database_main(Datum main_arg)
|
|
|
|
{
|
Avoid portability issues in autoprewarm.c.
autoprewarm.c mostly considered the number of blocks it might be dealing
with as being int64. This is unnecessary, because NBuffers is declared
as int, and there's been no suggestion that we might widen it in the
foreseeable future. Moreover, using int64 is problematic because the
code expected INT64_FORMAT to work with fscanf(), something we don't
guarantee, and which indeed fails on some older buildfarm members.
On top of that, the module randomly used uint32 rather than int64 variables
to hold block counters in several places, so it would fail anyway if we
ever did have NBuffers wider than that; and it also supposed that pg_qsort
could sort an int64 number of elements, which is wrong on 32-bit machines
(though no doubt a 32-bit machine couldn't actually have that many
buffers).
Hence, change all these variables to plain int.
In passing, avoid shadowing one variable named i with another,
and avoid casting away const in apw_compare_blockinfo.
Discussion: https://postgr.es/m/7773.1525288909@sss.pgh.pa.us
2018-05-04 00:50:27 +08:00
|
|
|
int pos;
|
2017-08-22 02:43:00 +08:00
|
|
|
BlockInfoRecord *block_info;
|
|
|
|
Relation rel = NULL;
|
|
|
|
BlockNumber nblocks = 0;
|
|
|
|
BlockInfoRecord *old_blk = NULL;
|
|
|
|
dsm_segment *seg;
|
|
|
|
|
|
|
|
/* Establish signal handlers; once that's done, unblock signals. */
|
|
|
|
pqsignal(SIGTERM, die);
|
|
|
|
BackgroundWorkerUnblockSignals();
|
|
|
|
|
|
|
|
/* Connect to correct database and get block information. */
|
|
|
|
apw_init_shmem();
|
|
|
|
seg = dsm_attach(apw_state->block_info_handle);
|
|
|
|
if (seg == NULL)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
|
|
|
|
errmsg("could not map dynamic shared memory segment")));
|
2018-04-06 00:59:32 +08:00
|
|
|
BackgroundWorkerInitializeConnectionByOid(apw_state->database, InvalidOid, 0);
|
2017-08-22 02:43:00 +08:00
|
|
|
block_info = (BlockInfoRecord *) dsm_segment_address(seg);
|
|
|
|
pos = apw_state->prewarm_start_idx;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Loop until we run out of blocks to prewarm or until we run out of free
|
|
|
|
* buffers.
|
|
|
|
*/
|
|
|
|
while (pos < apw_state->prewarm_stop_idx && have_free_buffer())
|
|
|
|
{
|
|
|
|
BlockInfoRecord *blk = &block_info[pos++];
|
|
|
|
Buffer buf;
|
|
|
|
|
|
|
|
CHECK_FOR_INTERRUPTS();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Quit if we've reached records for another database. If previous
|
|
|
|
* blocks are of some global objects, then continue pre-warming.
|
|
|
|
*/
|
|
|
|
if (old_blk != NULL && old_blk->database != blk->database &&
|
|
|
|
old_blk->database != 0)
|
|
|
|
break;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* As soon as we encounter a block of a new relation, close the old
|
|
|
|
* relation. Note that rel will be NULL if try_relation_open failed
|
|
|
|
* previously; in that case, there is nothing to close.
|
|
|
|
*/
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 23:39:09 +08:00
|
|
|
if (old_blk != NULL && old_blk->filenumber != blk->filenumber &&
|
2017-08-22 02:43:00 +08:00
|
|
|
rel != NULL)
|
|
|
|
{
|
|
|
|
relation_close(rel, AccessShareLock);
|
|
|
|
rel = NULL;
|
|
|
|
CommitTransactionCommand();
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Try to open each new relation, but only once, when we first
|
|
|
|
* encounter it. If it's been dropped, skip the associated blocks.
|
|
|
|
*/
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 23:39:09 +08:00
|
|
|
if (old_blk == NULL || old_blk->filenumber != blk->filenumber)
|
2017-08-22 02:43:00 +08:00
|
|
|
{
|
|
|
|
Oid reloid;
|
|
|
|
|
|
|
|
Assert(rel == NULL);
|
|
|
|
StartTransactionCommand();
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 23:39:09 +08:00
|
|
|
reloid = RelidByRelfilenumber(blk->tablespace, blk->filenumber);
|
2017-08-22 02:43:00 +08:00
|
|
|
if (OidIsValid(reloid))
|
|
|
|
rel = try_relation_open(reloid, AccessShareLock);
|
|
|
|
|
|
|
|
if (!rel)
|
|
|
|
CommitTransactionCommand();
|
|
|
|
}
|
|
|
|
if (!rel)
|
|
|
|
{
|
|
|
|
old_blk = blk;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Once per fork, check for fork existence and size. */
|
|
|
|
if (old_blk == NULL ||
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 23:39:09 +08:00
|
|
|
old_blk->filenumber != blk->filenumber ||
|
2017-08-22 02:43:00 +08:00
|
|
|
old_blk->forknum != blk->forknum)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* smgrexists is not safe for illegal forknum, hence check whether
|
|
|
|
* the passed forknum is valid before using it in smgrexists.
|
|
|
|
*/
|
|
|
|
if (blk->forknum > InvalidForkNumber &&
|
|
|
|
blk->forknum <= MAX_FORKNUM &&
|
2021-07-13 05:01:29 +08:00
|
|
|
smgrexists(RelationGetSmgr(rel), blk->forknum))
|
2017-08-22 02:43:00 +08:00
|
|
|
nblocks = RelationGetNumberOfBlocksInFork(rel, blk->forknum);
|
|
|
|
else
|
|
|
|
nblocks = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check whether blocknum is valid and within fork file size. */
|
|
|
|
if (blk->blocknum >= nblocks)
|
|
|
|
{
|
|
|
|
/* Move to next forknum. */
|
|
|
|
old_blk = blk;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Prewarm buffer. */
|
|
|
|
buf = ReadBufferExtended(rel, blk->forknum, blk->blocknum, RBM_NORMAL,
|
|
|
|
NULL);
|
|
|
|
if (BufferIsValid(buf))
|
|
|
|
{
|
|
|
|
apw_state->prewarmed_blocks++;
|
|
|
|
ReleaseBuffer(buf);
|
|
|
|
}
|
|
|
|
|
|
|
|
old_blk = blk;
|
|
|
|
}
|
|
|
|
|
|
|
|
dsm_detach(seg);
|
|
|
|
|
|
|
|
/* Release lock on previous relation. */
|
|
|
|
if (rel)
|
|
|
|
{
|
|
|
|
relation_close(rel, AccessShareLock);
|
|
|
|
CommitTransactionCommand();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Dump information on blocks in shared buffers. We use a text format here
|
|
|
|
* so that it's easy to understand and even change the file contents if
|
|
|
|
* necessary.
|
Avoid portability issues in autoprewarm.c.
autoprewarm.c mostly considered the number of blocks it might be dealing
with as being int64. This is unnecessary, because NBuffers is declared
as int, and there's been no suggestion that we might widen it in the
foreseeable future. Moreover, using int64 is problematic because the
code expected INT64_FORMAT to work with fscanf(), something we don't
guarantee, and which indeed fails on some older buildfarm members.
On top of that, the module randomly used uint32 rather than int64 variables
to hold block counters in several places, so it would fail anyway if we
ever did have NBuffers wider than that; and it also supposed that pg_qsort
could sort an int64 number of elements, which is wrong on 32-bit machines
(though no doubt a 32-bit machine couldn't actually have that many
buffers).
Hence, change all these variables to plain int.
In passing, avoid shadowing one variable named i with another,
and avoid casting away const in apw_compare_blockinfo.
Discussion: https://postgr.es/m/7773.1525288909@sss.pgh.pa.us
2018-05-04 00:50:27 +08:00
|
|
|
* Returns the number of blocks dumped.
|
2017-08-22 02:43:00 +08:00
|
|
|
*/
|
Avoid portability issues in autoprewarm.c.
autoprewarm.c mostly considered the number of blocks it might be dealing
with as being int64. This is unnecessary, because NBuffers is declared
as int, and there's been no suggestion that we might widen it in the
foreseeable future. Moreover, using int64 is problematic because the
code expected INT64_FORMAT to work with fscanf(), something we don't
guarantee, and which indeed fails on some older buildfarm members.
On top of that, the module randomly used uint32 rather than int64 variables
to hold block counters in several places, so it would fail anyway if we
ever did have NBuffers wider than that; and it also supposed that pg_qsort
could sort an int64 number of elements, which is wrong on 32-bit machines
(though no doubt a 32-bit machine couldn't actually have that many
buffers).
Hence, change all these variables to plain int.
In passing, avoid shadowing one variable named i with another,
and avoid casting away const in apw_compare_blockinfo.
Discussion: https://postgr.es/m/7773.1525288909@sss.pgh.pa.us
2018-05-04 00:50:27 +08:00
|
|
|
static int
|
2017-08-22 02:43:00 +08:00
|
|
|
apw_dump_now(bool is_bgworker, bool dump_unlogged)
|
|
|
|
{
|
Avoid portability issues in autoprewarm.c.
autoprewarm.c mostly considered the number of blocks it might be dealing
with as being int64. This is unnecessary, because NBuffers is declared
as int, and there's been no suggestion that we might widen it in the
foreseeable future. Moreover, using int64 is problematic because the
code expected INT64_FORMAT to work with fscanf(), something we don't
guarantee, and which indeed fails on some older buildfarm members.
On top of that, the module randomly used uint32 rather than int64 variables
to hold block counters in several places, so it would fail anyway if we
ever did have NBuffers wider than that; and it also supposed that pg_qsort
could sort an int64 number of elements, which is wrong on 32-bit machines
(though no doubt a 32-bit machine couldn't actually have that many
buffers).
Hence, change all these variables to plain int.
In passing, avoid shadowing one variable named i with another,
and avoid casting away const in apw_compare_blockinfo.
Discussion: https://postgr.es/m/7773.1525288909@sss.pgh.pa.us
2018-05-04 00:50:27 +08:00
|
|
|
int num_blocks;
|
|
|
|
int i;
|
2017-08-22 02:43:00 +08:00
|
|
|
int ret;
|
|
|
|
BlockInfoRecord *block_info_array;
|
|
|
|
BufferDesc *bufHdr;
|
|
|
|
FILE *file;
|
|
|
|
char transient_dump_file_path[MAXPGPATH];
|
|
|
|
pid_t pid;
|
|
|
|
|
|
|
|
LWLockAcquire(&apw_state->lock, LW_EXCLUSIVE);
|
|
|
|
pid = apw_state->pid_using_dumpfile;
|
|
|
|
if (apw_state->pid_using_dumpfile == InvalidPid)
|
|
|
|
apw_state->pid_using_dumpfile = MyProcPid;
|
|
|
|
LWLockRelease(&apw_state->lock);
|
|
|
|
|
|
|
|
if (pid != InvalidPid)
|
|
|
|
{
|
|
|
|
if (!is_bgworker)
|
|
|
|
ereport(ERROR,
|
2022-10-14 14:37:12 +08:00
|
|
|
(errmsg("could not perform block dump because dump file is being used by PID %d",
|
|
|
|
(int) apw_state->pid_using_dumpfile)));
|
2017-08-22 02:43:00 +08:00
|
|
|
|
|
|
|
ereport(LOG,
|
2022-10-14 14:37:12 +08:00
|
|
|
(errmsg("skipping block dump because it is already being performed by PID %d",
|
|
|
|
(int) apw_state->pid_using_dumpfile)));
|
2017-08-22 02:43:00 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
block_info_array =
|
|
|
|
(BlockInfoRecord *) palloc(sizeof(BlockInfoRecord) * NBuffers);
|
|
|
|
|
|
|
|
for (num_blocks = 0, i = 0; i < NBuffers; i++)
|
|
|
|
{
|
|
|
|
uint32 buf_state;
|
|
|
|
|
|
|
|
CHECK_FOR_INTERRUPTS();
|
|
|
|
|
|
|
|
bufHdr = GetBufferDescriptor(i);
|
|
|
|
|
|
|
|
/* Lock each buffer header before inspecting. */
|
|
|
|
buf_state = LockBufHdr(bufHdr);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Unlogged tables will be automatically truncated after a crash or
|
|
|
|
* unclean shutdown. In such cases we need not prewarm them. Dump them
|
|
|
|
* only if requested by caller.
|
|
|
|
*/
|
|
|
|
if (buf_state & BM_TAG_VALID &&
|
|
|
|
((buf_state & BM_PERMANENT) || dump_unlogged))
|
|
|
|
{
|
2022-08-25 03:50:48 +08:00
|
|
|
block_info_array[num_blocks].database = bufHdr->tag.dbOid;
|
|
|
|
block_info_array[num_blocks].tablespace = bufHdr->tag.spcOid;
|
|
|
|
block_info_array[num_blocks].filenumber =
|
|
|
|
BufTagGetRelNumber(&bufHdr->tag);
|
|
|
|
block_info_array[num_blocks].forknum =
|
|
|
|
BufTagGetForkNum(&bufHdr->tag);
|
2017-08-22 02:43:00 +08:00
|
|
|
block_info_array[num_blocks].blocknum = bufHdr->tag.blockNum;
|
|
|
|
++num_blocks;
|
|
|
|
}
|
|
|
|
|
|
|
|
UnlockBufHdr(bufHdr, buf_state);
|
|
|
|
}
|
|
|
|
|
|
|
|
snprintf(transient_dump_file_path, MAXPGPATH, "%s.tmp", AUTOPREWARM_FILE);
|
|
|
|
file = AllocateFile(transient_dump_file_path, "w");
|
|
|
|
if (!file)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode_for_file_access(),
|
|
|
|
errmsg("could not open file \"%s\": %m",
|
|
|
|
transient_dump_file_path)));
|
|
|
|
|
Avoid portability issues in autoprewarm.c.
autoprewarm.c mostly considered the number of blocks it might be dealing
with as being int64. This is unnecessary, because NBuffers is declared
as int, and there's been no suggestion that we might widen it in the
foreseeable future. Moreover, using int64 is problematic because the
code expected INT64_FORMAT to work with fscanf(), something we don't
guarantee, and which indeed fails on some older buildfarm members.
On top of that, the module randomly used uint32 rather than int64 variables
to hold block counters in several places, so it would fail anyway if we
ever did have NBuffers wider than that; and it also supposed that pg_qsort
could sort an int64 number of elements, which is wrong on 32-bit machines
(though no doubt a 32-bit machine couldn't actually have that many
buffers).
Hence, change all these variables to plain int.
In passing, avoid shadowing one variable named i with another,
and avoid casting away const in apw_compare_blockinfo.
Discussion: https://postgr.es/m/7773.1525288909@sss.pgh.pa.us
2018-05-04 00:50:27 +08:00
|
|
|
ret = fprintf(file, "<<%d>>\n", num_blocks);
|
2017-08-22 02:43:00 +08:00
|
|
|
if (ret < 0)
|
|
|
|
{
|
|
|
|
int save_errno = errno;
|
|
|
|
|
|
|
|
FreeFile(file);
|
|
|
|
unlink(transient_dump_file_path);
|
|
|
|
errno = save_errno;
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode_for_file_access(),
|
2018-09-05 02:06:04 +08:00
|
|
|
errmsg("could not write to file \"%s\": %m",
|
2017-08-22 02:43:00 +08:00
|
|
|
transient_dump_file_path)));
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < num_blocks; i++)
|
|
|
|
{
|
|
|
|
CHECK_FOR_INTERRUPTS();
|
|
|
|
|
2022-09-28 21:45:27 +08:00
|
|
|
ret = fprintf(file, "%u,%u,%u,%u,%u\n",
|
2017-08-22 02:43:00 +08:00
|
|
|
block_info_array[i].database,
|
|
|
|
block_info_array[i].tablespace,
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 23:39:09 +08:00
|
|
|
block_info_array[i].filenumber,
|
2017-08-22 02:43:00 +08:00
|
|
|
(uint32) block_info_array[i].forknum,
|
|
|
|
block_info_array[i].blocknum);
|
|
|
|
if (ret < 0)
|
|
|
|
{
|
|
|
|
int save_errno = errno;
|
|
|
|
|
|
|
|
FreeFile(file);
|
|
|
|
unlink(transient_dump_file_path);
|
|
|
|
errno = save_errno;
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode_for_file_access(),
|
2018-09-05 02:06:04 +08:00
|
|
|
errmsg("could not write to file \"%s\": %m",
|
2017-08-22 02:43:00 +08:00
|
|
|
transient_dump_file_path)));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
pfree(block_info_array);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Rename transient_dump_file_path to AUTOPREWARM_FILE to make things
|
|
|
|
* permanent.
|
|
|
|
*/
|
|
|
|
ret = FreeFile(file);
|
|
|
|
if (ret != 0)
|
|
|
|
{
|
|
|
|
int save_errno = errno;
|
|
|
|
|
|
|
|
unlink(transient_dump_file_path);
|
|
|
|
errno = save_errno;
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode_for_file_access(),
|
2018-09-05 02:06:04 +08:00
|
|
|
errmsg("could not close file \"%s\": %m",
|
2017-08-22 02:43:00 +08:00
|
|
|
transient_dump_file_path)));
|
|
|
|
}
|
|
|
|
|
|
|
|
(void) durable_rename(transient_dump_file_path, AUTOPREWARM_FILE, ERROR);
|
|
|
|
apw_state->pid_using_dumpfile = InvalidPid;
|
|
|
|
|
|
|
|
ereport(DEBUG1,
|
2021-02-17 18:24:46 +08:00
|
|
|
(errmsg_internal("wrote block details for %d blocks", num_blocks)));
|
2017-08-22 02:43:00 +08:00
|
|
|
return num_blocks;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* SQL-callable function to launch autoprewarm.
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
autoprewarm_start_worker(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
pid_t pid;
|
|
|
|
|
|
|
|
if (!autoprewarm)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
|
|
|
|
errmsg("autoprewarm is disabled")));
|
|
|
|
|
|
|
|
apw_init_shmem();
|
|
|
|
LWLockAcquire(&apw_state->lock, LW_EXCLUSIVE);
|
|
|
|
pid = apw_state->bgworker_pid;
|
|
|
|
LWLockRelease(&apw_state->lock);
|
|
|
|
|
|
|
|
if (pid != InvalidPid)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
|
2022-10-14 14:37:12 +08:00
|
|
|
errmsg("autoprewarm worker is already running under PID %d",
|
|
|
|
(int) pid)));
|
2017-08-22 02:43:00 +08:00
|
|
|
|
2020-06-15 05:22:47 +08:00
|
|
|
apw_start_leader_worker();
|
2017-08-22 02:43:00 +08:00
|
|
|
|
|
|
|
PG_RETURN_VOID();
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* SQL-callable function to perform an immediate block dump.
|
Avoid portability issues in autoprewarm.c.
autoprewarm.c mostly considered the number of blocks it might be dealing
with as being int64. This is unnecessary, because NBuffers is declared
as int, and there's been no suggestion that we might widen it in the
foreseeable future. Moreover, using int64 is problematic because the
code expected INT64_FORMAT to work with fscanf(), something we don't
guarantee, and which indeed fails on some older buildfarm members.
On top of that, the module randomly used uint32 rather than int64 variables
to hold block counters in several places, so it would fail anyway if we
ever did have NBuffers wider than that; and it also supposed that pg_qsort
could sort an int64 number of elements, which is wrong on 32-bit machines
(though no doubt a 32-bit machine couldn't actually have that many
buffers).
Hence, change all these variables to plain int.
In passing, avoid shadowing one variable named i with another,
and avoid casting away const in apw_compare_blockinfo.
Discussion: https://postgr.es/m/7773.1525288909@sss.pgh.pa.us
2018-05-04 00:50:27 +08:00
|
|
|
*
|
|
|
|
* Note: this is declared to return int8, as insurance against some
|
|
|
|
* very distant day when we might make NBuffers wider than int.
|
2017-08-22 02:43:00 +08:00
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
autoprewarm_dump_now(PG_FUNCTION_ARGS)
|
|
|
|
{
|
Avoid portability issues in autoprewarm.c.
autoprewarm.c mostly considered the number of blocks it might be dealing
with as being int64. This is unnecessary, because NBuffers is declared
as int, and there's been no suggestion that we might widen it in the
foreseeable future. Moreover, using int64 is problematic because the
code expected INT64_FORMAT to work with fscanf(), something we don't
guarantee, and which indeed fails on some older buildfarm members.
On top of that, the module randomly used uint32 rather than int64 variables
to hold block counters in several places, so it would fail anyway if we
ever did have NBuffers wider than that; and it also supposed that pg_qsort
could sort an int64 number of elements, which is wrong on 32-bit machines
(though no doubt a 32-bit machine couldn't actually have that many
buffers).
Hence, change all these variables to plain int.
In passing, avoid shadowing one variable named i with another,
and avoid casting away const in apw_compare_blockinfo.
Discussion: https://postgr.es/m/7773.1525288909@sss.pgh.pa.us
2018-05-04 00:50:27 +08:00
|
|
|
int num_blocks;
|
2017-08-22 02:43:00 +08:00
|
|
|
|
|
|
|
apw_init_shmem();
|
|
|
|
|
|
|
|
PG_ENSURE_ERROR_CLEANUP(apw_detach_shmem, 0);
|
|
|
|
{
|
|
|
|
num_blocks = apw_dump_now(false, true);
|
|
|
|
}
|
|
|
|
PG_END_ENSURE_ERROR_CLEANUP(apw_detach_shmem, 0);
|
|
|
|
|
Avoid portability issues in autoprewarm.c.
autoprewarm.c mostly considered the number of blocks it might be dealing
with as being int64. This is unnecessary, because NBuffers is declared
as int, and there's been no suggestion that we might widen it in the
foreseeable future. Moreover, using int64 is problematic because the
code expected INT64_FORMAT to work with fscanf(), something we don't
guarantee, and which indeed fails on some older buildfarm members.
On top of that, the module randomly used uint32 rather than int64 variables
to hold block counters in several places, so it would fail anyway if we
ever did have NBuffers wider than that; and it also supposed that pg_qsort
could sort an int64 number of elements, which is wrong on 32-bit machines
(though no doubt a 32-bit machine couldn't actually have that many
buffers).
Hence, change all these variables to plain int.
In passing, avoid shadowing one variable named i with another,
and avoid casting away const in apw_compare_blockinfo.
Discussion: https://postgr.es/m/7773.1525288909@sss.pgh.pa.us
2018-05-04 00:50:27 +08:00
|
|
|
PG_RETURN_INT64((int64) num_blocks);
|
2017-08-22 02:43:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Allocate and initialize autoprewarm related shared memory, if not already
|
|
|
|
* done, and set up backend-local pointer to that state. Returns true if an
|
|
|
|
* existing shared memory segment was found.
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
apw_init_shmem(void)
|
|
|
|
{
|
|
|
|
bool found;
|
|
|
|
|
|
|
|
LWLockAcquire(AddinShmemInitLock, LW_EXCLUSIVE);
|
|
|
|
apw_state = ShmemInitStruct("autoprewarm",
|
|
|
|
sizeof(AutoPrewarmSharedState),
|
|
|
|
&found);
|
|
|
|
if (!found)
|
|
|
|
{
|
|
|
|
/* First time through ... */
|
|
|
|
LWLockInitialize(&apw_state->lock, LWLockNewTrancheId());
|
|
|
|
apw_state->bgworker_pid = InvalidPid;
|
|
|
|
apw_state->pid_using_dumpfile = InvalidPid;
|
|
|
|
}
|
|
|
|
LWLockRelease(AddinShmemInitLock);
|
|
|
|
|
2018-02-01 04:12:33 +08:00
|
|
|
LWLockRegisterTranche(apw_state->lock.tranche, "autoprewarm");
|
|
|
|
|
2017-08-22 02:43:00 +08:00
|
|
|
return found;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Clear our PID from autoprewarm shared state.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
apw_detach_shmem(int code, Datum arg)
|
|
|
|
{
|
|
|
|
LWLockAcquire(&apw_state->lock, LW_EXCLUSIVE);
|
|
|
|
if (apw_state->pid_using_dumpfile == MyProcPid)
|
|
|
|
apw_state->pid_using_dumpfile = InvalidPid;
|
|
|
|
if (apw_state->bgworker_pid == MyProcPid)
|
|
|
|
apw_state->bgworker_pid = InvalidPid;
|
|
|
|
LWLockRelease(&apw_state->lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2020-06-15 05:22:47 +08:00
|
|
|
* Start autoprewarm leader worker process.
|
2017-08-22 02:43:00 +08:00
|
|
|
*/
|
|
|
|
static void
|
2020-06-15 05:22:47 +08:00
|
|
|
apw_start_leader_worker(void)
|
2017-08-22 02:43:00 +08:00
|
|
|
{
|
2022-07-16 21:47:27 +08:00
|
|
|
BackgroundWorker worker;
|
2017-08-22 02:43:00 +08:00
|
|
|
BackgroundWorkerHandle *handle;
|
|
|
|
BgwHandleStatus status;
|
|
|
|
pid_t pid;
|
|
|
|
|
2022-07-16 21:47:27 +08:00
|
|
|
MemSet(&worker, 0, sizeof(BackgroundWorker));
|
2017-08-22 02:43:00 +08:00
|
|
|
worker.bgw_flags = BGWORKER_SHMEM_ACCESS;
|
|
|
|
worker.bgw_start_time = BgWorkerStart_ConsistentState;
|
|
|
|
strcpy(worker.bgw_library_name, "pg_prewarm");
|
|
|
|
strcpy(worker.bgw_function_name, "autoprewarm_main");
|
2020-06-15 05:22:47 +08:00
|
|
|
strcpy(worker.bgw_name, "autoprewarm leader");
|
|
|
|
strcpy(worker.bgw_type, "autoprewarm leader");
|
2017-08-22 02:43:00 +08:00
|
|
|
|
|
|
|
if (process_shared_preload_libraries_in_progress)
|
|
|
|
{
|
|
|
|
RegisterBackgroundWorker(&worker);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* must set notify PID to wait for startup */
|
|
|
|
worker.bgw_notify_pid = MyProcPid;
|
|
|
|
|
|
|
|
if (!RegisterDynamicBackgroundWorker(&worker, &handle))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INSUFFICIENT_RESOURCES),
|
|
|
|
errmsg("could not register background process"),
|
|
|
|
errhint("You may need to increase max_worker_processes.")));
|
|
|
|
|
|
|
|
status = WaitForBackgroundWorkerStartup(handle, &pid);
|
|
|
|
if (status != BGWH_STARTED)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INSUFFICIENT_RESOURCES),
|
|
|
|
errmsg("could not start background process"),
|
|
|
|
errhint("More details may be available in the server log.")));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Start autoprewarm per-database worker process.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
apw_start_database_worker(void)
|
|
|
|
{
|
2022-07-16 21:47:27 +08:00
|
|
|
BackgroundWorker worker;
|
2017-08-22 02:43:00 +08:00
|
|
|
BackgroundWorkerHandle *handle;
|
|
|
|
|
2022-07-16 21:47:27 +08:00
|
|
|
MemSet(&worker, 0, sizeof(BackgroundWorker));
|
2017-08-22 02:43:00 +08:00
|
|
|
worker.bgw_flags =
|
|
|
|
BGWORKER_SHMEM_ACCESS | BGWORKER_BACKEND_DATABASE_CONNECTION;
|
|
|
|
worker.bgw_start_time = BgWorkerStart_ConsistentState;
|
2019-03-19 03:21:09 +08:00
|
|
|
worker.bgw_restart_time = BGW_NEVER_RESTART;
|
2017-08-22 02:43:00 +08:00
|
|
|
strcpy(worker.bgw_library_name, "pg_prewarm");
|
|
|
|
strcpy(worker.bgw_function_name, "autoprewarm_database_main");
|
2017-09-01 00:24:47 +08:00
|
|
|
strcpy(worker.bgw_name, "autoprewarm worker");
|
|
|
|
strcpy(worker.bgw_type, "autoprewarm worker");
|
2017-08-22 02:43:00 +08:00
|
|
|
|
|
|
|
/* must set notify PID to wait for shutdown */
|
|
|
|
worker.bgw_notify_pid = MyProcPid;
|
|
|
|
|
|
|
|
if (!RegisterDynamicBackgroundWorker(&worker, &handle))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INSUFFICIENT_RESOURCES),
|
|
|
|
errmsg("registering dynamic bgworker autoprewarm failed"),
|
|
|
|
errhint("Consider increasing configuration parameter \"max_worker_processes\".")));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ignore return value; if it fails, postmaster has died, but we have
|
|
|
|
* checks for that elsewhere.
|
|
|
|
*/
|
|
|
|
WaitForBackgroundWorkerShutdown(handle);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Compare member elements to check whether they are not equal. */
|
|
|
|
#define cmp_member_elem(fld) \
|
|
|
|
do { \
|
|
|
|
if (a->fld < b->fld) \
|
|
|
|
return -1; \
|
|
|
|
else if (a->fld > b->fld) \
|
|
|
|
return 1; \
|
Avoid portability issues in autoprewarm.c.
autoprewarm.c mostly considered the number of blocks it might be dealing
with as being int64. This is unnecessary, because NBuffers is declared
as int, and there's been no suggestion that we might widen it in the
foreseeable future. Moreover, using int64 is problematic because the
code expected INT64_FORMAT to work with fscanf(), something we don't
guarantee, and which indeed fails on some older buildfarm members.
On top of that, the module randomly used uint32 rather than int64 variables
to hold block counters in several places, so it would fail anyway if we
ever did have NBuffers wider than that; and it also supposed that pg_qsort
could sort an int64 number of elements, which is wrong on 32-bit machines
(though no doubt a 32-bit machine couldn't actually have that many
buffers).
Hence, change all these variables to plain int.
In passing, avoid shadowing one variable named i with another,
and avoid casting away const in apw_compare_blockinfo.
Discussion: https://postgr.es/m/7773.1525288909@sss.pgh.pa.us
2018-05-04 00:50:27 +08:00
|
|
|
} while(0)
|
2017-08-22 02:43:00 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* apw_compare_blockinfo
|
|
|
|
*
|
|
|
|
* We depend on all records for a particular database being consecutive
|
|
|
|
* in the dump file; each per-database worker will preload blocks until
|
|
|
|
* it sees a block for some other database. Sorting by tablespace,
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 23:39:09 +08:00
|
|
|
* filenumber, forknum, and blocknum isn't critical for correctness, but
|
2017-08-22 02:43:00 +08:00
|
|
|
* helps us get a sequential I/O pattern.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
apw_compare_blockinfo(const void *p, const void *q)
|
|
|
|
{
|
Avoid portability issues in autoprewarm.c.
autoprewarm.c mostly considered the number of blocks it might be dealing
with as being int64. This is unnecessary, because NBuffers is declared
as int, and there's been no suggestion that we might widen it in the
foreseeable future. Moreover, using int64 is problematic because the
code expected INT64_FORMAT to work with fscanf(), something we don't
guarantee, and which indeed fails on some older buildfarm members.
On top of that, the module randomly used uint32 rather than int64 variables
to hold block counters in several places, so it would fail anyway if we
ever did have NBuffers wider than that; and it also supposed that pg_qsort
could sort an int64 number of elements, which is wrong on 32-bit machines
(though no doubt a 32-bit machine couldn't actually have that many
buffers).
Hence, change all these variables to plain int.
In passing, avoid shadowing one variable named i with another,
and avoid casting away const in apw_compare_blockinfo.
Discussion: https://postgr.es/m/7773.1525288909@sss.pgh.pa.us
2018-05-04 00:50:27 +08:00
|
|
|
const BlockInfoRecord *a = (const BlockInfoRecord *) p;
|
|
|
|
const BlockInfoRecord *b = (const BlockInfoRecord *) q;
|
2017-08-22 02:43:00 +08:00
|
|
|
|
|
|
|
cmp_member_elem(database);
|
|
|
|
cmp_member_elem(tablespace);
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 23:39:09 +08:00
|
|
|
cmp_member_elem(filenumber);
|
2017-08-22 02:43:00 +08:00
|
|
|
cmp_member_elem(forknum);
|
|
|
|
cmp_member_elem(blocknum);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|