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 pgcrypto
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?
Tom Lane [EMAIL PROTECTED] writes:
c) Otherwise, the column name of the i-th column of the query
specification is implementation-dependent and different
from the column name of any column, other than itself, of
a table referenced by any
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
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 own buffers out
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) Having backends write
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=stq=skytools+postgres+replicationrnum=9#fa8692ca4f987722
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
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 change
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
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
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've
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
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 annoyed by it when
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 dump the record
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,
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 us so
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. Security by
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
-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 with
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:
ciencias=# select
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' repeats 18 times, rr, 'l' repeats 12
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
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.
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 either way
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, it was
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 smart move IMHO, I
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
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
involved,
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
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
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
Nota: mensaje reenviado como archivo adjunto.
Sé un Mejor Amante del Cine
¿Quieres saber cómo? ¡Deja que otras personas te ayuden!
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*
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 construction
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 1.
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
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
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). So
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
40 matches
Mail list logo
