On Fri, 7 Sep 2007, Heikki Linnakangas wrote:
Pavel Stehule wrote:
postgres=# select ts_debug('cs','PliЪЪ ЪЪluЪЪouЪЪkЪЪ k se napil ЪЪlutЪЪ
vody');
ERROR: character 0xc3a5 of encoding UTF8 has no equivalent in LATIN2
CONTEXT: SQL function ts_debug statement 1
I can reproduce that.
Joshua D. Drake schrieb:
This is not acceptable on our lists. Do not post in such a way again.
Sincerely,
Joshua D. Drake
Hi Josh,
Your're right, but this special Guy has just boring me a lot with
Replication Things but
my [Featurerequest] on the Topic was dedicated to Streaming
As a fallout of this work that I haven't seen made explicit, a session
opening a transaction and then sitting around doing nothing will not
cause as many problems as it used to -- for example it won't cause
VACUUM to be unable to clean up dead rows. Is this correct?
Nowadays this is no longer
Alvaro Herrera [EMAIL PROTECTED] writes:
As a fallout of this work that I haven't seen made explicit, a session
opening a transaction and then sitting around doing nothing will not
cause as many problems as it used to -- for example it won't cause
VACUUM to be unable to clean up dead rows. Is
Tom Lane [EMAIL PROTECTED] writes:
If you issue BEGIN, then SELECT, then sit, you'll be publishing an xmin
but not an xid, so at that point you become a problem for VACUUM.
However, internally you don't have any live snapshots (if you're in READ
COMMITTED mode), so eventually we could have
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
If you issue BEGIN, then SELECT, then sit, you'll be publishing an xmin
but not an xid, so at that point you become a problem for VACUUM.
However, internally you don't have any live snapshots (if you're in READ
Ühel kenal päeval, L, 2007-09-08 kell 10:39, kirjutas apoc9009:
Joshua D. Drake schrieb:
This is not acceptable on our lists. Do not post in such a way again.
Sincerely,
Joshua D. Drake
Hi Josh,
Your're right, but this special Guy has just boring me a lot with
Replication Things
On Fri, 7 Sep 2007, Simon Riggs wrote:
For me, the bgwriter should sleep for at most 10ms at a time.
Here's the results I got when I pushed the time down significantly from
the defaults, with some of the earlier results for comparision:
info | set
Greg Smith [EMAIL PROTECTED] writes:
If anyone has a reason why they feel the bgwriter_delay needs to be a
tunable or why the rate might need to run even faster than 10ms, now would
be a good time to say why.
You'd be hard-wiring the thing to wake up 100 times per second? Doesn't
sound like
On Sat, 8 Sep 2007, Tom Lane wrote:
I've already gotten flak about the current default of 200ms:
https://bugzilla.redhat.com/show_bug.cgi?id=252129
I can't imagine that folk with those types of goals will tolerate an
un-tunable 10ms cycle.
That's the counter-example for why lowering the
C. 'backup _is_ replication' is also true
--
Hannu
It is useless to speak with a person like you about the diffrence between
Backup and Replications.Both Things having diffrent Concepts and
Approaches,
but for you it is all the same.
What should i say? Thadts the typically
Greg Smith [EMAIL PROTECTED] writes:
On Sat, 8 Sep 2007, Tom Lane wrote:
In fact, given the numbers you show here, I'd say you should leave the
default cycle time at 200ms. The 10ms value is eating way more CPU and
producing absolutely no measured benefit relative to 200ms...
My server is
Hi all,
Realizing that the mentioned TODO item discussed at
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.phphttp://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.phpcan
be useful for myself and others as well, I would like to go ahead and
implement it.
Synopsis:
==
Greg Smith [EMAIL PROTECTED] writes:
On Sat, 8 Sep 2007, Tom Lane wrote:
I've already gotten flak about the current default of 200ms:
https://bugzilla.redhat.com/show_bug.cgi?id=252129
I can't imagine that folk with those types of goals will tolerate an
un-tunable 10ms cycle.
That's the
Hannu Krosing [EMAIL PROTECTED] writes:
Is this apoc9009 guy real ?
Please, just don't respond.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
Greg,
Aren't there some things that depend on the idea that even READ COMMITTED
transactions still have a serializable snapshot lying around for them to
use?
No, that would be REPEATABLE READ. That's one of the areas where we need to
test HOT; does RR and SERIALIZABLE still work correctly
On Sat, 8 Sep 2007, Tom Lane wrote:
It might be interesting to consider making the delay auto-tune: if you
wake up and find nothing (much) to do, sleep longer the next time,
conversely shorten the delay when work picks up. Something for 8.4,
though, at this point.
I have a couple of pages of
Ühel kenal päeval, L, 2007-09-08 kell 21:15, kirjutas Apoc Sagdiyev:
C. 'backup _is_ replication' is also true
--
Hannu
It is useless to speak with a person like you
Oh, you think that _I_ am scandinavian ?? Never thought about that
possibility ;P
If speaking with me is
On Fri, Sep 07, 2007 at 10:36:41AM -0400, Brian Hurt wrote:
Kenneth Marshall wrote:
I understand that a hash value is a many-to-one mapping. That is the
point of the flag in the index. The flag means that there is only one
item in the heap corresponding to that hash value. In this case we
I wrote:
This patch implements Florian's idea about how to manage snapshot xmax
without the ugly and performance-losing tactic of taking XidGenLock and
ProcArrayLock at the same time. I had to do a couple of slightly klugy
things to get bootstrap and prepared transactions to work, but on the
On Thu, 6 Sep 2007, Decibel! wrote:
I don't know that there should be a direct correlation, but ISTM that
scan_whole_pool_seconds should take checkpoint intervals into account
somehow.
Any direct correlation is weak at this point. The LRU cleaner has a small
impact on checkpoints, in that
Tom,
So on the strength of that, I'm going to go ahead and commit the patch,
but I'd be interested to see benchmarks from people with access to
better hardware.
Is the latest version of the patch from -patches the one I should test?
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
Hello Tom,
Tom Lane wrote:
So on the strength of that, I'm going to go ahead and commit the patch,
but I'd be interested to see benchmarks from people with access to
better hardware.
I've just completed two dbt2 test runs on a mid-level system, with 4GB
RAM and a 7 disk SATA RAID 1+0 w/ BBU.
Markus,
I've just completed two dbt2 test runs on a mid-level system, with 4GB
RAM and a 7 disk SATA RAID 1+0 w/ BBU. Once with code as of 2007/09/05
18:00 (which is *before* the first lazy xid commit) and once with cvs
HEAD (2007/09/08 +latestCompletedXid.patch.
Hmmm. Your results are
Kenneth Marshall wrote:
Continuing this train of thought While it would make sense for larger
keys to store the hash in the index, if the key is smaller, particularly
if it is of fixed size, it would make sense to store the key in the index
instead. This would have the benefit of allowing
Josh Berkus [EMAIL PROTECTED] writes:
Hmmm. Your results are withing the margin of error for DBT2, so they
show no real difference. What we need for this is a heavy-read
workload, though; on a workload like DBT2 (which is mostly writes) I
wouldn't expect lazy-XID to help much.
Lazy-XID
Josh Berkus [EMAIL PROTECTED] writes:
Is the latest version of the patch from -patches the one I should test?
Yeah, the posted patch is the same as what I committed.
regards, tom lane
---(end of broadcast)---
TIP 5: don't
Tom Lane [EMAIL PROTECTED] writes:
My desktop machine has a single consumer-grade IDE drive, and even with
fsync off and synchronous_commit off, it can barely make 190 tps sustained
pgbench throughput --- it's just disk write bound all the time. On a run
with 8 clients, 1 transactions per
On Sat, Sep 08, 2007 at 05:14:09PM -0400, Mark Mielke wrote:
Kenneth Marshall wrote:
Continuing this train of thought While it would make sense for larger
keys to store the hash in the index, if the key is smaller, particularly
if it is of fixed size, it would make sense to store the key
Josh Berkus [EMAIL PROTECTED] writes:
Hmmm. Your results are withing the margin of error for DBT2, so they show no
real difference. What we need for this is a heavy-read workload, though; on
a workload like DBT2 (which is mostly writes) I wouldn't expect lazy-XID to
help much.
The TPM
No! Actually I'm wearing my tin hat right now and I Never say Anything
about My Suspicions about 9/11 on Internet in fear of Echelon catching
and filing me.
---
Hannu
hmm, a little bit Para?
http://www.myvideo.de/watch/1776449
Ok, now your point of View its more clearly...
Kenneth Marshall wrote:
The value of storing the
actual value, possibly as an option, is that the key check can be done
in the index without requiring a heap lookup to check the actual value
which would be a benefit for a unique index. I agree that supporting
variable length data would
Josh Berkus [EMAIL PROTECTED] writes:
No, that would be REPEATABLE READ. That's one of the areas where we need to
test HOT; does RR and SERIALIZABLE still work correctly with HOT?
I'm a little confused by your question. REPEATABLE READ is an isolation level
we don't directly support in
Greg Smith wrote:
On Sat, 8 Sep 2007, Tom Lane wrote:
It might be interesting to consider making the delay auto-tune: if you
wake up and find nothing (much) to do, sleep longer the next time,
conversely shorten the delay when work picks up. Something for 8.4,
though, at this point.
I have
I have been looking at fixing the issue of accepting strings that are
not valid in the database encoding. It appears from previous discussion
that we need to add a call to pg_verifymbstr() to the relevant input
routines and ensure that the chr() function returns a valid string. That
leaves
On Sun, 2 Sep 2007, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I made it reject all but latin letters, which is the same restriction
that's in place for timezone set filenames. That might be overly
strong, but we definitely have to forbid . and
Hi there,
seems something is broken in ispell dictionary (CVS HEAD).
event=# CREATE TEXT SEARCH DICTIONARY en_ispell (
TEMPLATE = ispell,
DictFile = english,
AffFile = english,
StopWords = english
);
CREATE TEXT SEARCH DICTIONARY
event=# select
On Sun, 9 Sep 2007, Oleg Bartunov wrote:
Oh, my god, I see we dictate extensions !
STATEMENT: CREATE TEXT SEARCH DICTIONARY en_ispell (
TEMPLATE = ispell,
DictFile = englishDict,
AffFile = englishAff,
StopWords = englishStop
38 matches
Mail list logo
