Oleg Bartunov wrote:
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=#
On Sun, Sep 09, 2007 at 12:02:28AM -0400, Andrew Dunstan wrote:
. what do we need to do to make the verification code more efficient? I
think we need to address the correctness issue first, but doing so
should certainly make us want to improve the verification code. For
example, I'm
Martijn van Oosterhout wrote:
On Sun, Sep 09, 2007 at 12:02:28AM -0400, Andrew Dunstan wrote:
. what do we need to do to make the verification code more efficient? I
think we need to address the correctness issue first, but doing so
should certainly make us want to improve the
Andrew Dunstan [EMAIL PROTECTED] writes:
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()
Oleg Bartunov [EMAIL PROTECTED] writes:
Oh, my god, I see we dictate extensions !
Folk, this is too much ! Now, we dictate extensions '.dict, .affix, .stop',
what else ?
Does it defined by ispell template only, or it's global requirements ?
It's the callers of get_tsearch_config_filename()
I brought back clownfish(still a bit dubious about the unexplained
failures which seem vmware emulation bugs but this one seems to be
easily reproduceable) onto the buildfarm and enabled --with-openssl
after the the recent openssl/pgcrypto related fixes but I'm still
getting a backend crash during
Heikki Linnakangas [EMAIL PROTECTED] writes:
Oleg Bartunov wrote:
seems something is broken in ispell dictionary (CVS HEAD).
Works for me, with the affix file from iamerican debian package, and a
dictionary containing just star/S. Which ispell files are you using?
Is anyone working on
On 9/8/07, Sibte Abbas [EMAIL PROTECTED] wrote:
Hi all,
Realizing that the mentioned TODO item discussed at
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php can be
useful for myself and others as well, I
On 9/9/07, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote:
I brought back clownfish(still a bit dubious about the unexplained
failures which seem vmware emulation bugs but this one seems to be
easily reproduceable) onto the buildfarm and enabled --with-openssl
after the the recent
[ see thread at
http://archives.postgresql.org/pgsql-bugs/2007-06/msg00166.php ]
Stephen Frost [EMAIL PROTECTED] writes:
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
Tom Lane wrote:
So actually, ON_ERROR_ROLLBACK breaks *any* use of SET LOCAL, not just
ROLE. Not sure that this is fixable :-(
Tom Lane wrote:
A possible answer is to add a verifymbstr to the string literal
converter anytime it has processed a numeric backslash-escape in the
string. Open questions for that are (1) does it have negative effects
for bytea, and if so is there any hope of working around it? (2) how
can
When I was playing with pgbench testing yesterday, one thing that seemed
a bit odd was that turning off synchronous_commit didn't change the
results noticeably. It took till today for the reason to penetrate
my cranium: it was off already.
Hmm,
After renewing session I've got working ispell dictionary. I don't
remember exactly if such behaviour is what we wanted.
Oleg
On Sun, 9 Sep 2007, Heikki Linnakangas wrote:
Oleg Bartunov wrote:
seems something is broken in ispell dictionary (CVS HEAD).
event=# CREATE TEXT SEARCH
Marko Kreen [EMAIL PROTECTED] writes:
On 9/9/07, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote:
I brought back clownfish(still a bit dubious about the unexplained
failures which seem vmware emulation bugs but this one seems to be
easily reproduceable) onto the buildfarm and enabled
Tom Lane wrote:
Marko Kreen [EMAIL PROTECTED] writes:
On 9/9/07, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote:
I brought back clownfish(still a bit dubious about the unexplained
failures which seem vmware emulation bugs but this one seems to be
easily reproduceable) onto the buildfarm and
Tom Lane wrote:
We've had that hack in there for almost a month now, and no strange
behaviors have turned up in the buildfarm. So I'm inclined to think
it has served its purpose, and we should revert it before anyone else
comes to bogus conclusions about performance. This is particularly
the
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Is that going to cover data coming in via COPY? and parameters for
prepared statements?
Those should be checked already --- if not, the right fix is still to
fix it there, not in per-datatype code. I think we are OK though,
On Sun, 2007-09-09 at 10:51 -0400, Tom Lane wrote:
A possible answer is to add a verifymbstr to the string literal
converter anytime it has processed a numeric backslash-escape in the
string. Open questions for that are (1) does it have negative effects
for bytea, and if so is there any hope
Tom Lane [EMAIL PROTECTED] writes:
We've had that hack in there for almost a month now, and no strange
behaviors have turned up in the buildfarm. So I'm inclined to think
it has served its purpose, and we should revert it before anyone else
comes to bogus conclusions about performance. This
Andrew Dunstan [EMAIL PROTECTED] writes:
Well, a little experimentation shows that we currently are not OK:
This experiment is inadequately described.
What is the type of the column involved?
regards, tom lane
---(end of
Jeff Davis [EMAIL PROTECTED] writes:
Currently, you can pass a bytea literal as either: E'\377\377\377' or
E'\\377\\377\\377'.
The first strategy (single backslash) is not correct, because if you do
E'\377\000\377', the embedded null character counts as the end of the
cstring, even though
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
We've had that hack in there for almost a month now, and no strange
behaviors have turned up in the buildfarm. So I'm inclined to think
it has served its purpose, and we should revert it before anyone else
comes to
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
We've had that hack in there for almost a month now, and no strange
behaviors have turned up in the buildfarm. So I'm inclined to think
it has served its purpose, and we should revert it before anyone else
comes to bogus
On Sun, 2007-09-09 at 17:09 -0400, Tom Lane wrote:
Jeff Davis [EMAIL PROTECTED] writes:
Currently, you can pass a bytea literal as either: E'\377\377\377' or
E'\\377\\377\\377'.
The first strategy (single backslash) is not correct, because if you do
E'\377\000\377', the embedded null
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Well, a little experimentation shows that we currently are not OK:
This experiment is inadequately described.
What is the type of the column involved?
Sorry. It's text.
cheers
andrew
Hi
I've already posted this idea, but I feel that I did explain it
rather badly. So here comes a new try.
Currently, we do not assume that either the childXids array, nor
the xid cache in the proc array are sorted by ascending xid order.
I believe that we could simplify the code, further reduce
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
The GucContext of log_autovacuum is PGC_BACKEND in the CVS HEAD,
but should it be PGC_SIGHUP?
Indeed, and it was already documented as though it was SIGHUP, so this
is obviously just a typo. Patch applied, thanks.
regards, tom
Alvaro Herrera [EMAIL PROTECTED] writes:
Maybe we should lower the autovac naptime too, just to make it do some
more stuff (and to see if it breaks something else just because of being
running).
Well, Andrew has committed the pg_regress extension to allow buildfarm
animals to set nondefault
On Sun, Sep 02, 2007 at 10:41:22PM -0400, Tom Lane wrote:
Kenneth Marshall [EMAIL PROTECTED] writes:
... This is the rough plan. Does anyone see anything critical that
is missing at this point?
Sounds pretty good. Let me brain-dump one item on you: one thing that
hash currently has over
Jeff Davis [EMAIL PROTECTED] writes:
Would stringTypeDatum() in parse_type.c be a good place to put the
pg_verifymbstr()?
Probably not, in its current form, since it hasn't got any idea where
the char *string came from; moreover it is not in any better position
than the typinput function to
Tom Lane wrote:
In the short run it might be best to do it in scan.l after all.
I have not come up with a way of doing that and handling the bytea case.
If you have I'm all ears. And then I am still worried about COPY.
cheers
andrew
---(end of
On Sun, 2007-09-09 at 23:22 -0400, Tom Lane wrote:
In the short run it might be best to do it in scan.l after all. A few
minutes' thought about what it'd take to delay the decisions till later
yields a depressingly large number of changes; and we do not have time
to be developing
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
In the short run it might be best to do it in scan.l after all.
I have not come up with a way of doing that and handling the bytea case.
AFAICS we have no realistic choice other than to reject \0 in SQL
literals; to do otherwise
On Sun, 2007-09-09 at 23:33 -0400, Andrew Dunstan wrote:
Tom Lane wrote:
In the short run it might be best to do it in scan.l after all.
I have not come up with a way of doing that and handling the bytea case.
If you have I'm all ears. And then I am still worried about COPY.
If
Jeff Davis [EMAIL PROTECTED] writes:
If it's done in the scanner it should still accept things like:
E'\\377\\000\\377'::bytea
right?
Right, that will work, because the transformed literal is '\377\000\377'
(no strange characters there, just what it says) and that has not got
any encoding
35 matches
Mail list logo
