Re: 2PC-induced lockup
От | Florian G. Pflug |
---|---|
Тема | Re: 2PC-induced lockup |
Дата | |
Msg-id | 46958BFA.3060500@phlo.org обсуждение исходный текст |
Ответ на | Re: 2PC-induced lockup (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > "Simon Riggs" <simon@2ndquadrant.com> writes: >> I'd be much more comfortable if LOCK TABLE caused a message to the log >> if it is executed on any system table. > > Enabled by "set training_wheels = on", perhaps? > > This is really pretty silly to be getting worked up about. The command > in question wouldn't have been allowed at all except to a superuser, > and there are plenty of ways to catastrophically destroy your database > when you are superuser; most of which we will never consider blocking > for the same reasons that Unix systems have never tried to block root > from doing "rm -rf /". I'd say the real design flaw in Peter's > referenced application is that they're running it as superuser. Yeah.. though "lock pg_auth; prepare" looks quite innocent, much more than say "delete from pg_database" or "rm -rf whatever". At least to the untrained eye. I fully agree that that special-casing this particular way to shoot yourself in the foot is not worth it - but maybe pursuing a more general solution would be worthwile? Maybe superuser-connections could e.g. ignore any errors that occur while reading a system table, together with a big, fat warning, but still allow a logon? That of course depends on the assumption that basic authentication is possible using just the information from the flatfiles and pg_hba.conf, which I'm not sure about. greetings, Florian Pflug
В списке pgsql-hackers по дате отправления: