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
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 replication
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
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 about
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
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
On Fri, Nov 16, 2012 at 11:09 AM, Sébastien Lardière
slardi...@hi-media.com 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
--
On 2012-11-05, Moshe Jacobson mo...@neadwerx.com 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
On Nov 17, 2012, at 20:11, Jasen Betts ja...@xnet.co.nz wrote:
On 2012-11-05, Moshe Jacobson mo...@neadwerx.com 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
On 11/17/12 5:37 PM, David Johnston wrote:
On Nov 17, 2012, at 20:11, Jasen Bettsja...@xnet.co.nz wrote:
On 2012-11-05, Moshe Jacobsonmo...@neadwerx.com wrote:
But more importantly, what's the practical difference between varchar with
no limit and text?
text is immeasurably faster.
If it
On Nov 17, 2012, at 20:43, John R Pierce pie...@hogranch.com wrote:
On 11/17/12 5:37 PM, David Johnston wrote:
On Nov 17, 2012, at 20:11, Jasen Bettsja...@xnet.co.nz wrote:
On 2012-11-05, Moshe Jacobsonmo...@neadwerx.com wrote:
But more importantly, what's the practical difference between
On 2012-11-06, Albe Laurenz laurenz.a...@wien.gv.at 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
On 2012-11-06, Kevin Grittner kgri...@mail.com 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
On 2012-11-06, Kevin Grittner kgri...@mail.com 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
-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 supports
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 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_identifier_for_a_prepared_statement_name_ok
will be truncated to
On 18/11/12 17:10, Phil Sorber wrote:
On Nov 17, 2012 11:06 PM, Gavin Flower
gavinflo...@archidevsys.co.nz mailto:gavinflo...@archidevsys.co.nz
wrote:
On 18/11/12 16:49, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
NOTICE: identifier
Greg Sabino Mullane g...@turnstep.com 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
David Johnston pol...@yahoo.com writes:
On Nov 17, 2012, at 20:43, John R Pierce pie...@hogranch.com 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
On Sun, Nov 18, 2012 at 1:29 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David Johnston pol...@yahoo.com writes:
On Nov 17, 2012, at 20:43, John R Pierce pie...@hogranch.com wrote:
I think he meant a tiny tiny bit faster, primarily due to not having to
validate the length.
Maybe... But I would
22 matches
Mail list logo
