View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000757 | Pgpool-II | Bug | public | 2022-06-22 11:12 | 2022-08-18 14:12 |
| Reporter | kuroda.hayato | Assigned To | t-ishii | ||
| Priority | none | Severity | minor | Reproducibility | always |
| Status | feedback | Resolution | open | ||
| Product Version | 4.3.2 | ||||
| Target Version | 4.3.3 | Fixed in Version | 4.3.3 | ||
| Summary | 0000757: pgpool_setup does not work well with PG15b1 | ||||
| Description | While testing a pgpool-II with PG15b1, I found that pgpool_setup did not work well. I'm not sure whether you have already detected that but I reported here. # Configuration I used following versions: PG : HEAD for me, the commit id is e3fcca0d Pgpool-II: V4_3_STABLE # test I executed "pgpool_setup" without any options, and I could not work well. Recovery operations did not complete. Followings were copied from my output ``` $ pgpool_setup PostgreSQL major version: 150 Starting set up in streaming replication mode creating startall and shutdownall creating failover script creating database cluster /home/$user/test_pool/setup/data0...done. update postgresql.conf creating pgpool_remote_start creating basebackup.sh creating recovery.conf creating database cluster /home/$user/test_pool/setup/data1...done. update postgresql.conf creating pgpool_remote_start creating basebackup.sh creating recovery.conf temporarily start data0 cluster to create extensions temporarily start pgpool-II to create standby nodes node_id | hostname | port | status | pg_status | lb_weight | role | pg_role | select_cnt | load_balance_node | replication_delay | replication _state | replication_sync_state | last_status_change ---------+-----------+-------+--------+-----------+-----------+---------+---------+------------+-------------------+-------------------+------------ -------+------------------------+--------------------- 0 | localhost | 11002 | up | up | 0.500000 | primary | primary | 0 | true | 0 | | | 2022-06-17 02:24:44 1 | localhost | 11003 | down | down | 0.500000 | standby | unknown | 0 | false | 0 | | | 2022-06-17 02:24:43 (2 rows) recovery node 1...ERROR: recovery is checking if postmaster is started DETAIL: postmaster on hostname:"localhost" database:"template1" user:"$user" failed to start in 90 second done. creating follow primary script node_id | hostname | port | status | pg_status | lb_weight | role | pg_role | select_cnt | load_balance_node | replication_delay | replication_state | replication_sync_state | last_status_change ---------+-----------+-------+--------+-----------+-----------+---------+---------+------------+-------------------+-------------------+-------------------+------------------------+--------------------- 0 | localhost | 11002 | up | up | 0.500000 | primary | primary | 0 | true | 0 | | | 2022-06-17 02:24:44 1 | localhost | 11003 | down | down | 0.500000 | standby | unknown | 0 | false | 0 | | | 2022-06-17 02:24:43 (2 rows) shutdown all pgpool-II setting for streaming replication mode is done. To start the whole system, use /home/$user/test_pool/setup/startall. To shutdown the whole system, use /home/$user/test_pool/setup/shutdownall. pcp command user name is "$user", password is "$user". Each PostgreSQL, pgpool-II and pcp port is as follows: 0000001 port is 11002 0000002 port is 11003 pgpool port is 11000 pcp port is 11001 The info above is in README.port. ``` | ||||
| Steps To Reproduce | This can reproduce by executing pgpool_setup. | ||||
| Additional Information | I checked the log and found strange lines: ``` 8852 2022-06-17 02:24:44.852 UTC ERROR: function pg_start_backup(unknown, boolean) does not exist at character 8 8852 2022-06-17 02:24:44.852 UTC HINT: No function matches the given name and argument types. You might need to add explicit type casts. 8852 2022-06-17 02:24:44.852 UTC STATEMENT: SELECT pg_start_backup('Streaming Replication', true) ERROR: function pg_start_backup(unknown, boolean) does not exist LINE 1: SELECT pg_start_backup('Streaming Replication', true) ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts. ``` According to the following commit, APIs pg_start_backup()/pg_stop_backup() has been removed from PG15. ``` commit 39969e2a1e4d7f5a37f3ef37d53bbfe171e7d77a Author: Stephen Frost <sfrost@snowman.net> Date: Wed Apr 6 14:41:03 2022 -0400 Remove exclusive backup mode ``` | ||||
| Tags | No tags attached. | ||||
|
|
Yes, PostgreSQL 15 renamed the functions used in pgpool_setup. Moreover, now those functions must be used within a same connection. So I decided to give up to use those functions and am trying to use pg_basebackup command instead. The patch has been already committed in the master branch. I will wait and see how buildfarm reacts. |
|
|
It seems there's no additional errors in buildfarm after I pushed the patch to the master branch. I have pushed the patch to 4.3 to 4.0 stable branches (I have not pushed to 3.7 branch because it needed to solve conflict and I think it' s not worth troubole). |
|
|
I will close the issue unless you have other problems. |
|
|
Thanks for updating! I found your commit in V4_3_STABLE branch. I built a new pgpool and ran pgpool_setup, and the ERROR that calls pg_start_backup() was removed. I tested tutorials written in doc and it was OK. However, while setting up the following output in standard output didn't change: ``` recovery node 1...ERROR: recovery is checking if postmaster is started DETAIL: postmaster on hostname:"localhost" database:"template1" user:"$user" failed to start in 90 second ``` Is this error harmless? I grepped all logs and there were no related ERROR |
|
|
> Is this error harmless? No. > I grepped all logs and there were no related ERROR You'd better to check logs on primary and standby PostgreSQL servers. |
|
|
> You'd better to check logs on primary and standby PostgreSQL servers. Hmm... I picked logs up from data{0, 1}/log directories and I could not find anything. PSA logs that are masked my env info. Note that feel free to close the issue if it is just depends on my machine's environment. data0.log (6,562 bytes)
24210 2022-06-28 02:19:12.074 UTC LOG: starting PostgreSQL 15devel on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), 64-bit
24210 2022-06-28 02:19:12.074 UTC LOG: listening on IPv4 address "0.0.0.0", port 11002
24210 2022-06-28 02:19:12.074 UTC LOG: listening on IPv6 address "::", port 11002
24210 2022-06-28 02:19:12.080 UTC LOG: listening on Unix socket "/tmp/.s.PGSQL.11002"
24214 2022-06-28 02:19:12.087 UTC LOG: database system was shut down at 2022-06-28 02:19:10 UTC
24210 2022-06-28 02:19:12.095 UTC LOG: database system is ready to accept connections
24221 2022-06-28 02:19:12.164 UTC LOG: statement: CREATE EXTENSION pgpool_regclass;
24221 2022-06-28 02:19:12.170 UTC LOG: statement: CREATE EXTENSION pgpool_recovery;
24221 2022-06-28 02:19:12.173 UTC LOG: statement: CREATE DATABASE test;
24260 2022-06-28 02:19:12.428 UTC LOG: statement: SELECT pg_is_in_recovery()
24260 2022-06-28 02:19:12.429 UTC LOG: statement: SELECT current_setting('server_version_num')
24265 2022-06-28 02:19:12.436 UTC LOG: statement: SELECT pg_is_in_recovery()
24267 2022-06-28 02:19:13.288 UTC LOG: statement: SELECT version()
24269 2022-06-28 02:19:13.298 UTC LOG: statement: SELECT pg_is_in_recovery()
24267 2022-06-28 02:19:13.300 UTC LOG: statement: DISCARD ALL
24281 2022-06-28 02:19:13.327 UTC LOG: statement: SELECT current_setting('server_version_num')
24281 2022-06-28 02:19:13.328 UTC LOG: statement: SELECT pg_current_wal_lsn()
24281 2022-06-28 02:19:13.328 UTC LOG: statement: SELECT application_name, state, sync_state FROM pg_stat_replication
24279 2022-06-28 02:19:13.331 UTC LOG: statement: DISCARD ALL
24281 2022-06-28 02:19:13.333 UTC LOG: statement: SELECT pg_is_in_recovery()
24285 2022-06-28 02:19:13.347 UTC LOG: statement: SELECT pg_is_in_recovery()
24283 2022-06-28 02:19:13.353 UTC LOG: statement: DISCARD ALL
24289 2022-06-28 02:19:13.362 UTC LOG: statement: SET statement_timeout To 0
24289 2022-06-28 02:19:13.363 UTC LOG: statement: SELECT pgpool_recovery('basebackup.sh', 'localhost', '$TESTDIR/data1', '11002', 1, '11003', 'localhost')
24212 2022-06-28 02:19:13.454 UTC LOG: checkpoint starting: immediate force wait
24212 2022-06-28 02:19:13.594 UTC LOG: checkpoint complete: wrote 797 buffers (4.9%); 0 WAL file(s) added, 0 removed, 1 recycled; write=0.040 s, sync=0.025 s, total=0.141 s; sync files=199, longest=0.005 s, average=0.001 s; distance=9006 kB, estimate=9006 kB
24289 2022-06-28 02:19:14.049 UTC LOG: statement: SELECT pgpool_remote_start('localhost', '$TESTDIR/data1')
24314 2022-06-28 02:19:23.337 UTC LOG: statement: SELECT pg_current_wal_lsn()
24314 2022-06-28 02:19:23.338 UTC LOG: statement: SELECT application_name, state, sync_state FROM pg_stat_replication
24314 2022-06-28 02:19:23.342 UTC LOG: statement: SELECT pg_is_in_recovery()
24316 2022-06-28 02:19:33.347 UTC LOG: statement: SELECT pg_current_wal_lsn()
24316 2022-06-28 02:19:33.347 UTC LOG: statement: SELECT application_name, state, sync_state FROM pg_stat_replication
24316 2022-06-28 02:19:33.352 UTC LOG: statement: SELECT pg_is_in_recovery()
24326 2022-06-28 02:19:43.356 UTC LOG: statement: SELECT pg_current_wal_lsn()
24326 2022-06-28 02:19:43.357 UTC LOG: statement: SELECT application_name, state, sync_state FROM pg_stat_replication
24326 2022-06-28 02:19:43.361 UTC LOG: statement: SELECT pg_is_in_recovery()
24328 2022-06-28 02:19:53.365 UTC LOG: statement: SELECT pg_current_wal_lsn()
24328 2022-06-28 02:19:53.366 UTC LOG: statement: SELECT application_name, state, sync_state FROM pg_stat_replication
24328 2022-06-28 02:19:53.371 UTC LOG: statement: SELECT pg_is_in_recovery()
24341 2022-06-28 02:20:03.375 UTC LOG: statement: SELECT pg_current_wal_lsn()
24341 2022-06-28 02:20:03.376 UTC LOG: statement: SELECT application_name, state, sync_state FROM pg_stat_replication
24341 2022-06-28 02:20:03.380 UTC LOG: statement: SELECT pg_is_in_recovery()
24344 2022-06-28 02:20:13.385 UTC LOG: statement: SELECT pg_current_wal_lsn()
24344 2022-06-28 02:20:13.386 UTC LOG: statement: SELECT application_name, state, sync_state FROM pg_stat_replication
24344 2022-06-28 02:20:13.390 UTC LOG: statement: SELECT pg_is_in_recovery()
24346 2022-06-28 02:20:23.394 UTC LOG: statement: SELECT pg_current_wal_lsn()
24346 2022-06-28 02:20:23.395 UTC LOG: statement: SELECT application_name, state, sync_state FROM pg_stat_replication
24346 2022-06-28 02:20:23.400 UTC LOG: statement: SELECT pg_is_in_recovery()
24349 2022-06-28 02:20:33.404 UTC LOG: statement: SELECT pg_current_wal_lsn()
24349 2022-06-28 02:20:33.405 UTC LOG: statement: SELECT application_name, state, sync_state FROM pg_stat_replication
24349 2022-06-28 02:20:33.410 UTC LOG: statement: SELECT pg_is_in_recovery()
24359 2022-06-28 02:20:43.414 UTC LOG: statement: SELECT pg_current_wal_lsn()
24359 2022-06-28 02:20:43.415 UTC LOG: statement: SELECT application_name, state, sync_state FROM pg_stat_replication
24359 2022-06-28 02:20:43.419 UTC LOG: statement: SELECT pg_is_in_recovery()
24362 2022-06-28 02:20:53.423 UTC LOG: statement: SELECT pg_current_wal_lsn()
24362 2022-06-28 02:20:53.424 UTC LOG: statement: SELECT application_name, state, sync_state FROM pg_stat_replication
24362 2022-06-28 02:20:53.428 UTC LOG: statement: SELECT pg_is_in_recovery()
24367 2022-06-28 02:20:59.102 UTC LOG: statement: SELECT pg_is_in_recovery()
24365 2022-06-28 02:20:59.104 UTC LOG: statement: DISCARD ALL
24374 2022-06-28 02:20:59.127 UTC LOG: statement: SELECT pg_is_in_recovery()
24372 2022-06-28 02:20:59.129 UTC LOG: statement: DISCARD ALL
24210 2022-06-28 02:21:00.138 UTC LOG: received fast shutdown request
24210 2022-06-28 02:21:00.141 UTC LOG: aborting any active transactions
24218 2022-06-28 02:21:00.142 UTC FATAL: terminating background worker "lrg launcher" due to administrator command
24210 2022-06-28 02:21:00.142 UTC LOG: background worker "lrg launcher" (PID 24218) exited with exit code 1
24210 2022-06-28 02:21:00.142 UTC LOG: background worker "logical replication launcher" (PID 24219) exited with exit code 1
24212 2022-06-28 02:21:00.143 UTC LOG: shutting down
24212 2022-06-28 02:21:00.256 UTC LOG: checkpoint starting: shutdown immediate
24212 2022-06-28 02:21:00.343 UTC LOG: checkpoint complete: wrote 54 buffers (0.3%); 0 WAL file(s) added, 0 removed, 2 recycled; write=0.003 s, sync=0.018 s, total=0.089 s; sync files=15, longest=0.015 s, average=0.002 s; distance=32768 kB, estimate=32768 kB
24210 2022-06-28 02:21:00.351 UTC LOG: database system is shut down
data1.log (2,454 bytes)
24210 2022-06-28 02:19:12.074 UTC LOG: starting PostgreSQL 15devel on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), 64-bit
24210 2022-06-28 02:19:12.074 UTC LOG: listening on IPv4 address "0.0.0.0", port 11002
24210 2022-06-28 02:19:12.074 UTC LOG: listening on IPv6 address "::", port 11002
24210 2022-06-28 02:19:12.080 UTC LOG: listening on Unix socket "/tmp/.s.PGSQL.11002"
24214 2022-06-28 02:19:12.087 UTC LOG: database system was shut down at 2022-06-28 02:19:10 UTC
24210 2022-06-28 02:19:12.095 UTC LOG: database system is ready to accept connections
24221 2022-06-28 02:19:12.164 UTC LOG: statement: CREATE EXTENSION pgpool_regclass;
24221 2022-06-28 02:19:12.170 UTC LOG: statement: CREATE EXTENSION pgpool_recovery;
24221 2022-06-28 02:19:12.173 UTC LOG: statement: CREATE DATABASE test;
24260 2022-06-28 02:19:12.428 UTC LOG: statement: SELECT pg_is_in_recovery()
24260 2022-06-28 02:19:12.429 UTC LOG: statement: SELECT current_setting('server_version_num')
24265 2022-06-28 02:19:12.436 UTC LOG: statement: SELECT pg_is_in_recovery()
24267 2022-06-28 02:19:13.288 UTC LOG: statement: SELECT version()
24269 2022-06-28 02:19:13.298 UTC LOG: statement: SELECT pg_is_in_recovery()
24267 2022-06-28 02:19:13.300 UTC LOG: statement: DISCARD ALL
24281 2022-06-28 02:19:13.327 UTC LOG: statement: SELECT current_setting('server_version_num')
24281 2022-06-28 02:19:13.328 UTC LOG: statement: SELECT pg_current_wal_lsn()
24281 2022-06-28 02:19:13.328 UTC LOG: statement: SELECT application_name, state, sync_state FROM pg_stat_replication
24279 2022-06-28 02:19:13.331 UTC LOG: statement: DISCARD ALL
24281 2022-06-28 02:19:13.333 UTC LOG: statement: SELECT pg_is_in_recovery()
24285 2022-06-28 02:19:13.347 UTC LOG: statement: SELECT pg_is_in_recovery()
24283 2022-06-28 02:19:13.353 UTC LOG: statement: DISCARD ALL
24289 2022-06-28 02:19:13.362 UTC LOG: statement: SET statement_timeout To 0
24289 2022-06-28 02:19:13.363 UTC LOG: statement: SELECT pgpool_recovery('basebackup.sh', 'localhost', '$TESTDIR/data1', '11002', 1, '11003', 'localhost')
24212 2022-06-28 02:19:13.454 UTC LOG: checkpoint starting: immediate force wait
24212 2022-06-28 02:19:13.594 UTC LOG: checkpoint complete: wrote 797 buffers (4.9%); 0 WAL file(s) added, 0 removed, 1 recycled; write=0.040 s, sync=0.025 s, total=0.141 s; sync files=199, longest=0.005 s, average=0.001 s; distance=9006 kB, estimate=9006 kB
|
|
|
It looks like data1.log is just a copy of data0.log. data1.log should have the real log after these: 24289 2022-06-28 02:19:13.363 UTC LOG: statement: SELECT pgpool_recovery('basebackup.sh', 'localhost', '$TESTDIR/data1', '11002', 1, '11003', 'localhost') 24212 2022-06-28 02:19:13.454 UTC LOG: checkpoint starting: immediate force wait 24212 2022-06-28 02:19:13.594 UTC LOG: checkpoint complete: wrote 797 buffers (4.9%); 0 WAL file(s) added, 0 removed, 1 recycled; write=0.040 s, sync=0.025 s, total=0.141 s; sync files=199, longest=0.005 s, average=0.001 s; distance=9006 kB, estimate=9006 kB Attached is my data1.log. Tuesday.log (5,978 bytes)
500637 2022-06-28 11:59:13.125 JST LOG: starting PostgreSQL 15beta1 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, 64-bit
500637 2022-06-28 11:59:13.125 JST LOG: listening on IPv4 address "0.0.0.0", port 11002
500637 2022-06-28 11:59:13.125 JST LOG: listening on IPv6 address "::", port 11002
500637 2022-06-28 11:59:13.130 JST LOG: listening on Unix socket "/tmp/.s.PGSQL.11002"
500641 2022-06-28 11:59:13.135 JST LOG: database system was shut down at 2022-06-28 11:59:12 JST
500637 2022-06-28 11:59:13.141 JST LOG: database system is ready to accept connections
500647 2022-06-28 11:59:13.231 JST LOG: statement: CREATE EXTENSION pgpool_regclass;
500647 2022-06-28 11:59:13.232 JST ERROR: extension "pgpool_regclass" is not available
500647 2022-06-28 11:59:13.232 JST DETAIL: Could not open extension control file "/usr/local/src/pgsql/current/share/extension/pgpool_regclass.control": No such file or directory.
500647 2022-06-28 11:59:13.232 JST HINT: The extension must first be installed on the system where PostgreSQL is running.
500647 2022-06-28 11:59:13.232 JST STATEMENT: CREATE EXTENSION pgpool_regclass;
500647 2022-06-28 11:59:13.232 JST LOG: statement: CREATE EXTENSION pgpool_recovery;
500647 2022-06-28 11:59:13.240 JST LOG: statement: CREATE DATABASE test;
500687 2022-06-28 11:59:13.383 JST LOG: statement: SELECT pg_is_in_recovery()
500687 2022-06-28 11:59:13.384 JST LOG: statement: SELECT current_setting('server_version_num')
500691 2022-06-28 11:59:13.386 JST LOG: statement: SELECT pg_is_in_recovery()
500694 2022-06-28 11:59:14.317 JST LOG: statement: SELECT version()
500696 2022-06-28 11:59:14.329 JST LOG: statement: SELECT pg_is_in_recovery()
500694 2022-06-28 11:59:14.330 JST LOG: statement: DISCARD ALL
500707 2022-06-28 11:59:14.361 JST LOG: statement: SELECT current_setting('server_version_num')
500707 2022-06-28 11:59:14.362 JST LOG: statement: SELECT pg_current_wal_lsn()
500707 2022-06-28 11:59:14.363 JST LOG: statement: SELECT application_name, state, sync_state FROM pg_stat_replication
500707 2022-06-28 11:59:14.368 JST LOG: statement: SELECT pg_is_in_recovery()
500708 2022-06-28 11:59:14.371 JST LOG: statement: SELECT version()
500708 2022-06-28 11:59:14.374 JST LOG: statement: DISCARD ALL
500712 2022-06-28 11:59:14.398 JST LOG: statement: SELECT pg_is_in_recovery()
500710 2022-06-28 11:59:14.404 JST LOG: statement: DISCARD ALL
500717 2022-06-28 11:59:14.415 JST LOG: statement: SET statement_timeout To 0
500717 2022-06-28 11:59:14.416 JST LOG: statement: SELECT pgpool_recovery('basebackup.sh', 'localhost', '/home/t-ishii/work/Pgpool-II/current/z/data1', '11002', 1, '11003', 'localhost')
500639 2022-06-28 11:59:14.466 JST LOG: checkpoint starting: immediate force wait
500639 2022-06-28 11:59:14.568 JST LOG: checkpoint complete: wrote 763 buffers (4.7%); 0 WAL file(s) added, 0 removed, 1 recycled; write=0.018 s, sync=0.034 s, total=0.103 s; sync files=193, longest=0.003 s, average=0.001 s; distance=9366 kB, estimate=9366 kB
500798 2022-06-28 11:59:15.157 JST LOG: starting PostgreSQL 15beta1 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, 64-bit
500798 2022-06-28 11:59:15.158 JST LOG: listening on IPv4 address "0.0.0.0", port 11003
500798 2022-06-28 11:59:15.158 JST LOG: listening on IPv6 address "::", port 11003
500798 2022-06-28 11:59:15.163 JST LOG: listening on Unix socket "/tmp/.s.PGSQL.11003"
500802 2022-06-28 11:59:15.170 JST LOG: database system was interrupted; last known up at 2022-06-28 11:59:14 JST
500802 2022-06-28 11:59:15.358 JST LOG: entering standby mode
500802 2022-06-28 11:59:15.369 JST LOG: restored log file "000000010000000000000002" from archive
500802 2022-06-28 11:59:15.402 JST LOG: redo starts at 0/2000028
500802 2022-06-28 11:59:15.406 JST LOG: consistent recovery state reached at 0/2000100
500798 2022-06-28 11:59:15.406 JST LOG: database system is ready to accept read-only connections
500811 2022-06-28 11:59:15.412 JST LOG: started streaming WAL from primary at 0/3000000 on timeline 1
500815 2022-06-28 11:59:17.928 JST LOG: statement: SELECT pg_is_in_recovery()
500815 2022-06-28 11:59:17.929 JST LOG: statement: SELECT current_setting('server_version_num')
500825 2022-06-28 11:59:17.969 JST LOG: statement: SELECT pg_is_in_recovery()
500835 2022-06-28 11:59:17.998 JST LOG: statement: SELECT pg_is_in_recovery()
500811 2022-06-28 11:59:19.173 JST LOG: replication terminated by primary server
500811 2022-06-28 11:59:19.173 JST DETAIL: End of WAL reached on timeline 1 at 0/40000A0.
500811 2022-06-28 11:59:19.173 JST FATAL: could not send end-of-streaming message to primary: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
no COPY in progress
500802 2022-06-28 11:59:19.177 JST LOG: invalid record length at 0/40000A0: wanted 24, got 0
500847 2022-06-28 11:59:19.179 JST FATAL: could not connect to the primary server: connection to server at "localhost" (127.0.0.1), port 11002 failed: Connection refused
Is the server running on that host and accepting TCP/IP connections?
500802 2022-06-28 11:59:19.181 JST LOG: waiting for WAL to become available at 0/40000B8
500798 2022-06-28 11:59:19.210 JST LOG: received fast shutdown request
500798 2022-06-28 11:59:19.212 JST LOG: aborting any active transactions
500800 2022-06-28 11:59:19.214 JST LOG: shutting down
500800 2022-06-28 11:59:19.214 JST LOG: restartpoint starting: shutdown immediate
500800 2022-06-28 11:59:19.236 JST LOG: restartpoint complete: wrote 2 buffers (0.0%); 0 WAL file(s) added, 0 removed, 2 recycled; write=0.006 s, sync=0.003 s, total=0.023 s; sync files=1, longest=0.003 s, average=0.003 s; distance=32768 kB, estimate=32768 kB
500800 2022-06-28 11:59:19.236 JST LOG: recovery restart point at 0/4000028
500798 2022-06-28 11:59:19.238 JST LOG: database system is shut down
|
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2022-06-22 11:12 | kuroda.hayato | New Issue | |
| 2022-06-23 10:43 | t-ishii | Assigned To | => t-ishii |
| 2022-06-23 10:43 | t-ishii | Status | new => assigned |
| 2022-06-23 10:46 | t-ishii | Note Added: 0004059 | |
| 2022-06-27 15:53 | t-ishii | Note Added: 0004061 | |
| 2022-06-27 15:54 | t-ishii | Note Added: 0004062 | |
| 2022-06-27 15:54 | t-ishii | Status | assigned => feedback |
| 2022-06-28 10:06 | kuroda.hayato | Note Added: 0004063 | |
| 2022-06-28 10:06 | kuroda.hayato | Status | feedback => assigned |
| 2022-06-28 11:08 | t-ishii | Note Added: 0004069 | |
| 2022-06-28 11:28 | kuroda.hayato | Note Added: 0004077 | |
| 2022-06-28 11:28 | kuroda.hayato | File Added: data0.log | |
| 2022-06-28 11:28 | kuroda.hayato | File Added: data1.log | |
| 2022-06-28 12:07 | t-ishii | Note Added: 0004084 | |
| 2022-06-28 12:07 | t-ishii | File Added: Tuesday.log | |
| 2022-06-28 12:07 | t-ishii | Note Edited: 0004084 | |
| 2022-08-18 14:12 | administrator | Fixed in Version | => 4.3.3 |
| 2022-08-18 14:12 | administrator | Target Version | => 4.3.3 |
| 2022-08-18 14:12 | administrator | Status | assigned => feedback |
