Re: "failed to commit client_encoding" explained - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: "failed to commit client_encoding" explained
Date
Msg-id 49D474D1.50500@hagander.net
Whole thread Raw
In response to "failed to commit client_encoding" explained  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: "failed to commit client_encoding" explained  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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



pgsql-hackers by date:

Previous
From: Dave Page
Date:
Subject: Re: 8.4 open items list
Next
From: Magnus Hagander
Date:
Subject: Re: Path separator