Обсуждение: pg_stat_tmp files for dropped databases
Hi,
I've noticed that files for dropped databases aren't removed from pg_stat_tmp. After a cluster-wide VACUUM ANALYSE, and restarting Postgres, all the old database pg_stat_tmp files remain.
Shouldn't these be cleaned up?
--
Thom
Thom
Hi, On 22.2.2014 01:13, Thom Brown wrote: > Hi, > > I've noticed that files for dropped databases aren't removed from > pg_stat_tmp. After a cluster-wide VACUUM ANALYSE, and restarting > Postgres, all the old database pg_stat_tmp files remain. > > Shouldn't these be cleaned up? Yeah, that's a bug in pgstat_recv_dropdb() - instead of building path to the temporary file (in pg_stat_tmp), it builds a path to the permanent file in pg_stat. The permanent files don't exist at that moment, as the postmaster is still runnig and only writes them at shutdown. So the unlink deletes nothing (i.e. returns ENOENT), but the return value is ignored for all the unlink() in pgstat.c. Patch for master attached, needs to be backpatched to 9.3. I'd bet the files survived restart because pg_stat_tmp was kept between the restart. Postmaster walks through all databases, and moves their stats to 'pg_stat' (i.e. removes them from pg_stat_tmp). On the start it does the opposite (move pg_stat -> pg_stat_tmp). But it does not clear the pg_stat_tmp directory, i.e. the files will stay there until removed manually. IIRC it was implemented like this on purpose (what if someone pointed pg_stat_tmp to directory with other files) - only the ownership etc. is checked. So this is expected. Assuming you have just stats in the directory, it's safe to remove the contents of pg_stat_tmp before starting up the database. On systems having pg_stat_tmp pointed to tmpfs, this is basically what happens when rebooting the machine (and why I haven't noticed this on our production systems so far). regards Tomas
Вложения
On 22 February 2014 01:07, Tomas Vondra <tv@fuzzy.cz> wrote:
-- Hi,Yeah, that's a bug in pgstat_recv_dropdb() - instead of building path to
On 22.2.2014 01:13, Thom Brown wrote:
> Hi,
>
> I've noticed that files for dropped databases aren't removed from
> pg_stat_tmp. After a cluster-wide VACUUM ANALYSE, and restarting
> Postgres, all the old database pg_stat_tmp files remain.
>
> Shouldn't these be cleaned up?
the temporary file (in pg_stat_tmp), it builds a path to the permanent
file in pg_stat.
The permanent files don't exist at that moment, as the postmaster is
still runnig and only writes them at shutdown. So the unlink deletes
nothing (i.e. returns ENOENT), but the return value is ignored for all
the unlink() in pgstat.c.
Patch for master attached, needs to be backpatched to 9.3.
I'd bet the files survived restart because pg_stat_tmp was kept between
the restart. Postmaster walks through all databases, and moves their
stats to 'pg_stat' (i.e. removes them from pg_stat_tmp). On the start it
does the opposite (move pg_stat -> pg_stat_tmp).
But it does not clear the pg_stat_tmp directory, i.e. the files will
stay there until removed manually. IIRC it was implemented like this on
purpose (what if someone pointed pg_stat_tmp to directory with other
files) - only the ownership etc. is checked. So this is expected.
Assuming you have just stats in the directory, it's safe to remove the
contents of pg_stat_tmp before starting up the database. On systems
having pg_stat_tmp pointed to tmpfs, this is basically what happens when
rebooting the machine (and why I haven't noticed this on our production
systems so far).
Thanks for confirming and for finding the explanation.
Thom
Tomas Vondra wrote: > On 22.2.2014 01:13, Thom Brown wrote: > > I've noticed that files for dropped databases aren't removed from > > pg_stat_tmp. After a cluster-wide VACUUM ANALYSE, and restarting > > Postgres, all the old database pg_stat_tmp files remain. > Yeah, that's a bug in pgstat_recv_dropdb() - instead of building path to > the temporary file (in pg_stat_tmp), it builds a path to the permanent > file in pg_stat. Pushed, thanks. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services