| From: | Magnus Hagander <magnus(at)hagander(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: "failed to commit client_encoding" explained |
| Date: | 2009-04-02 08:18:25 |
| Message-ID: | 49D474D1.50500@hagander.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> A problem with such caching is that it'd fail to respond to changes in
> the content of pg_conversion. Now the code is already pretty
> insensitive in that respect, because if you're not doing any fresh "SET
> client_encoding" commands it won't ever notice changes in that catalog
> anyway. But this'd make it worse. We could ameliorate the issue
> somewhat by doing fresh lookups (and updating the cache) whenever doing
> SetClientEncoding with IsTransactionState() true, and only relying on
> the cache when IsTransactionState() is false.
>
> Comments?
Certainly seems like a reasonable compromise. From what I understand,
you'll get this "failed to commit..." message *if* you have changedf
things in pg_conversion. I think that's acceptable - it's not like
people modify pg_conversion all the time (at least I hope they don't).
//Magnus
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2009-04-02 08:35:14 | Re: Path separator |
| Previous Message | Dave Page | 2009-04-02 08:03:29 | Re: 8.4 open items list |