Re: Row Level Security − leakproof-ness and performance implications
От | Joshua Brindle |
---|---|
Тема | Re: Row Level Security − leakproof-ness and performance implications |
Дата | |
Msg-id | CAGB+Vh4B0wbCSP4zzqxuFJsmULAV8fdn3PGtJ0mFApMcX5vaaw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Row Level Security − leakproof-ness and performance implications (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Re: Row Level Security − leakproof-ness and performance implications
|
Список | pgsql-hackers |
On Thu, Feb 28, 2019 at 9:12 AM Robert Haas <robertmhaas@gmail.com> wrote: Hi, Robert, it has been a while :) > > So... you're just going to replace ALL error messages of any kind with > "ERROR: missing error text" when this option is enabled? That sounds > unusable. I mean if I'm reading it right this would get not only > messages from SQL-callable functions but also things like "deadlock > detected" and "could not read block %u in file %s" and "database is > not accepting commands to avoid wraparound data loss in database with > OID %u". You can't even shut it off conveniently, because the way This makes complete sense to me. The client side of a client/server protocol doesn't have any way to fix 'could not read block %u in file %s', the client doesn't need that kind of detailed information about a server, and in fact that information could be security sensitive. Imagine connecting to a webserver with a web browser and getting a similar message. When something critical happens the servers logs can be viewed and the error can be addressed there, on the server.
В списке pgsql-hackers по дате отправления: