Ok thanks for your reply Tom.
We have made on our side some update on this file
src/backend/tsearch/dict_thesaurus.c
Then we recompile PG 9.2.2 with this patch and now the thesaurus works fine
with more than 64k entries and queries runtime is always low as expected.
Here is our update of the fil
Good points to both. Thank you both for reviewing.
Dave
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
On Fri, Jan 11, 2013 at 12:36 PM, Stefan Reiser wrote:
> Kris Jurka schrieb:
>
>
>> On Fri, 11 Jan 2013, Dave Cramer wrote:
>>
>> Ok, I've pushed this fix into master
>
Kris Jurka schrieb:
On Fri, 11 Jan 2013, Dave Cramer wrote:
Ok, I've pushed this fix into master
You've made any failure to parse the affected row count return
SUCCESS_NO_INFO. Shouldn't you change the integer parsing to a long
parsing and only modify the response if the value is > INT_MAX
On Fri, 11 Jan 2013, Dave Cramer wrote:
> Ok, I've pushed this fix into master
>
You've made any failure to parse the affected row count return
SUCCESS_NO_INFO. Shouldn't you change the integer parsing to a long
parsing and only modify the response if the value is > INT_MAX while still
thr
On Fri, 11 Jan 2013, Stefan Reiser wrote:
> What about returning Statement.SUCCESS_NO_INFO as it says in
> http://docs.oracle.com/javase/6/docs/api/java/sql/BatchUpdateException.html#getUpdateCounts%28%29
> and
> http://docs.oracle.com/javase/6/docs/api/java/sql/Statement.html#executeBatch%28%29
Ok, I've pushed this fix into master
On Fri, Jan 11, 2013 at 10:38 AM, Dave Cramer wrote:
> SUCCESS_NO_INFO
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
Yes, that seems like a much better approach. I'm guessing SUCCESS_NO_INFO
is < 0 and an int. I can't wait for the error reports (arguments)
Dave
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
On Fri, Jan 11, 2013 at 10:32 AM, Stefan Reiser wrote:
> One thought:
>
> What ab
One thought:
What about returning Statement.SUCCESS_NO_INFO as it says in
http://docs.oracle.com/javase/6/docs/api/java/sql/BatchUpdateException.html#getUpdateCounts%28%29
and
http://docs.oracle.com/javase/6/docs/api/java/sql/Statement.html#executeBatch%28%29
?
It seems better to report no numb
On 11 January 2013 12:18, Tomonari Katsumata
wrote:
> I'm not sure but what about adding the parameter("cascade_mode") on
> recovery.conf ?
> The parameter represents a will to connect to standby server when starting
> as standby.
> If the parameter is set to on, connect to a server forcely like
Ok, this is much more difficult than I thought.
Turns out that there are at least two interfaces that expect an int not a
long.
BatchUpdateException
executeBatch
I'm thinking the only option here is to report INT_MAX as opposed to
failing.
Thoughts ?
Dave
Dave Cramer
dave.cramer(at)credativ
Hi,
hi, I'm playing with Synchronous Replication on PostgreSQL 9.2.2.
And I saw a strange behavior.
Unless you left out something, the configuration you described
actually sets up asynchronous replication.
Thank you for the comment.
I was thinking to promote one of them and set
synchronou
On 11.01.2013 11:19, Simon Riggs wrote:
On 11 January 2013 08:40, Heikki Linnakangas wrote:
This makes me wonder if there should be a GUC to forbid cascading
replication, though. If you don't want to do cascading replication (which is
quite rare, I'd say), you could just disable it to avoid a
On 11 January 2013 08:40, Heikki Linnakangas wrote:
> This makes me wonder if there should be a GUC to forbid cascading
> replication, though. If you don't want to do cascading replication (which is
> quite rare, I'd say), you could just disable it to avoid a situation like
> this.
Connection fr
On 11.01.2013 06:09, katsumata.tomon...@po.ntts.co.jp wrote:
The following bug has been logged on the website:
Bug reference: 7803
Logged by: Tomonari Katsumata
Email address: katsumata.tomon...@po.ntts.co.jp
PostgreSQL version: 9.2.2
Operating system: RHEL 5.3 x86_64
Descri
14 matches
Mail list logo
