Re: [HACKERS] invalidly encoded strings

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 encodi

Re: [HACKERS] invalidly encoded strings

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.

Re: [HACKERS] invalidly encoded strings

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

Re: [HACKERS] invalidly encoded strings

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 mostly-co

Re: [HACKERS] invalidly encoded strings

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 broadcast)--

Re: [HACKERS] invalidly encoded strings

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

Re: [HACKERS] Hash index todo list item

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

Re: [HACKERS] Are we done with sync-commit-defaults-to-off patch?

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 nondefaul

Re: [HACKERS] GucContext of log_autovacuum

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,

[HACKERS] Maybe some more low-hanging fruit in the latestCompletedXid patch.

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

Re: [HACKERS] invalidly encoded strings

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

Re: [HACKERS] invalidly encoded strings

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 embed

Re: [HACKERS] Are we done with sync-commit-defaults-to-off patch?

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 bo

Re: [HACKERS] Are we done with sync-commit-defaults-to-off patch?

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

Re: [HACKERS] invalidly encoded strings

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 tho

Re: [HACKERS] invalidly encoded strings

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 broadcast)-

Re: [HACKERS] Are we done with sync-commit-defaults-to-off patch?

"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

Re: [HACKERS] invalidly encoded strings

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 ho

Re: [HACKERS] invalidly encoded strings

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,

Re: [HACKERS] Are we done with sync-commit-defaults-to-off patch?

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

Re: [HACKERS] pgcrypto related backend crash on solaris 10/x86_64

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

Re: [HACKERS] pgcrypto related backend crash on solaris 10/x86_64

"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

Re: [HACKERS] ispell dictionary broken in CVS HEAD ?

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 DICTIO

[HACKERS] Are we done with sync-commit-defaults-to-off patch?

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. http://archives.postgresql.org/pgsql-hackers/2007-08/msg00

Re: [HACKERS] invalidly encoded strings

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, eg see "need_transcoding"

Re: [HACKERS] invalidly encoded strings

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

Re: [HACKERS] [BUGS] 'SET LOCAL ROLE blah;' doesn't work?

[ 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 fi

Re: [HACKERS] pgcrypto related backend crash on solaris 10/x86_64

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 openssl/p

Re: [HACKERS] TODO item: add \# which lists line numbers, and allows command execution

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 > can be > useful for myself and others as

Re: [HACKERS] ispell dictionary broken in CVS HEAD ?

"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 worki

[HACKERS] pgcrypto related backend crash on solaris 10/x86_64

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

Re: [HACKERS] tsearch filenames unlikes special symbols and numbers

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_filenam

Re: [HACKERS] invalidly encoded strings

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()

Re: [HACKERS] invalidly encoded strings

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 verification

Re: [HACKERS] invalidly encoded strings

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 wond

Re: [HACKERS] ispell dictionary broken in CVS HEAD ?

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 > even