Re: Revisiting Re: BUG #8532: postgres fails to start with timezone-data >=2013e - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Revisiting Re: BUG #8532: postgres fails to start with timezone-data >=2013e
Date
Msg-id 1628.1428787827@sss.pgh.pa.us
Whole thread Raw
In response to Revisiting Re: BUG #8532: postgres fails to start with timezone-data >=2013e  (Ian Stakenvicius <axs@gentoo.org>)
Responses Re: Revisiting Re: BUG #8532: postgres fails to start with timezone-data >=2013e
List pgsql-hackers
Ian Stakenvicius <axs@gentoo.org> writes:
> Hey all -- so I know that Gentoo Linux is likely the only platform this
> bug occurs under, but i got annoyed enough with it that I decided to
> write a patch to fix this issue once and for all (or at least, help keep
> it from happening).

> That thread in question actually dealt with crashing on startup in
> postgresql-9.1 and earlier, but all versions including the latest still
> suffer from the inability to load timezone data via the pg_timezone_*
> tables if /usr/share/zoneinfo contains filesystem loops.

> To that end, the following helps resolve this issue by ensuring
> single-level filesystem loops are detected and skipped.  The top half of
> the patch only applies to postgresql-9.1 and earlier, while the second
> half applies to all versions.

This patch doesn't look right at all.  In the first place, tzdirsub is the
entire subpath, not necessarily just one filename.  In the second place,
limiting the strncmp comparison to strlen(direntry->d_name) exposes you to
false matches --- for example, a current d_name of "foo" would be thought
to match a tzdirsub path of "foobar".  In the third place, relying on
basename(1) does not seem advisable for portability reasons --- use
something from src/port/path.c instead.

It would probably be a good idea to be more specific about what sorts of
loops you are hoping to catch, because this surely won't detect all
possible loops as-is.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: FDW oddity
Next
From: Michael Paquier
Date:
Subject: Re: improving speed of make check-world