On 04/09/2013 09:06 AM, Alvaro Herrera wrote:
Fabio Rueda Carrascosa escribió:
My grant/revoke architecture is fine, you mean about costly cpu/ram queries?
Sure. The SQL dialect supported by Postgres is Turing-complete, so
people can write statements that consume arbitrary amounts of RAM an
On Tue, Apr 9, 2013 at 11:13 AM, Merlin Moncure wrote:
> On Tue, Apr 9, 2013 at 10:57 AM, Fabio Rueda Carrascosa
> wrote:
>> My grant/revoke architecture is fine, you mean about costly cpu/ram queries?
>
> it has nothing to do with grant/revoke. There are multiple trivial
> things a user can do
On Tue, Apr 9, 2013 at 10:57 AM, Fabio Rueda Carrascosa
wrote:
> My grant/revoke architecture is fine, you mean about costly cpu/ram queries?
it has nothing to do with grant/revoke. There are multiple trivial
things a user can do to DOS you server. You can prevent a lot of
them, but it's defin
Fabio Rueda Carrascosa escribió:
> My grant/revoke architecture is fine, you mean about costly cpu/ram queries?
Sure. The SQL dialect supported by Postgres is Turing-complete, so
people can write statements that consume arbitrary amounts of RAM and
diskspace, and run for arbitrary amounts of time
My grant/revoke architecture is fine, you mean about costly cpu/ram queries?
2013/4/9 Tom Lane
> Fabio Rueda Carrascosa writes:
> > Im planning to publish my postgresql server to a few untrusted clients.
> > I dont want them to modify any runtime setting, like work_mem or
> something
> > risky
Fabio Rueda Carrascosa writes:
> Im planning to publish my postgresql server to a few untrusted clients.
> I dont want them to modify any runtime setting, like work_mem or something
> risky to my server. In general I assume the pg_catalog schema is public but
> I don't want to allow updating pg_se
