Please see comment at the end of this post...
On 19/07/16 00:55, Christopher BROWN wrote:
> Hello,
>
> What would the scope and capacity of the cache be? For example,
> scoped to the lifetime of a (pooled) Connection, to that of Statement,
> or something else, and how could the cache capacity be controlled
> (avoiding excessive garbage collection pressure, etc.) and
> instrumented (cache hits/misses, cache filling and emptying rates,
> etc.)? Would it be possible for the application to issue a command to
> clear the cache immediately if the application is aware of structural
> changes (this can happen a lot in development might lead to unexpected
> behavior)?
>
> --
> Christopher
>
>
> On 18 July 2016 at 14:38, Dave Cramer <pg@fastcrypt.com
> <mailto:pg@fastcrypt.com>> wrote:
>
>
>
>
>
> On 18 July 2016 at 07:48, Vladimir Sitnikov
> <sitnikov.vladimir@gmail.com <mailto:sitnikov.vladimir@gmail.com>>
> wrote:
>
> Dave>Well all drivers have to do something similar. Not all
> result sets are updatable. What do other drivers do ?
>
> Technically speaking, pgjdbc could cache the names of primary
> keys for a given table.
> It would be useful at least in two places:
> 1) updateable resultset
> 2) return generated keys
>
> However, as of now no such cache exists in pgjdbc.
> The second issue is the backend does not send notifications on
> DDL changes. Thus the cache can easily get out of sync when
> java thinks there's a column named A, and in reality the
> column was dropped long ago.
>
> This error would happen far fewer times than the cache would help
> the problem. I think if we can figure out how to gracefully
> recover from the error we would be far further ahead.
>
> Dave Cramer
>
> davec@postgresintl.com <mailto:davec@postgresintl.com>
> www.postgresintl.com <http://www.postgresintl.com/>
>
In this list, the convention is to post replies at the end (with some
rare exceptions), or interspersed when appropriate, and to omit parts no
longer relevant.
The motivation of bottom posting like this: is that people get to see
the context before the reply, AND emails don't end up getting longer &
longer as people reply at the beginning forgetting to trim the now
irrelevant stuff at the end.
Cheers,
Gavin
