pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedKilled background writer process
5+ messages / 3 participants
[nested] [flat]
* Killed background writer process
@ 2021-06-04 09:24 Raj kumar <rajkumar820999@gmail.com>
0 siblings, 2 replies; 5+ messages in thread
From: Raj kumar @ 2021-06-04 09:24 UTC (permalink / raw)
To: Pgsql-admin <pgsql-admin@lists.postgresql.org>
Hi Team,
I've killed background writer process for a testing purpose. I found that
after sometime it automatically came up with a new PID without me doing
anything from my end.
How postgres automatically brings it up? Is there any impact on the
Database and connections?
Thanks,
Raj Kumar Narendiran
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Killed background writer process
@ 2021-06-04 09:46 Vijaykumar Jain <vijaykumarjain.github@gmail.com>
parent: Raj kumar <rajkumar820999@gmail.com>
1 sibling, 1 reply; 5+ messages in thread
From: Vijaykumar Jain @ 2021-06-04 09:46 UTC (permalink / raw)
To: Raj kumar <rajkumar820999@gmail.com>; +Cc: Pgsql-admin <pgsql-admin@lists.postgresql.org>
PostgreSQL: Documentation: 13: 19.4. Resource Consumption
<https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-BACKGRO...;
There is a separate server process called the *background writer*, whose
function is to issue writes of “dirty” (new or modified) shared buffers.
When the number of clean shared buffers appears to be insufficient, the
background writer writes some dirty buffers to the file system and marks
them as clean. This reduces the likelihood that server processes handling
user queries will be unable to find clean buffers and have to write dirty
buffers themselves. However, the background writer does cause a net overall
increase in I/O load, because while a repeatedly-dirtied page might
otherwise be written only once per checkpoint interval, the background
writer might write it several times as it is dirtied in the same interval.
The parameters discussed in this subsection can be used to tune the
behavior for local needs.
postgres/README at bc2a389efb3b52d259cefd53c16cfa00742116f2 ·
postgres/postgres (github.com)
<https://github.com/postgres/postgres/blob/bc2a389efb3b52d259cefd53c16cfa00742116f2/src/backend/stora...;
I believe the postmaster checks if it is running, if not it starts again
i think.
in source.
postgres/postmaster.c at bc2a389efb3b52d259cefd53c16cfa00742116f2 ·
postgres/postgres (github.com)
<https://github.com/postgres/postgres/blob/bc2a389efb3b52d259cefd53c16cfa00742116f2/src/backend/postm...;
The same goes for wal writer as well.
On Fri, 4 Jun 2021 at 14:55, Raj kumar <rajkumar820999@gmail.com> wrote:
> Hi Team,
>
> I've killed background writer process for a testing purpose. I found that
> after sometime it automatically came up with a new PID without me doing
> anything from my end.
>
> How postgres automatically brings it up? Is there any impact on the
> Database and connections?
>
> Thanks,
> Raj Kumar Narendiran
>
--
Thanks,
Vijay
Mumbai, India
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Killed background writer process
@ 2021-06-04 09:51 Laurenz Albe <laurenz.albe@cybertec.at>
parent: Raj kumar <rajkumar820999@gmail.com>
1 sibling, 0 replies; 5+ messages in thread
From: Laurenz Albe @ 2021-06-04 09:51 UTC (permalink / raw)
To: Raj kumar <rajkumar820999@gmail.com>; Pgsql-admin <pgsql-admin@lists.postgresql.org>
On Fri, 2021-06-04 at 14:54 +0530, Raj kumar wrote:
> I've killed background writer process for a testing purpose. I found that after sometime
> it automatically came up with a new PID without me doing anything from my end.
>
> How postgres automatically brings it up? Is there any impact on the Database and connections?
The postmaster process keeps track of its children and restarts any background process
that died.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Killed background writer process
@ 2021-06-04 09:52 Vijaykumar Jain <vijaykumarjain.github@gmail.com>
parent: Vijaykumar Jain <vijaykumarjain.github@gmail.com>
0 siblings, 1 reply; 5+ messages in thread
From: Vijaykumar Jain @ 2021-06-04 09:52 UTC (permalink / raw)
To: Raj kumar <rajkumar820999@gmail.com>; +Cc: Pgsql-admin <pgsql-admin@lists.postgresql.org>
not sure if this explains well,
window1 :
postgres=# begin transaction isolation level serializable;
BEGIN
postgres=*# delete from t;
DELETE 200
----- wait while you kill bg writer, should not be impacted.
postgres=*# commit;
COMMIT
in a parallel window, strace the pid of background writer.
window2:
strace -p 13665
strace: Process 13665 attached
select(8, [5 6 7], NULL, NULL, {tv_sec=26, tv_usec=338078}) = ?
ERESTARTNOHAND (To be restarted if no handler)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13668,
si_uid=1001, si_status=0, si_utime=0, si_stime=1} ---
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG, NULL) = 13668
wait4(-1, 0x7fffa51c2474, WNOHANG, NULL) = 0
rt_sigreturn({mask=[]}) = -1 EINTR (Interrupted system call)
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP ABRT BUS FPE SEGV CONT SYS RTMIN
RT_1], NULL, 8) = 0
clone(child_stack=NULL,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7fabf885c610) = 13832
openat(AT_FDCWD, "postmaster.pid", O_RDWR) = 9
read(9, "13665\n/opt/postgresql-13/pgsql/d"..., 8191) = 88
close(9) = 0
getpid() = 13665
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
select(8, [5 6 7], NULL, NULL, {tv_sec=60, tv_usec=0}
window3:
postgres@go:~/postgresql-13.2/src$ ps -aef | grep postgres
root 13607 13594 0 15:04 pts/1 00:00:00 su - postgres
postgres 13608 13607 0 15:04 pts/1 00:00:00 -bash
root 13657 13537 0 15:17 pts/0 00:00:00 su - postgres
postgres 13658 13657 0 15:17 pts/0 00:00:00 -bash
postgres 13665 1 0 15:17 ? 00:00:00
/opt/postgresql-13/local/bin/postgres -D /opt/postgresql-13/pgsql/data
postgres 13667 13665 0 15:17 ? 00:00:00 postgres: checkpointer
postgres 13668 13665 0 15:17 ? 00:00:00 postgres: background
writer
postgres 13669 13665 0 15:17 ? 00:00:00 postgres: walwriter
postgres 13670 13665 0 15:17 ? 00:00:00 postgres: stats
collector
postgres 13671 13665 0 15:17 ? 00:00:00 postgres: logical
replication launcher
postgres 13672 13658 0 15:17 pts/0 00:00:00 psql
postgres 13673 13665 0 15:17 ? 00:00:00 postgres: postgres
postgres [local] idle in transaction
window4:
postgres@go:~$ kill 13668
On Fri, 4 Jun 2021 at 15:16, Vijaykumar Jain <
vijaykumarjain.github@gmail.com> wrote:
> PostgreSQL: Documentation: 13: 19.4. Resource Consumption
> <https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-BACKGRO...;
> There is a separate server process called the *background writer*, whose
> function is to issue writes of “dirty” (new or modified) shared buffers.
> When the number of clean shared buffers appears to be insufficient, the
> background writer writes some dirty buffers to the file system and marks
> them as clean. This reduces the likelihood that server processes handling
> user queries will be unable to find clean buffers and have to write dirty
> buffers themselves. However, the background writer does cause a net overall
> increase in I/O load, because while a repeatedly-dirtied page might
> otherwise be written only once per checkpoint interval, the background
> writer might write it several times as it is dirtied in the same interval.
> The parameters discussed in this subsection can be used to tune the
> behavior for local needs.
>
> postgres/README at bc2a389efb3b52d259cefd53c16cfa00742116f2 ·
> postgres/postgres (github.com)
> <https://github.com/postgres/postgres/blob/bc2a389efb3b52d259cefd53c16cfa00742116f2/src/backend/stora...;
>
> I believe the postmaster checks if it is running, if not it starts again
> i think.
> in source.
> postgres/postmaster.c at bc2a389efb3b52d259cefd53c16cfa00742116f2 ·
> postgres/postgres (github.com)
> <https://github.com/postgres/postgres/blob/bc2a389efb3b52d259cefd53c16cfa00742116f2/src/backend/postm...;
>
> The same goes for wal writer as well.
>
>
> On Fri, 4 Jun 2021 at 14:55, Raj kumar <rajkumar820999@gmail.com> wrote:
>
>> Hi Team,
>>
>> I've killed background writer process for a testing purpose. I found that
>> after sometime it automatically came up with a new PID without me doing
>> anything from my end.
>>
>> How postgres automatically brings it up? Is there any impact on the
>> Database and connections?
>>
>> Thanks,
>> Raj Kumar Narendiran
>>
>
>
> --
> Thanks,
> Vijay
> Mumbai, India
>
--
Thanks,
Vijay
Mumbai, India
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Killed background writer process
@ 2021-06-04 10:05 Raj kumar <rajkumar820999@gmail.com>
parent: Vijaykumar Jain <vijaykumarjain.github@gmail.com>
0 siblings, 0 replies; 5+ messages in thread
From: Raj kumar @ 2021-06-04 10:05 UTC (permalink / raw)
To: Vijaykumar Jain <vijaykumarjain.github@gmail.com>; +Cc: Pgsql-admin <pgsql-admin@lists.postgresql.org>
Hi,
Thanks Laurenz and Vijay.. it really helps!
Thanks & Regards,
Raj Kumar Narendiran
On Fri, 4 Jun 2021, 15:22 Vijaykumar Jain, <vijaykumarjain.github@gmail.com>
wrote:
> not sure if this explains well,
>
>
> window1 :
> postgres=# begin transaction isolation level serializable;
> BEGIN
> postgres=*# delete from t;
> DELETE 200
> ----- wait while you kill bg writer, should not be impacted.
> postgres=*# commit;
> COMMIT
>
>
> in a parallel window, strace the pid of background writer.
> window2:
> strace -p 13665
> strace: Process 13665 attached
> select(8, [5 6 7], NULL, NULL, {tv_sec=26, tv_usec=338078}) = ?
> ERESTARTNOHAND (To be restarted if no handler)
> --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13668,
> si_uid=1001, si_status=0, si_utime=0, si_stime=1} ---
> wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG, NULL) = 13668
> wait4(-1, 0x7fffa51c2474, WNOHANG, NULL) = 0
> rt_sigreturn({mask=[]}) = -1 EINTR (Interrupted system
> call)
> rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP ABRT BUS FPE SEGV CONT SYS RTMIN
> RT_1], NULL, 8) = 0
> clone(child_stack=NULL,
> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
> child_tidptr=0x7fabf885c610) = 13832
> openat(AT_FDCWD, "postmaster.pid", O_RDWR) = 9
> read(9, "13665\n/opt/postgresql-13/pgsql/d"..., 8191) = 88
> close(9) = 0
> getpid() = 13665
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> select(8, [5 6 7], NULL, NULL, {tv_sec=60, tv_usec=0}
>
> window3:
> postgres@go:~/postgresql-13.2/src$ ps -aef | grep postgres
> root 13607 13594 0 15:04 pts/1 00:00:00 su - postgres
> postgres 13608 13607 0 15:04 pts/1 00:00:00 -bash
> root 13657 13537 0 15:17 pts/0 00:00:00 su - postgres
> postgres 13658 13657 0 15:17 pts/0 00:00:00 -bash
> postgres 13665 1 0 15:17 ? 00:00:00
> /opt/postgresql-13/local/bin/postgres -D /opt/postgresql-13/pgsql/data
> postgres 13667 13665 0 15:17 ? 00:00:00 postgres: checkpointer
> postgres 13668 13665 0 15:17 ? 00:00:00 postgres: background
> writer
> postgres 13669 13665 0 15:17 ? 00:00:00 postgres: walwriter
> postgres 13670 13665 0 15:17 ? 00:00:00 postgres: stats
> collector
> postgres 13671 13665 0 15:17 ? 00:00:00 postgres: logical
> replication launcher
> postgres 13672 13658 0 15:17 pts/0 00:00:00 psql
> postgres 13673 13665 0 15:17 ? 00:00:00 postgres: postgres
> postgres [local] idle in transaction
>
>
> window4:
> postgres@go:~$ kill 13668
>
>
>
> On Fri, 4 Jun 2021 at 15:16, Vijaykumar Jain <
> vijaykumarjain.github@gmail.com> wrote:
>
>> PostgreSQL: Documentation: 13: 19.4. Resource Consumption
>> <https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-BACKGRO...;
>> There is a separate server process called the *background writer*, whose
>> function is to issue writes of “dirty” (new or modified) shared buffers.
>> When the number of clean shared buffers appears to be insufficient, the
>> background writer writes some dirty buffers to the file system and marks
>> them as clean. This reduces the likelihood that server processes handling
>> user queries will be unable to find clean buffers and have to write dirty
>> buffers themselves. However, the background writer does cause a net overall
>> increase in I/O load, because while a repeatedly-dirtied page might
>> otherwise be written only once per checkpoint interval, the background
>> writer might write it several times as it is dirtied in the same interval.
>> The parameters discussed in this subsection can be used to tune the
>> behavior for local needs.
>>
>> postgres/README at bc2a389efb3b52d259cefd53c16cfa00742116f2 ·
>> postgres/postgres (github.com)
>> <https://github.com/postgres/postgres/blob/bc2a389efb3b52d259cefd53c16cfa00742116f2/src/backend/stora...;
>>
>> I believe the postmaster checks if it is running, if not it starts again
>> i think.
>> in source.
>> postgres/postmaster.c at bc2a389efb3b52d259cefd53c16cfa00742116f2 ·
>> postgres/postgres (github.com)
>> <https://github.com/postgres/postgres/blob/bc2a389efb3b52d259cefd53c16cfa00742116f2/src/backend/postm...;
>>
>> The same goes for wal writer as well.
>>
>>
>> On Fri, 4 Jun 2021 at 14:55, Raj kumar <rajkumar820999@gmail.com> wrote:
>>
>>> Hi Team,
>>>
>>> I've killed background writer process for a testing purpose. I found
>>> that after sometime it automatically came up with a new PID without me
>>> doing anything from my end.
>>>
>>> How postgres automatically brings it up? Is there any impact on the
>>> Database and connections?
>>>
>>> Thanks,
>>> Raj Kumar Narendiran
>>>
>>
>>
>> --
>> Thanks,
>> Vijay
>> Mumbai, India
>>
>
>
> --
> Thanks,
> Vijay
> Mumbai, India
>
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2021-06-04 10:05 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-06-04 09:24 Killed background writer process Raj kumar <rajkumar820999@gmail.com>
2021-06-04 09:46 ` Vijaykumar Jain <vijaykumarjain.github@gmail.com>
2021-06-04 09:52 ` Vijaykumar Jain <vijaykumarjain.github@gmail.com>
2021-06-04 10:05 ` Raj kumar <rajkumar820999@gmail.com>
2021-06-04 09:51 ` Laurenz Albe <laurenz.albe@cybertec.at>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox