A small optimisation I implemented today unfortunately misfired and
stopped new results from registering with the buildfarm for a period of
about 10 hours. I have rolled it back so results are starting to flow
again. Apologies to anyone inconvenienced.
cheers
andrew
---
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> This is used for calculating the upper limit of -c option. However
> actual limit is coming from the number of descriptors that select(2)
> can watch (besides the number of file descriptors allowed by the
> kernal. This is different story though, I think).
I found following in pgbench.c:
#define MAXCLIENTS 1024 /* max number of clients allowed */
This is used for calculating the upper limit of -c option. However
actual limit is coming from the number of descriptors that select(2)
can watch (besides the number of file descriptors all
I was a bit unhappy to realize just now that the patch Heikki sent in,
and I reviewed and applied, actually broke dict_synonym. (Modifying a
string tends to modify the result of strlen() ...) While we can't
cover *everything* in the regression tests, it now seems like a bad
idea that the tsearch.
Ron Mayer <[EMAIL PROTECTED]> writes:
> Warning: Use of frivolous nonstandard behavior XXX.
> Hint: Use the standard YYY instead.
If these behaviors were really "frivolous" this might fly, but I don't
think the majority of users will hold still for the removal of either
GROUP BY 1 or ORDER BY
I wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Just so people know, I'm fixing those (tsearch-created make check failures
>> on msvc). It's been a bad week this week at work, but I hope to get around
>> to fix these beginning of next week.
> IIRC the work left to do is to port the const
Tom Lane wrote:
> Part of the reason for being conservative about changing here
> is that we've got a mix of standard and nonstandard behaviors
>
> A lot of this is legacy behavior that would never have passed muster
> if it had been newly proposed in the last few years --- we have gotten
> *far*
Nota: mensaje reenviado como archivo adjunto.
Sé un Mejor Amante del Cine
¿Quieres saber cómo? ¡Deja que otras personas te ayuden!
http://advision.webevents.yahoo.com/reto/entret
On Fri, 24 Aug 2007, Kevin Grittner wrote:
I would be fine with that if I could configure the back end to always write a
dirty page to the OS when it is written to shared memory. That would allow
Linux and XFS to do their job in a timely manner, and avoid this problem.
You should take a look
On Thu, 2007-08-23 at 17:04 -0400, Andrew Dunstan wrote:
> I have just noticed that we are still accepting data that is invalid for
> the server encoding, and in consequence we can produce a dump which we
> can't subsequently load. This is a major bug IMNSHO, and needs to be
> fixed for 8.3.
I
Edoardo wrote:
On Aug 24, 4:27 pm, [EMAIL PROTECTED] ("Heikki Linnakangas")
wrote:
Edoardo wrote:
- Google Summer of Code effort by Florian Pflug
I would like to talk about the last one: I couldn't find any website /
explanation or further post.
The google
linkhttp://code.google.com/soc/postgr
Bill Thoen <[EMAIL PROTECTED]> writes:
> I'm a bit out of my depth with using these debugging tools and
> interpreting their results, but I think the problem is due to the output
> being just too big for interactive display.
Well, I can certainly believe it's related to the amount of data
involv
I'm a bit out of my depth with using these debugging tools and
interpreting their results, but I think the problem is due to the output
being just too big for interactive display. Using the same query with
tighter limits in the WHERE clause works perfectly. When I changed the
SQL script to writ
Tom Lane <[EMAIL PROTECTED]> writes:
> Manuel Sugawara <[EMAIL PROTECTED]> writes:
>> "Marko Kreen" <[EMAIL PROTECTED]> writes:
>>> In 8.0 the pgcrypto functions were non-strict and checked for NULLs.
>>> In 8.1 they were made STRICT.
>>> In 8.2 the NULL check were removed from code.
>
>> Not an s
Manuel Sugawara <[EMAIL PROTECTED]> writes:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
>> In 8.0 the pgcrypto functions were non-strict and checked for NULLs.
>> In 8.1 they were made STRICT.
>> In 8.2 the NULL check were removed from code.
> Not an smart move IMHO, I didn't create the function,
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Any tests which focus just on throughput don't address the problems which
> caused us so much grief.
This is a good point: a steady-state load is either going to be in the
regime where you're not write-bottlenecked, or the one where you are;
and eithe
On Aug 24, 4:27 pm, [EMAIL PROTECTED] ("Heikki Linnakangas")
wrote:
> Edoardo wrote:
> > - Google Summer of Code effort by Florian Pflug
>
> > I would like to talk about the last one: I couldn't find any website /
> > explanation or further post.
> > The google
> > linkhttp://code.google.com/soc/p
Bill Thoen <[EMAIL PROTECTED]> writes:
> (gdb) bt
> #0 0x003054264571 in fputc () from /lib64/libc.so.6
> #1 0x0040dbc2 in print_aligned_text (title=0x0, headers=0x5665d0,
> cells=0x2f8fc010, footers=0x557c90,
> opt_align=0x557ef0 'l' , "rr", 'l' times>, "rl lll", opt
Charles N. Charotti wrote:
Hi Everybody,
I want to know if there is any plan in future versions
of PG to obfuscate the source code of some objects of
the database, specially the functions of the backend ?
I mean the text definition of each function or perhaps
even triggers of the database.
J
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Charles N. Charotti wrote:
> Hi Everybody,
>
> I want to know if there is any plan in future versions
> of PG to obfuscate the source code of some objects of
> the database, specially the functions of the backend ?
Functions in the backend written wi
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> On 8/24/07, Manuel Sugawara <[EMAIL PROTECTED]> wrote:
>> Manuel Sugawara <[EMAIL PROTECTED]> writes:
>> > I have a simple query that uses digest(data, 'sha1') and consistently
>> > crashes the backend
>>
>> The problem is with null arguments:
>>
>> cien
On Fri, Aug 24, 2007 at 04:59:13PM +0200, Charles N. Charotti wrote:
> I want to know if there is any plan in future versions
> of PG to obfuscate the source code of some objects of
> the database, specially the functions of the backend ?
There have been requests for this, but AFAIK nobody has co
Charles,
> I want to know if there is any plan in future versions
> of PG to obfuscate the source code of some objects of
> the database, specially the functions of the backend ?
>
> I mean the text definition of each function or perhaps
> even triggers of the database.
Not seriously, no. Securi
>>> On Fri, Aug 24, 2007 at 7:41 AM, in message
<[EMAIL PROTECTED]>, "Heikki Linnakangas"
<[EMAIL PROTECTED]> wrote:
> I was not able to find a test where turning bgwriter on performed better
> than turning it off.
Any tests which focus just on throughput don't address the problems which
caused
On Fri, 24 Aug 2007, Tom Lane wrote:
Heikki makes a good point nearby that if you are not disk write
bottlenecked then it's perfectly OK for backends to issue writes, as
it'll just result in a transfer to kernel cache space, and no actual
wait for I/O. And if you *are* write-bottlenecked, the
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>
>> Note that if you use something like fetchrow_hashref it will actually
>> condense
>> out duplicate column names since it loads the row into a hash. So if you
>> you're writing a program which just wants to dum
Gregory Stark <[EMAIL PROTECTED]> writes:
> How does all of this relate to your epiphany that we should just have
> bgwriter be a full clock sweep ahead clock hand without retracing its
> steps?
Well, it's still clearly silly for the bgwriter to rescan buffers it's
already cleaned. But I think we
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> ... note that we fail to meet (c)
>> exactly, since we don't bother to generate names that are distinct ---
>> but in practice no one seems to care about that.)
> Actually I suspect there are people who get annoy
Hi all,
I want to add a column, i.e. an additional TargetEntry, in an executor node
named Foo that is placed on top of the usually created plan. This node Foo will
calculate the column which is then used to sort the relation subsequently. If
desired, the column added by Foo is finally removed b
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Just so people know, I'm fixing those (tsearch-created make check failures
> on msvc). It's been a bad week this week at work, but I hope to get around
> to fix these beginning of next week.
IIRC the work left to do is to port the construction of the
s
Hi Everybody,
I want to know if there is any plan in future versions
of PG to obfuscate the source code of some objects of
the database, specially the functions of the backend ?
I mean the text definition of each function or perhaps
even triggers of the database.
Just in case, somebody knows of
On Thu, Aug 23, 2007 at 02:06:16PM -0400, Chuck McDevitt wrote:
> In general, we wouldn't want to support any de facto standard that:
>
> 1. Is supported only by one vendor
> 2. Causes any standard SQL statement to fail, or return a different
> answer from the standard.
>
> The proposed cha
Edoardo wrote:
> - Google Summer of Code effort by Florian Pflug
>
> I would like to talk about the last one: I couldn't find any website /
> explanation or further post.
> The google link
> http://code.google.com/soc/postgres/appinfo.html?csaid=6545828A8197EBC6
> is broken
> does anybody knows s
Hi,
I am searching for a simple replication solution for postgres and I
found some webpages and forum threads like this one:
http://groups.google.com/group/pgsql.performance/browse_thread/thread/8e79c0b0136964e8/fa8692ca4f987722?lnk=st&q=skytools+postgres+replication&rnum=9#fa8692ca4f987722
basi
Gregory Stark wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
>> Greg Smith <[EMAIL PROTECTED]> writes:
>>> In the interest of closing work on what's officially titled the "Automatic
>>> adjustment of bgwriter_lru_maxpages" patch, I wanted to summarize where I
>>> think this is at ...
>>> 2) H
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Greg Smith <[EMAIL PROTECTED]> writes:
>> In the interest of closing work on what's officially titled the "Automatic
>> adjustment of bgwriter_lru_maxpages" patch, I wanted to summarize where I
>> think this is at ...
>
>> 2) Having backends write their o
"Tom Lane" <[EMAIL PROTECTED]> writes:
> c) Otherwise, the of the i-th column of thespecification> is implementation-dependent and different
> from the of any column, other than itself, of
> a table referenced by any contained in the
>
Just so people know, I'm fixing those (tsearch-created make check failures
on msvc). It's been a bad week this week at work, but I hope to get around
to fix these beginning of next week.
//Magnus
---(end of broadcast)---
TIP 6: explain analyze is yo
Manuel Sugawara wrote:
I have a simple query that uses digest(data, 'sha1') and consistently
crashes the backend
The problem is with null arguments:
ciencias=# select digest(null, 'sha1');
el servidor ha cerrado la conexión inesperadamente,
Can you check if the function is defined "STRICT"?
On 8/24/07, Manuel Sugawara <[EMAIL PROTECTED]> wrote:
> Manuel Sugawara <[EMAIL PROTECTED]> writes:
> > I have a simple query that uses digest(data, 'sha1') and consistently
> > crashes the backend
>
> The problem is with null arguments:
>
> ciencias=# select digest(null, 'sha1');
In 8.0 the pgcr
40 matches
Mail list logo
