Обсуждение: Re: Scheduler in Postgres
Tom Lane wrote: > Christopher Browne <cbbrowne@acm.org> writes: >> Centuries ago, Nostradamus foresaw when decibel@decibel.org ("Jim C. >> Nasby") would write: >>> In PostgreSQL, there's currently no way to assume the identity of >>> another user. > >> I'm confused at that... > >> There seem to be ways at time of connection establishment, whether >> via the psql "-U" option, or the PGconnect "dbuser=foo" option, or >> during a psql session via "\c - newuser". > > Not to mention SET SESSION AUTHORIZATION. Chris, all the options you mention require the entry of a password, or for SET SESSION AUTHORIZATION, that the original connection was made by a superuser (which in turn would have required entry of a password.) It's possible to circumvent this with trust authentication, but the PostgreSQL documentation recommends against general use of trust authentication (and I agree with that recommendation in a production environment.) As described in other messages in this thread, putting a scheduler in the database would allow authentication to be done at the time the job is set up, and then the job to be run without reauthorization. -- Guy Rouillier
"Guy Rouillier" <guyr@masergy.com> writes: >> Not to mention SET SESSION AUTHORIZATION. > Chris, all the options you mention require the entry of a password, or > for SET SESSION AUTHORIZATION, that the original connection was made by > a superuser (which in turn would have required entry of a password.) > It's possible to circumvent this with trust authentication, but the > PostgreSQL documentation recommends against general use of trust > authentication (and I agree with that recommendation in a production > environment.) > As described in other messages in this thread, putting a scheduler in > the database would allow authentication to be done at the time the job > is set up, and then the job to be run without reauthorization. I think this is really a content-free argument. An outside-the-database cron substitute would have to have superuser privileges so that it could do SET SESSION AUTHORIZATION, but so what? If the DBA doesn't want to cooperate in setting up a scheduler, he probably doesn't want his users to use an inside-the-database one either. There aren't really any permissions or security issues here that weren't solved long ago. People have been using cron jobs driving connect-as-superuser scripts to do periodic pg_dump and vacuum maintenance since forever. An outside-the-database scheduler for user tasks is a straightforward increment on that. regards, tom lane