Hello,
We are running 9.2 w/ streaming replication.
The slave is used for heavy tsearch based data mining.
Apparently depending on the business of the master the slave queries fail with
different frequency with the following message —
ERROR: canceling statement due to conflict with recovery
D
On 11/17/2012 06:08 AM, T. E. Lawrence wrote:
> Hello,
>
> We are running 9.2 w/ streaming replication.
>
> The slave is used for heavy tsearch based data mining.
>
> Apparently depending on the business of the master the slave queries fail
> with different frequency with the following message
> Have you looked at the below?:
>
> http://www.postgresql.org/docs/9.2/interactive/hot-standby.html#HOT-STANDBY-CONFLICT
>
> 25.5.2. Handling Query Conflicts
Yes, thank you!
I am hoping to hear more from people who have running 9.2 systems w/ between
100m and 1b records, w/ streaming replicat
I am researching how to set up a schema for querying a set of tags
associated with an object. There are approximately 100 distinct tags
in my application (these will be pre-populated), and I am expecting a
fairly low number of distinct sets of these tags -- in other words, a
given set of tags wil
> I am researching how to set up a schema for querying a set of tags
> associated with an object.
I would be interested in hearing your conclusions.
I am currently researching in a similar direction.
We have streaming replication where the slaves are used for data mining,
storing currently abou
On 11/17/2012 07:33 AM, T. E. Lawrence wrote:
Have you looked at the below?:
http://www.postgresql.org/docs/9.2/interactive/hot-standby.html#HOT-STANDBY-CONFLICT
25.5.2. Handling Query Conflicts
Yes, thank you!
I am hoping to hear more from people who have running 9.2 systems w/ between
100
On Sat, Nov 17, 2012 at 11:01:41AM -0500, Mike Jarmy wrote:
> I am researching how to set up a schema for querying a set of tags
> associated with an object. There are approximately 100 distinct tags
> in my application (these will be pre-populated), and I am expecting a
> fairly low number of dis
On Fri, Nov 16, 2012 at 11:09 AM, Sébastien Lardière
wrote:
> On 11/15/2012 08:40 PM, Cédric Villemain wrote:
>> top post: this looks like a plproxy bug (no ?), I've added Marko in CC.
>
> Yes, it is, i think …
Thanks, fixed in git. Fix will be in 2.5 release.
--
marko
--
Sent via pgsql-gen
On 2012-11-05, Moshe Jacobson wrote:
> --14dae93404f5f865d804cdc59353
> Content-Type: text/plain; charset=ISO-8859-1
>
> Is there any practical difference between defining a column as a
> varchar(n)vs. a varchar
> vs. a text field?
>
> I've always been under the impression that if I am wanting to
On Nov 17, 2012, at 20:11, Jasen Betts wrote:
> On 2012-11-05, Moshe Jacobson wrote:
>
>> But more importantly, what's the practical difference between varchar with
>> no limit and text?
>
> text is immeasurably faster.
>
>>
If it cannot be measured then how can you claim this?
Everything
On 11/17/12 5:37 PM, David Johnston wrote:
On Nov 17, 2012, at 20:11, Jasen Betts wrote:
>On 2012-11-05, Moshe Jacobson wrote:
>>But more importantly, what's the practical difference between varchar with
>>no limit and text?
>text is immeasurably faster.
If it cannot be measured then how ca
On Nov 17, 2012, at 20:43, John R Pierce wrote:
> On 11/17/12 5:37 PM, David Johnston wrote:
>> On Nov 17, 2012, at 20:11, Jasen Betts wrote:
>>> >On 2012-11-05, Moshe Jacobson wrote:
>>But more importantly, what's the practical difference between varchar
>>with
>>no limit and
On 2012-11-06, Albe Laurenz wrote:
> hari.fu...@gmail.com wrote:
>> > I think the problem is that this + operator is implemented
>> > by the function "timestamptz_pl_interval", which is STABLE
>> > but not IMMUTABLE.
>> >
>> > I am not sure why this function cannot be IMMUTABLE, it
>> > seems to m
On 2012-11-06, Kevin Grittner wrote:
>
> For TIMESTAMP WITHOUT TIME ZONE it couldn't be IMMUTABLE, because the
> result would be based on the time zone setting of the client
> connection; but adding a fixed interval to a UTC time to get a UTC
> time seems pretty immutable to me. That said, I'm not
On 2012-11-06, Kevin Grittner wrote:
> hari.fu...@gmail.com
>
>> No: the result of e.g.
>>
>> SELECT TIMESTAMPTZ '2012-10-28 01:30:00' + INTERVAL '24 hours';
>>
>> depends on the client's timezone and its DST rules.
>
> Can you give an example of where adding an interval based on *hours*
> to T
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> NOTICE: identifier
> "this_is_a_really_long_identifier_for_a_prepared_statement_name_ok"
> will be truncated to
> "this_is_a_really_long_identifier_for_a_prepared_statement_name_"
> PREPARE
...
> The ORM could use a shorter identifier, but it
On 18/11/12 16:49, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
NOTICE: identifier
"this_is_a_really_long_identifier_for_a_prepared_statement_name_ok"
will be truncated to
"this_is_a_really_long_identifier_for_a_prepared_statement_name_"
PREPARE
...
The ORM
On Nov 17, 2012 11:06 PM, "Gavin Flower"
wrote:
>
> On 18/11/12 16:49, Greg Sabino Mullane wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: RIPEMD160
>>
>>
>>> NOTICE: identifier
>>> "this_is_a_really_long_identifier_for_a_prepared_statement_name_ok"
>>> will be truncated to
>>> "this_is_
On 18/11/12 17:10, Phil Sorber wrote:
On Nov 17, 2012 11:06 PM, "Gavin Flower"
mailto:gavinflo...@archidevsys.co.nz>>
wrote:
>
> On 18/11/12 16:49, Greg Sabino Mullane wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: RIPEMD160
>>
>>
>>> NOTICE: identifier
>>> "this_is_a_really_long_i
"Greg Sabino Mullane" writes:
>> If it's a postgres bug, what is the fix? Make the identifier max size
>> longer?
> I'd also be in favor of this, in addition to upgrading from a NOTICE.
Increasing NAMEDATALEN has been discussed, and rejected, before. It
is very very far from being a free change
David Johnston writes:
> On Nov 17, 2012, at 20:43, John R Pierce wrote:
>> I think he meant a tiny tiny bit faster, primarily due to not having to
>> validate the length.
> Maybe... But I would presume a "varchar with no limit" does not validate
> length...
There is overhead from the type sy
On Sun, Nov 18, 2012 at 1:29 AM, Tom Lane wrote:
> David Johnston writes:
>> On Nov 17, 2012, at 20:43, John R Pierce wrote:
>>> I think he meant a tiny tiny bit faster, primarily due to not having to
>>> validate the length.
>
>> Maybe... But I would presume a "varchar with no limit" does not
22 matches
Mail list logo
