Thread: BUG #6676: checkpointer does not work by SIGINT.
The following bug has been logged on the website: Bug reference: 6676 Logged by: Tomonari Katsumata Email address: katsumata.tomonari@po.ntts.co.jp PostgreSQL version: Unsupported/Unknown Operating system: RHEL 5.7 x86_64 Description:=20=20=20=20=20=20=20=20 Hi, Now I'm testing the behavior of checkpointer, and I found a difference with PostgreSQL9.1 behavior. When I send SIGINT signal to writer process on PostgreSQL9.1,=20 writer process starts checkpoint. But, when I send SIGINT signal to checkpointer on PostgreSQL9.2beta2,=20 checkpointer doesn't start checkpoint. <PostgreSQL 9.1.3> change the config file(postgresql.conf) to log information about checkpoint. log_checkpoints =3D on logging_collector =3D on $ psql postgres -c "create table tbl(i int)" CREATE TABLE $ psql postgres -c "insert into tbl values(1);" INSERT 0 1 $ ps faxww | grep postgres | grep "writer process" 19706 ? Ss 0:00 \_ postgres: writer process 19707 ? Ss 0:00 \_ postgres: wal writer process $ kill -2 19706 <log messages> LOG: checkpoint starting: LOG: checkpoint complete: wrote 1 buffers (0.0%); 0 transaction log file(s) added, 0 removed, 0 recycled; write=3D0.000 s, sync=3D0.001 s, total=3D0.00= 4 s; sync files=3D1, longest=3D0.001 s, average=3D0.001 s =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D <PostgreSQL 9.2beta2> change the config file(postgresql.conf) to log information about checkpoint. log_checkpoints =3D on logging_collector =3D on $ psql postgres -c "create table tbl(i int);" CREATE TABLE $ psql postgres -c "insert into tbl values(1);" INSERT 0 1 $ ps faxww | grep checkpointer 11526 pts/3 S+ 0:00 | \_ grep checkpointer 11482 ? Ss 0:00 \_ postgres: checkpointer process=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20 $ kill -2 11482 <no log messages> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I know "latch" is introduced on PostgreSQL9.2,=20 but I'm not sure this is a bug or not. Is this a desirable behavior of "latch" ?
katsumata.tomonari@po.ntts.co.jp writes: > Now I'm testing the behavior of checkpointer, > and I found a difference with PostgreSQL9.1 behavior. > When I send SIGINT signal to writer process on PostgreSQL9.1, > writer process starts checkpoint. > But, when I send SIGINT signal to checkpointer on PostgreSQL9.2beta2, > checkpointer doesn't start checkpoint. AFAICT, the checkpointer does consider starting a checkpoint, but it decides not to do one, because of this recent change: http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=18fb9d8d21a28caddb72c7ffbdd7b96d52ff9724 If you had done enough updates since the last checkpoint, it would do one. So this isn't a bug, but an intentional reduction in checkpoint frequency. (Note that sending SIGINT is not, and never has been, equivalent to forcing a checkpoint.) regards, tom lane
Hi, Thank you for explanation about it. I've understood that it is intended thing. Sorry to bother you. regards, (2012/06/07 2:05), Tom Lane wrote: > katsumata.tomonari@po.ntts.co.jp writes: >> Now I'm testing the behavior of checkpointer, >> and I found a difference with PostgreSQL9.1 behavior. >> When I send SIGINT signal to writer process on PostgreSQL9.1, >> writer process starts checkpoint. >> But, when I send SIGINT signal to checkpointer on PostgreSQL9.2beta2, >> checkpointer doesn't start checkpoint. > AFAICT, the checkpointer does consider starting a checkpoint, but it > decides not to do one, because of this recent change: > http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=18fb9d8d21a28caddb72c7ffbdd7b96d52ff9724 > > If you had done enough updates since the last checkpoint, it would do > one. So this isn't a bug, but an intentional reduction in checkpoint > frequency. (Note that sending SIGINT is not, and never has been, > equivalent to forcing a checkpoint.) > > regards, tom lane >
Tomonari Katsumata <katsumata.tomonari@po.ntts.co.jp> writes: > Thank you for explanation about it. > I've understood that it is intended thing. > Sorry to bother you. No, actually it's a good thing you brought it up, because we're now reconsidering whether that patch was a good idea or not ... http://archives.postgresql.org/pgsql-hackers/2012-06/msg00160.php regards, tom lane