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 ch
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 b
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 thi
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 carefull
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 thi
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 th
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 re
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
"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 wit
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
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 b
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
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 al
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 got
19 matches
Mail list logo
