On 01/05/2016 03:21 PM, oleg yusim wrote:
Thanks JD. From what I read about WAL (you have been referring to this: http://www.postgresql.org/docs/current/static/wal-internals.html pg_xlog, right?) it allows us to know what happened, but does it warranty known secure state? I mean, I do not think it would help with this: "In general, security mechanisms should be designed so that a failure will follow the same execution path as disallowing the operation. For example, application security methods, such as isAuthorized(), isAuthenticated(), and validate(), should all return false if there is an exception during processing. If security controls can throw exceptions, they must be very clear about exactly what that condition means. "
Not sure what you are talking about above. the application as in the client application connecting to the database or the database application itself?
Right? Thanks, Oleg On Tue, Jan 5, 2016 at 5:14 PM, Joshua D. Drake <jd@xxxxxxxxxxxxxxxxx <mailto:jd@xxxxxxxxxxxxxxxxx>> wrote: On 01/05/2016 03:09 PM, oleg yusim wrote: The question here, what is PostreSQL 9.4.5 (hosted on Linux box) behavior? Does it fail to known/secure state in these 3 cases? I tried to find the description of the way PostgreSQL fails in this regard, but didn't find much. Based on what you pasted, PostgreSQL does fail to a known state. That is the whole point of the xlog. Sincerely, JD Thanks, Oleg -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564 <tel:503-667-4564> PostgreSQL Centered full stack support, consulting and development. Announcing "I'm offended" is basically telling the world you can't control your own emotions, so everyone else should do it for you.
-- Adrian Klaver adrian.klaver@xxxxxxxxxxx -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
