> Well, I found at least part of the problem:
> http://archives.postgresql.org/message-id/20090606023940.bd4b8753...@cvs.postgresql.org
>
> This is in perfectly sequential code. The reason it has
> nondeterministic effects is that (so far as I can tell) the only
> non-crash case where there would
I wrote:
> ... What I think is happening is that there's some inadequately
> locked page-changing logic in there, and if you can get autovacuum to
> happen on msginfo concurrently with the data reload step, it'll mess up.
> Given that we've not seen reports of this on 8.3, I'll bet lunch that
> the
I wrote:
>> I poked around in the dump for awhile. I still can't reproduce the
>> failure from a standing start.
I've had a bit of success with reproducing the failure from scratch.
After loading the SQL dump that Tatsuo previously supplied into a UTF8,
C-locale database, generate a data-only dum
> I poked around in the dump for awhile. I still can't reproduce the
> failure from a standing start. It looks to me like Tatsuo's database
> was possibly produced from separate schema and data load steps, followed
> by some update operations. It would be nice to have a full script for
> reprodu
I wrote:
> Hmm ... I'll rev up my old 32-bit-Intel machine. I suspect that the
> missing link here is some state change in the database above and beyond
> just loading the data, but since we don't know exactly what that is,
> we'll have to resort to working with Tatsuo's bitwise dump.
I poked aro
"Kevin Grittner" writes:
> By the way, that's 32 bit Kubuntu 7.10.
> Linux kgrittn-desktop 2.6.22-16-generic #1 SMP Thu Apr 2 01:27:50 GMT
> 2009 i686 GNU/Linux
> I've done a new build with --enable-debug and confirmed the problem in
> that environment.
Hmm ... I'll rev up my old 32-bit-Intel
I wrote:
> Tatsuo Ishii wrote:
>
>> http://sylpheed.sraoss.jp/tmp/searcherdb84.tar.bz2
>
> Using that on my kubuntu machine with no configure options except
> prefix:
>
> [problem confirmed]
>
> Given that I can replicate this, is there some useful next step?
By the way, that's 32 bit
Tatsuo Ishii wrote:
> http://sylpheed.sraoss.jp/tmp/searcherdb84.tar.bz2
Using that on my kubuntu machine with no configure options except
prefix:
h...@kgrittn-desktop:~$ /usr/local/pgsql-8.4beta2/bin/psql -U hiro
sylph
psql (8.4beta2)
Type "help" for help.
sylph=# SELECT msg_sid, hdr_from
> > I found the cause of this one --- the new code for estimating the
> > selectivity of @@ was not guarding against the possibility that the
> > given TSQuery is empty, as it is in this example.
>
> Shouldn't be this in regression test?
>
> > I'm still unable to reproduce the "tuple offset out o
> I found the cause of this one --- the new code for estimating the
> selectivity of @@ was not guarding against the possibility that the
> given TSQuery is empty, as it is in this example.
Shouldn't be this in regression test?
> I'm still unable to reproduce the "tuple offset out of range" error
Tom Lane wrote:
> Tatsuo Ishii writes:
>>> initdb -E UTF-8 --no-locale /path/to/database
>
>> So locale is "C". I believe we are not customizing
>> default_text_search_config. I'm not think of any nondefault
>> configuration settings.
>
> Huh. So that should be the same case I tested here. I
On Wed, 3 Jun 2009, Tom Lane wrote:
Tatsuo Ishii writes:
initdb -E UTF-8 --no-locale /path/to/database
So locale is "C". I believe we are not customizing
default_text_search_config. I'm not think of any nondefault
configuration settings.
Huh. So that should be the same case I tested here
Tatsuo Ishii writes:
>> initdb -E UTF-8 --no-locale /path/to/database
> So locale is "C". I believe we are not customizing
> default_text_search_config. I'm not think of any nondefault
> configuration settings.
Huh. So that should be the same case I tested here. I wonder why
I can't duplicate
> Hmm. I can confirm the "unrecognized operator" failure (though I get
> "8" not "-50" ... uninitialized memory?). The "tuple out of range"
> failures are not happening here though. Perhaps it is locale dependent?
> What locale are you using, and what is your default_text_search_config
> setting
Tatsuo Ishii writes:
> STATEMENT: SELECT msg_sid, hdr_from, hdr_to, hdr_subject, msg_date,
> folder_id, msgnum FROM msginfo LEFT JOIN msg_folderinfo USING (msg_sid) WHERE
> plainto_tsquery(E'a') @@ body_index
> NOTICE: text-search query contains only stop words or doesn't contain
> lexemes, i
Tatsuo Ishii writes:
> Sorry for delay. I have put a database dump at:
> http://sylpheed.sraoss.jp/tmp/dump.sql.gz
> We got following errors using this database:
Hmm. I can confirm the "unrecognized operator" failure (though I get
"8" not "-50" ... uninitialized memory?). The "tuple out of ran
> > I have encountered strange errors while testing PostgreSQL 8.4 beta2.
>
> > ERROR: tuple offset out of range: 0
> > (occasionally ERROR: tuple offset out of range: 459)
>
> This is evidently coming from tbm_add_tuples, indicating that it's being
> passed bogus TID values from the GIN index.
Tatsuo Ishii writes:
> I have encountered strange errors while testing PostgreSQL 8.4 beta2.
> ERROR: tuple offset out of range: 0
> (occasionally ERROR: tuple offset out of range: 459)
This is evidently coming from tbm_add_tuples, indicating that it's being
passed bogus TID values from the GI
18 matches
Mail list logo
