| From: | Ants Aasma <ants(dot)aasma(at)eesti(dot)ee> |
|---|---|
| To: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
| Cc: | pgsql-performance(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> |
| Subject: | Re: problems with set_config, work_mem, maintenance_work_mem, and sorting |
| Date: | 2012-02-29 07:30:21 |
| Message-ID: | CA+CSw_u3Qxo0wqufHN=+nhe0ZU2mhyiO-SBgLcO+na7V+VfD=Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Feb 29, 2012 1:44 AM, "Claudio Freire" <klaussfreire(at)gmail(dot)com> wrote:
> Another option, depending on your SQLA version, when connections are
> sent back to the pool, I seem to remember they were reset. That would
> also reset the work_mem, you'd still see the same pid on PG logs, but
> it's not the same session.
Except that any open transactions are rolled back no other reset is done.
The correct way to handle this would be to set the options and commit the
transaction in Pool connect or checkout events. The event choice depends on
whether application scope or request scope parameters are wanted.
--
Ants Aasma
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Anssi Kääriäinen | 2012-02-29 10:20:15 | Large insert and delete batches |
| Previous Message | Gavin Flower | 2012-02-29 05:31:29 | Re: Very long deletion time on a 200 GB database |