BTW, before I forget, this little project turned up a couple of
small improvements for the current buildfarm infrastructure:
1. There are half a dozen entries with obviously bogus timestamps:
bfarm=# select sysname,snapshot,branch from mfailures where snapshot <
'2004-01-01';
sysname |
Jeremy Drake <[EMAIL PROTECTED]> writes:
> These on mongoose are most likely a result of flaky hardware.
Yeah, I saw a pretty fair number of irreproducible issues that are
probably hardware flake-outs. Of course you can't tell which are those
and which are low-probability software bugs for many m
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> Some of these might possibly be interesting to other people ...
> If you provide the various greps, etc... I will put it into the website
> proper...
Unfortunately I didn't keep notes on exactly what I searched for in each
case. Some of them were
On Sun, 18 Mar 2007, Tom Lane wrote:
> another icc crash|
> 2007-02-03 10:50:01 | 1
> icc "internal error" |
> 2007-03-16 16:30:01 |29
These on mongoose are most likely a result of flak
Jeff Davis <[EMAIL PROTECTED]> wrote:
> Some people think it's a bug, some people don't. It is technically
> documented behavior, but I don't think the documentation is clear
> enough. I think it is a bug that should be fixed, and here's another
> message in the thread that expresses my opinion:
| 2007-01-31 17:30:01 |16
use of // comment|
2007-02-16 09:23:02 | 1
xml code teething problems |
2007-02-16 16:01:05 |79
(54 rows)
Some of these might
Neil Conway <[EMAIL PROTECTED]> writes:
> Returning control to the backend for every row returned would likely be
> excessive, but you could return once every k rows and get most of the
> benefits of both approaches (k might be on the order of 1000).
However, this still leaves us with no idea ho
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Ok, good point. Now, which of those need to have a check for valid encoding?
The vast majority will barf on any non-ASCII character anyway ... only
the ones that don't will need a check.
regards, tom lane
--
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> The usual trick recommended in the doc is to use lower() and LIKE but
> it leads to bad row estimates (it's constant whatever the search
> pattern is)
Not if you have an index on lower(col) which one supposes you'd have
anyway for such an application.
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> OK, for anyone that wants to play, I have created an extract that
> contains a summary of every non-CVS-related failure we've had. It's a
> single table looking like this:
I did some analysis on this data. Attached is a text dump of a table
declared
Gregory Stark wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
Below is a list of the input routines in the adt directory, courtesy of grep.
Grep isn't a good way to get these, your list missed a bunch.
postgres=# select distinct prosrc from pg_proc where oid in (select typinput
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Below is a list of the input routines in the adt directory, courtesy of grep.
Grep isn't a good way to get these, your list missed a bunch.
postgres=# select distinct prosrc from pg_proc where oid in (select typinput
from pg_type);
prosrc
Returning k rows would be a reasonable solution but which functions need to
be modified to achieve this.
- Original Message -
From: "Neil Conway" <[EMAIL PROTECTED]>
To: "Andrew Dunstan" <[EMAIL PROTECTED]>
Cc: "Martijn van Oosterhout" ; "Islam Hegazy"
<[EMAIL PROTECTED]>;
Sent: Su
Andrew Dunstan wrote:
I'm not convinced it would be a huge gain anyway. Switching madly in
and out of the perl interpreter at least is a known performance
problem, IIRC
Returning control to the backend for every row returned would likely be
excessive, but you could return once every k rows an
Martijn van Oosterhout wrote:
What you want is that when you call a perl tablefunction that as soon
as the perl function returns a row to return that to the caller. That
means the perl interpreter has to be able to save all its state,
return to the caller and when next called resume where it le
I wrote:
The escape processing is actually done in the lexer in the case of
literals. We have to allow for bytea literals there too, regardless of
encoding. The lexer naturally has no notion of the intended
destination of the literal, So we need to defer the validity check to
the *in func
On Sun, Mar 18, 2007 at 01:54:55PM -0600, Islam Hegazy wrote:
> I am trying to modify the execution of the table function to work in
> iterator fashion instead of materializing the output. I have been
> digging the Postgresql code source for about a month now and I can
> figure out where the execut
Hi there
I am trying to modify the execution of the table function to work in iterator
fashion instead of materializing the output. I have been digging the Postgresql
code source for about a month now and I can figure out where the execution of
the table function works. I will be very grateful
On 3/18/07, Martijn van Oosterhout wrote:
Er, it's link between LIKE and the ~=~ that's hard coded
Yes.
So I think it's easier that you think: just build the operator class
and make sure you use the right operator so the planner uses it. ILIKE
already maps to an operator...
Yeah I know. Th
On Sun, Mar 18, 2007 at 07:30:35PM +0100, Guillaume Smet wrote:
> I have planned to write the operator class as a "contrib" module but I
> couldn't find the link between LIKE operator and text_pattern_ops
> opclass which uses ~=~ and all its variants. Andrew from Supernews
> told me it was hardcode
On 3/17/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> On 3/5/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> In the second place, it's a serious violation of what little modularity
>> and layering we have for fd.c to be calling into commands/tablespace.c.
>> Th
Hi all,
I'm currently facing a common problem with queries using ILIKE: it
can't use an index except if the pattern begins with non alpha
characters.
The usual trick recommended in the doc is to use lower() and LIKE but
it leads to bad row estimates (it's constant whatever the search
pattern is)
>> It's intended to parse as much as possible out of the existing files.
>> Unfortunately, the makefiles aren't consistent enough to make this
>> always work, which is why each project in /bin/ for example is added
>> manually. In /contrib/ they're a lot more consistent, so they're
>> auto-parsed.
Magnus Hagander wrote:
Perhaps Magnus could give some precise details about the requirements of
the buildsystem he's constructed.
It's intended to parse as much as possible out of the existing files.
Unfortunately, the makefiles aren't consistent enough to make this
always work, which is
Andrew Dunstan wrote:
>
> The recent ecpg commit seems to have broken MSVC builds:
>
>
> descriptor.obj : error LNK2019: unresolved external symbol _pg_snprintf
> referenced in function _ECPGget_desc
> error.obj : error LNK2001: unresolved external symbol _pg_snprintf
> misc.obj : error LNK2001:
The recent ecpg commit seems to have broken MSVC builds:
descriptor.obj : error LNK2019: unresolved external symbol _pg_snprintf
referenced in function _ECPGget_desc
error.obj : error LNK2001: unresolved external symbol _pg_snprintf
misc.obj : error LNK2001: unresolved external symbol _pg_snp
"Aleksis Petrov" <[EMAIL PROTECTED]> writes:
> The other solution could be to not update the indexes at all (just REINDEX
> it). But this does'nt seem to fit in with the current implementation of
> repair_frag() function.
Considerably more to the point: what happens if VACUUM fails partway
through
On 3/6/07, Mike Rylander <[EMAIL PROTECTED]> wrote:
On 3/6/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> Mike Rylander wrote:
> > The patch adds support for default XML namespaces in xml2 by providing
> > a mechanism for supplying a prefix to a named namespace URI.
>
> How does it support mul
On Sun, Mar 18, 2007 at 08:25:56AM -0400, Andrew Dunstan wrote:
> It does also seem from my test results that transcoding to MB charsets
> (or at least to utf-8) is surprisingly expensive, and that this would be
> a good place to look at optimisation possibilities. The validity tests
> can also
Dear PostgreSQL community
Concept for a PostGIS application to Missing People:
This is a proposal for design a new concept for integrated PostGIS application
and how to implement features to improve tracking information about missing
people. This application will be useful in disaster scenario
On 3/17/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
In principle I am in favor of the patch.
Would it be better to use some more unlikely name for the dummy root
element used to process fragments than ?
Perhaps even something in a special namespace?
I did think about it, but I didn't find
Hi everyone,
Regarding the mentioned TODO item, the past discussion as I see from the
following thread:
http://archives.postgresql.org/pgsql-general/2007-01/msg00879.php
concludes that during vacuum full, the relations' indexes should be
recreated via REINDEX, rather than updating them.
One s
Sorry, here's the first post, just now included hackers (more info in
previous post)...
The following error occurred when issuing a vanilla initdb command on
my Windows system.
FATAL: could not select a suitable default timezone
DETAIL: It appears that your GMT time zone uses leap seconds.
Post
A little more info that might help: I had to put a hack into two .h
files (libpq.h, libpq-int.h) and add
typedef int ssize_t
to get things to compile. I did notice that libpq-int.h had this
typedef inside an #ifdef WIN32_ONLY_COMPILER which apparently wasn't
triggered.
Have now also tried:
downloading 8.2.2 and compiling it - no luck when running initdb (same
error)
rerunning configure with and without --with-includes=/mingw/include --
with-libraries=/mingw/lib (always running --without-zlib) - same error
I have been searching newsgroups, archives, etc. in hop
On 3/5/07, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote:
On 3/4/07, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote:
> I'll fix these issues and extend the patch with resgression tests and
> docs for xpath_array(). I'll resubmit it very soon.
Here is a new version of the patch. I didn't change an
Martijn van Oosterhout wrote:
On Sat, Mar 17, 2007 at 11:46:01AM -0400, Andrew Dunstan wrote:
How can we fix this? Frankly, the statement in the docs warning about
making sure that escaped sequences are valid in the server encoding is a
cop-out. We don't accept invalid data elsewhere, and th
Andrew,
Lastly, note that some buildfarm enhancements are on the SOC project
list. I have no idea if anyone will express any interest in that, of
course. It's not very glamorous work.
On the other hand, I think there are a lot more student perl hackers and
web people than there are folks wit
Mickael,
I am a student and I would like to have your opinion on a project I
plan to submit for GSoC. At school, when I work with relational
databases I have problems to test tables' structure and queries
because I need to insert test data manually, which is very unpleasant.
Therefore, I suggest
On Sat, Mar 17, 2007 at 11:46:01AM -0400, Andrew Dunstan wrote:
> How can we fix this? Frankly, the statement in the docs warning about
> making sure that escaped sequences are valid in the server encoding is a
> cop-out. We don't accept invalid data elsewhere, and this should be no
> different
Maybe we should add as resurce intensive check to ascii encoding(s),
that would even the score ;p
let's test mysql on this, and see how worse does it perform.
--
Grzegorz 'the evil' Jaskiewicz
evil C/evil C++ developer for hire
---(end of broadcast)-
41 matches
Mail list logo
