Re: [HACKERS] Proposal : For Auto-Prewarm. - Mailing list pgsql-hackers
From | Neha Sharma |
---|---|
Subject | Re: [HACKERS] Proposal : For Auto-Prewarm. |
Date | |
Msg-id | CANiYTQsraV04hOZk=eXRZt6SWiWvqzH+KweaZEcJcsF52y0E3A@mail.gmail.com Whole thread Raw |
Responses |
Re: [HACKERS] Proposal : For Auto-Prewarm.
|
List | pgsql-hackers |
Hi,
--
Regards,
Neha Sharma
I have been testing this feature for a while and below are the observations for few scenarios.
Observation:
scenario 1: If we set pg_prewarm.dump_interval = -1.0,we get an additional warning message in logfile and instead of ending the task of auto-dump it executes successfully.
[centos@test-machine bin]$ more logfile
2017-06-06 08:39:53.127 GMT [21905] WARNING: invalid value for parameter "pg_prewarm.dump_interval": "-1.0"
2017-06-06 08:39:53.127 GMT [21905] HINT: Valid units for this parameter are "ms", "s", "min", "h", and "d".
2017-06-06 08:39:53.127 GMT [21905] LOG: listening on IPv6 address "::1", port 5432
2017-06-06 08:39:53.127 GMT [21905] LOG: listening on IPv4 address "127.0.0.1", port 5432
2017-06-06 08:39:53.130 GMT [21905] LOG: listening on Unix socket "/tmp/.s.PGSQL.5432"
2017-06-06 08:39:53.143 GMT [21906] LOG: database system was shut down at 2017-06-06 08:38:20 GMT
2017-06-06 08:39:53.155 GMT [21905] LOG: database system is ready to accept connections
2017-06-06 08:39:53.155 GMT [21912] LOG: autoprewarm has started
[centos@test-machine bin]$ ps -ef | grep prewarm
centos 21912 21905 0 08:39 ? 00:00:00 postgres: bgworker: autoprewarm
[centos@test-machine bin]$ ./psql postgres
psql (10beta1)
Type "help" for help.
postgres=# show pg_prewarm.dump_interval;
pg_prewarm.dump_interval
--------------------------
5min
(1 row)
scenario 2: If we set pg_prewarm.dump_interval = 0.0,we get an additional warning message in logfile and the message states that the task was started and the worker thread it is also active,but the dump_interval duration is set to default 5 min (300 sec) instead of 0.
[centos@test-machine bin]$ ps -ef | grep prewarm
centos 21980 21973 0 08:54 ? 00:00:00 postgres: bgworker: autoprewarm
[centos@test-machine bin]$ more logfile
2017-06-06 09:20:52.436 GMT [22223] WARNING: invalid value for parameter "pg_prewarm.dump_interval": "0.0"
2017-06-06 09:20:52.436 GMT [22223] HINT: Valid units for this parameter are "ms", "s", "min", "h", and "d".
2017-06-06 09:20:52.436 GMT [22223] LOG: listening on IPv6 address "::1", port 5432
2017-06-06 09:20:52.437 GMT [22223] LOG: listening on IPv4 address "127.0.0.1", port 5432
2017-06-06 09:20:52.439 GMT [22223] LOG: listening on Unix socket "/tmp/.s.PGSQL.5432"
2017-06-06 09:20:52.452 GMT [22224] LOG: database system was shut down at 2017-06-06 09:19:49 GMT
2017-06-06 09:20:52.455 GMT [22223] LOG: database system is ready to accept connections
2017-06-06 09:20:52.455 GMT [22230] LOG: autoprewarm has started
[centos@test-machine bin]$ ./psql postgres
psql (10beta1)
Type "help" for help.
postgres=# show pg_prewarm.dump_interval;
pg_prewarm.dump_interval
--------------------------
5min
(1 row)
On Mon, Jun 5, 2017 at 8:06 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Jun 5, 2017 at 7:58 AM, Rafia Sabih
<rafia.sabih@enterprisedb.com> wrote:
> I had a look at the patch from stylistic/formatting point of view,
> please find the attached patch for the suggested modifications.
Many of these seem worse, like these ones:
- * Quit if we've reached records for another database. Unless the
+ * Quit if we've reached records of another database. Unless the
- * When we reach a new relation, close the old one. Note, however,
- * that the previous try_relation_open may have failed, in which case
- * rel will be NULL.
+ * On reaching a new relation, close the old one. Note, that the
+ * previous try_relation_open may have failed, in which case rel will
+ * be NULL.
- * Try to open each new relation, but only once, when we first
- * encounter it. If it's been dropped, skip the associated blocks.
+ * Each relation is open only once at it's first encounter. If it's
+ * been dropped, skip the associated blocks.
Others are better, like these:
- (errmsg("could not continue autoprewarm worker is
already running under PID %d",
+ (errmsg("autoprewarm worker is already running under PID %d",
- * Start of prewarm per-database worker. This will try to load blocks of one
+ * Start prewarm per-database worker, which will load blocks of one
Others don't really seem better or worse, like:
- * Register a per-database worker to load new database's block. And
- * wait until they finish their job to launch next one.
+ * Register a per-database worker to load new database's block. Wait
+ * until they finish their job to launch next one.
IMHO, there's still a good bit of work needed here to make this sound
like American English. For example:
- * It is a bgworker which automatically records information about blocks
- * which were present in buffer pool before server shutdown and then
- * prewarm the buffer pool upon server restart with those blocks.
+ * It is a bgworker process that automatically records information about
+ * blocks which were present in buffer pool before server
shutdown and then
+ * prewarms the buffer pool upon server restart with those blocks.
This construction "It is a..." without a clear referent seems to be
standard in Indian English, but it looks wrong to English speakers
from other parts of the world, or at least to me.
+ * Since there could be at max one worker who could do a prewarm, hence,
+ * acquiring locks is not required before setting skip_prewarm_on_restart.
To me, adding a comma before hence looks like a significant
improvement, but the word hence itself seems out-of-place. Also, I'd
change "at max" to "at most" and maybe reword the sentence a little.
There's a lot of little things like this which I have tended be quite
strict about changing before commit; I occasionally wonder whether
it's really worth the effort. It's not really wrong, it just sounds
weird to me as an American.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Regards,
Neha Sharma
pgsql-hackers by date: