On Sat, 7 Jan 2006, Greg Stark wrote:
Qingqing Zhou [EMAIL PROTECTED] writes:
For b1, it actually doesn't matter much though. With bitmap we definitely
can give a better EXPLAIN numbers for seqscan only, but without the bitmap,
we seldom make wrong choice of choosing/not choosing
The TODO list contains some items concerning the CIDR/INET datatype.
* %Prevent INET cast to CIDR if the unmasked bits are not zero, or
zero the bits
I added a function for this cast (which zeroes the bits) but then the
opr_sanity regression test failed because there is a cast from INET - CIDR
Qingqing Zhou [EMAIL PROTECTED] writes:
In other words, the difference between being in Postgres's buffer cache and
being in the filesystem cache, while not insignificant, isn't really
relevant
to the planner since it affects sequential scans and index scans equally.
The bitmap was
On Fri, 6 Jan 2006, Tom Lane wrote:
OK, this must be a different issue then. I think we have seen reports
like this one before, but not been able to reproduce it.
Could you rebuild with Asserts enabled and see if any asserts trigger?
I got an assert to fail. I'm not entirely sure if this
Joachim Wieland [EMAIL PROTECTED] writes:
Actually both types are not binary compatible, since they have a
type component that is either 0 or 1, depending on whether it is of type
INET or CIDR.
The whole question of the relationship of those types really needs to be
looked at more carefully.
Jeremy Drake [EMAIL PROTECTED] writes:
I got an assert to fail. I'm not entirely sure if this is helpful, but I
managed to get a core dump with --enable-debug and --enable-cassert (with
optimizations still on). Let me know if there is anything else that would
be useful to get out of this
On Sat, 7 Jan 2006, Tom Lane wrote:
Fascinating --- that's not anywhere near where I thought your problem
was. Which cache is this tuple in? (Print *ct-my_cache)
$2 = {
id = 3,
cc_next = 0x2aac1048,
cc_relname = 0x2ab19df8 pg_amop,
cc_reloid = 2602,
cc_indexoid = 2654,
Jeremy Drake [EMAIL PROTECTED] writes:
Am I correct in interpreting this as the hash opclass for Oid?
No, it's the AMOPOPID catalog cache (containing rows from pg_amop
indexed by amopopr/amopclaid).
After digging around for a bit I noticed that catalog caches get
flushed if someone vacuums the
On Sat, Jan 07, 2006 at 12:50:23PM -0500, Tom Lane wrote:
Joachim Wieland [EMAIL PROTECTED] writes:
Actually both types are not binary compatible, since they have a
type component that is either 0 or 1, depending on whether it is of type
INET or CIDR.
The whole question of the
On Sat, 7 Jan 2006, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
Am I correct in interpreting this as the hash opclass for Oid?
However, AFAICS the only consequence of this bug is to trigger
that Assert failure if you've got Asserts enabled. Dead catcache
entries aren't actually
Greg Stark [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hm. Personally I have a hunch you're right. But there we have no actual
evidence. The first thing that needs to happen is changes to use O_DIRECT
for
everything and then benchmarking one of those big TPC tests with the
Jeremy Drake [EMAIL PROTECTED] writes:
On Sat, 7 Jan 2006, Tom Lane wrote:
I'll go fix CatCacheRemoveCList, but I think this is not the bug
we're looking for.
Incidentally, one of my processes did get that error at the same time.
All of the other processes had an error
DBD::Pg::st execute
Here is a quick-and-dirty function for forcing sinval reset (ie, catalog
cache flush). I've already found one bug in CVS tip with it :-(, and
I have a feeling there may be a lot more.
Basic usage is: compile the program into a .so file, then in a spare
database do something like
create function
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
This is a theory. The whole database was loaded using pg_restore, I still
have the original dump so I will have a look at the dump now. The database
actually contains some plperl functions.
OK, I think I have reproduced the
Andrew Dunstan [EMAIL PROTECTED] writes:
However, to the best of my knowledge, Windows does NOT consult the
environment when set_locale is called. ISTM we probably need to call
set_locale ourselves on Windows with the desired values.
We already do, during process startup. The question
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
However, to the best of my knowledge, Windows does NOT consult the environment
when set_locale is called. ISTM we probably need to call set_locale ourselves
on Windows with the desired values.
We already do, during process
On Sat, 7 Jan 2006, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
On Sat, 7 Jan 2006, Tom Lane wrote:
I'll go fix CatCacheRemoveCList, but I think this is not the bug
we're looking for.
A bit of a leap in the dark, but: maybe the triggering event for this
situation is not a
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
However, to the best of my knowledge, Windows does NOT consult the
environment when set_locale is called. ISTM we probably need to call
set_locale ourselves on Windows with the desired values.
We
All,
I was thinking of handling the TODO for ISO8601 Interval output.
Is http://archives.postgresql.org/pgsql-patches/2003-09/msg00121.php
still
the consensus? I.E. rip out the current pseudo-iso code, and replace it
with
genuine ISO8601 code?
I tried(!) to e-mail Ron Mayer, but
19 matches
Mail list logo
