Re: fcntl(SETLK) [was Re: 2nd update on TOAST]

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: fcntl(SETLK) [was Re: 2nd update on TOAST]
Дата
Msg-id Pine.LNX.4.21.0007081516550.348-100000@localhost.localdomain
обсуждение исходный текст
Ответ на Re: fcntl(SETLK) [was Re: 2nd update on TOAST]  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: fcntl(SETLK) [was Re: 2nd update on TOAST]
Re: fcntl(SETLK) [was Re: 2nd update on TOAST]
Список pgsql-hackers
Tom Lane writes:

> Bruce and I were just talking by phone about this, and we realized that
> there is a completely different approach to making that decision: if you
> want to know whether there's an old postmaster connected to a socket
> file, try to connect to the old postmaster!

It seems that that would completely reverse the assumption of risk.
Currently, the postmaster may fail to start because there's a stale socket
file lying around, out of respect to a running colleague. With this idea
it would be the running postmaster's job to "defend" his socket against
newly starting colleagues. That doesn't seem fair.

What are our problems?

There's a possible DoS attack when someone else comes first and creates a
file /tmp/.s.PGSQL.5432. But detecting whether there's another program
running on that socket (if it's a socket) isn't going to help because you
most likely won't be able to delete it anyway. The solution to this is to
make the path of the socket file configurable more easily so that the
administrator has the choice of putting it a safer place that he prepared
appropriately.

A complementary solution is of course to add an option to run without Unix
socket, since we don't rely on the socket file for data directory locking
anymore. In fact, does anybody mind if I add such an option? We can have

tcpip_socket = yes|no
unix_socket = yes|no

(Security-conscious users may choose to turn off both. :-))

The other problem is a socket file left behind by a crashed postmaster. I
don't consider this such a big problem; a crashed postmaster is not the
normal mode of operation. The friendly message we have right now seems
alright to me. And it's a way of tell that the postmaster crashed at all.

One idea to get the pid in there somewhere is creating a socket file
"/tmp/.s.PGSQL.port.pid" and making /tmp/.s.PGSQL.port a symlink to it.
Then clients don't know the difference, but the server knows the pid and
can take appropriate action. Or make the symlink the other way around, not
sure.


-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: crypt and MD5 - still not wanted
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Re: postgres TODO