Kris Jurka [EMAIL PROTECTED] writes:
Gcc 4.3 has started to perform optimizations based on the denial of the
existence of signed overflow. Building CVS HEAD with gcc 4.3rc2 I get the
following warnings:
Hmm, I suspect that it's not so much that they're performing new
optimizations as that
On Sun, 9 Mar 2008, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I've coded a small patch to allow CaseSensitive synonyms.
Applied with corrections (it'd be good if you at least pretended to test
stuff before submitting it).
Would a similar parameter be useful for any of the other
On Mon, 10 Mar 2008, Tom Lane wrote:
I am wondering if these checks have been no-ops in Postgres builds done
with gcc 4.1 and up, and we're only just now being told about it.
Since gcc 4.2 supports -Wstrict-overflow, I rebuilt pg with that to see
what it's doing currently. I'm not sure
On Sun, Mar 09, 2008 at 10:45:59PM +0100, Dawid Kuroczko wrote:
alter table tab add column col integer not null default 42 check (col 0);
I think this will not solve the OP's problem. He wants to minimize the time
a table is under exclusive lock, and this ALTER command will effectively
Am Freitag, 7. März 2008 schrieb Tom Lane:
I'm not wedded to the number 1000 in particular --- obviously that's
just a round number. But it would be good to see some performance tests
with larger settings before deciding that we don't need a limit.
Well, I'm not saying we should raise the
On Sun, 2008-03-09 at 23:03 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I've coded a small patch to allow CaseSensitive synonyms.
Applied with corrections (it'd be good if you at least pretended to test
stuff before submitting it).
It is a frequent accusation of yours that
Le Monday 10 March 2008, Peter Eisentraut a écrit :
Am Freitag, 7. März 2008 schrieb Tom Lane:
I'm not wedded to the number 1000 in particular --- obviously that's
just a round number. But it would be good to see some performance tests
with larger settings before deciding that we don't
Simon Riggs wrote:
As Greg mentions on another thread, not all patches are *intended* to be
production quality by their authors. Many patches are shared for the
purpose of eliciting general feedback. You yourself encourage a group
development approach and specifically punish those people
On Mon, Mar 10, 2008 at 11:36 AM, Peter Eisentraut [EMAIL PROTECTED] wrote:
The time to analyze is also quite constant, just before you run out of
memory. :) The MaxAllocSize is the limiting factor in all this. In my
example, statistics targets larger than about 80 created pg_statistic
Hello,
Let me try again...
Here is simple example.
To do:
alter table users add column integer not null default 0;
Table is big, updated, referenced etc (big - means that alter lock the
table long enought
to kill the system). Note that it is not my design - I have to do
alter the table...
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Freitag, 7. März 2008 schrieb Tom Lane:
IIRC, egjoinsel is one of the weak spots, so tests involving planning of
joins between two tables with large MCV lists would be a good place to
start.
I have run tests with joining two and three tables with
On Mon, 2008-03-10 at 08:24 -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
As Greg mentions on another thread, not all patches are *intended* to be
production quality by their authors. Many patches are shared for the
purpose of eliciting general feedback. You yourself encourage a group
Tom Lane [EMAIL PROTECTED] writes:
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Freitag, 7. März 2008 schrieb Tom Lane:
IIRC, egjoinsel is one of the weak spots, so tests involving planning of
joins between two tables with large MCV lists would be a good place to
start.
I have run tests
Andrew Dunstan [EMAIL PROTECTED] writes:
I think if you post something marked Work In Progress, there is an
implied commitment on your part to post something complete at a later stage.
It *wasn't* marked Work In Progress, and Simon went out of his way to
cross-post it to -patches, where the
On Mon, 2008-03-10 at 09:42 -0400, Andrew Dunstan wrote:
I think if you post something marked Work In Progress, there is an
implied commitment on your part to post something complete at a later stage.
So if it's forgotten you would be the one doing the forgetting. ;-)
But if they aren't on
Simon Riggs wrote:
On Mon, 2008-03-10 at 08:24 -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
As Greg mentions on another thread, not all patches are *intended* to be
production quality by their authors. Many patches are shared for the
purpose of eliciting general feedback. You
Oleg Bartunov [EMAIL PROTECTED] writes:
On Sun, 9 Mar 2008, Tom Lane wrote:
Would a similar parameter be useful for any of the other dictionary
types?
There are many things desirable to do with dictionaries, for example,
say dictionary to return an original word plus it's normal form.
On Mon, 2008-03-10 at 10:01 -0400, Tom Lane wrote:
In future perhaps I should take it as a given that
Simon doesn't expect his patches to be applied?
I think you should take it as a given that Simon would like to try to
work together, sharing ideas and code, without insults and public
derision
Andrew Dunstan wrote:
Simon Riggs wrote:
As Greg mentions on another thread, not all patches are *intended* to be
production quality by their authors. Many patches are shared for the
purpose of eliciting general feedback. You yourself encourage a group
development approach and
Hmm, I can see how some middleware would help with folding or not
folding the input token, but what about the words coming from the
dictionary file (particularly the *output* lexeme)? It's not apparent
to me that it's sensible to try to control that from outside the
dictionary.
Right now I see
Well, if you think this can/should be done somewhere outside the
dictionary, should I revert the applied patch?
No, that patch is about case sensitivity of synonym dictionary. I suppose, Simon
wants to replace 'bill' to 'account', but doesn't want to get 'account Clinton'
For another
Kris Jurka [EMAIL PROTECTED] writes:
Gcc 4.3 has started to perform optimizations based on the denial of the
existence of signed overflow.
...
I don't understand the difference between -fwrapv and
-fno-strict-aliasing, but it seems we need at least one of them.
I don't see
Teodor Sigaev [EMAIL PROTECTED] writes:
Hmm, I can see how some middleware would help with folding or not
folding the input token, but what about the words coming from the
dictionary file (particularly the *output* lexeme)? It's not apparent
to me that it's sensible to try to control that
Right now I see an significant advantage of such layer: two possible
extension of dictionary (filtering and storing original form) are
One more extension: drop too long words. For example, decrease limit of max
length of word to prevent long to be indexed - word with 100 characters is
Hi,
what's your opinion on this?
I saw response only from Alvaro on the -patches list.
Thanks in advance,
Zoltán Böszörményi
Eredeti üzenet
Tárgy: Re: [PATCHES] 64-bit CommandIds
Dátum: Tue, 04 Mar 2008 21:52:25 +0100
Feladó: Zoltan Boszormenyi [EMAIL PROTECTED]
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
Hi,
what's your opinion on this?
I saw response only from Alvaro on the -patches list.
I don't understand. The patch only affects configuration and SQL data type
code. It doesn't actually store the 64-bit commandid anywhere which would be
the
I'm reviewing this patch
http://archives.postgresql.org/pgsql-patches/2007-04/msg00531.php
which contains this configure.in code to decide if it's safe to allow
use of non-segmented files:
if test $ac_cv_func_fseeko = yes; then
AC_SYS_LARGEFILE
fi
+ if test $ac_cv_sys_large_files = no -o
Gregory Stark wrote:
I don't understand. The patch only affects configuration and SQL data type
code. It doesn't actually store the 64-bit commandid anywhere which would be
the actual hard part.
Sure it does, this is the significant part of the patch:
*** pgsql.orig/src/include/c.h
Bruce Momjian wrote:
I have an idea for this TODO item:
* Allow administrators to safely terminate individual sessions either
via an SQL function or SIGTERM
Lock table corruption following SIGTERM of an individual backend
has been reported in 8.0. A
Bruce Momjian [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
When we get the termination signal, why can't we just set a global
boolean, do a query cancel, and in the setjmp() code block check the
global and exit --- at that stage we know we have released all locks and
can exit cleanly.
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
When we get the termination signal, why can't we just set a global
boolean, do a query cancel, and in the setjmp() code block check the
global and exit --- at that stage we know we have released all locks and
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
When we get the termination signal, why can't we just set a global
boolean, do a query cancel, and in the setjmp() code block check the
global and exit --- at that stage we know we have released all locks and
Am Montag, 10. März 2008 schrieb Gregory Stark:
It's not possible to believe that you'd not notice O(N^2) behavior for N
approaching 80 ;-). Perhaps your join columns were unique keys, and
thus didn't have any most-common-values?
We could remove the hard limit on statistics target and
Am Montag, 10. März 2008 schrieb Tom Lane:
A quick look at the configure script suggests that the available macros
don't really set anything that specifically tells you if they found
working largefile support. I'm considering doing AC_CHECK_SIZEOF(off_t)
and then looking at the result
That
Bruce Momjian [EMAIL PROTECTED] writes:
I am suggesting we add a new fuction pg_terminate_backend() that does
everything just like cancel, but also sets a global variable that we
check in the loop where we look for the next command and if it is set,
we exit the backend.
And if you never *get*
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am suggesting we add a new fuction pg_terminate_backend() that does
everything just like cancel, but also sets a global variable that we
check in the loop where we look for the next command and if it is set,
we exit the backend.
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Keep in mind that 99% of the excuse for people to want to use SIGTERM is
that the backend isn't responding to SIGINT. If you've fixed things so
that SIGTERM cannot get them out of any situation that SIGINT doesn't
get them out of, I
Zdenek Kotala [EMAIL PROTECTED] writes:
There is latest version of nonsegment support patch. I changed
LET_OS_MANAGE_FILESIZE to USE_SEGMENTED_FILES and I added
-disable-segmented-files switch to configure. I kept tuplestore behavior
and it still split file in both mode.
Applied with minor
We could remove the hard limit on statistics target and
impose the limit
instead on the actual size of the arrays. Ie, allow people to
specify larger
sample sizes and discard unreasonably large excess data
(possibly warning them
when that happens).
That would remove the screw case the
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
There is latest version of nonsegment support patch. I changed
LET_OS_MANAGE_FILESIZE to USE_SEGMENTED_FILES and I added
-disable-segmented-files switch to configure. I kept tuplestore behavior
and it still split file in both mode.
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
Applied with minor corrections.
Why is this not the default when supported?
Fear.
Maybe eventually, but right now I think it's too risky.
One point that I already found out the hard way is that sizeof(off_t) = 8
does not guarantee
Peter Eisentraut wrote:
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
There is latest version of nonsegment support patch. I changed
LET_OS_MANAGE_FILESIZE to USE_SEGMENTED_FILES and I added
-disable-segmented-files switch to configure. I kept tuplestore behavior
and it
Does it make any sense to allow LISTEN or UNLISTEN in a prepared
transaction?
It's certainly not sensical for these actions to affect the backend that
actually executes the COMMIT PREPARED, in the sense of creating or
destroying pg_listener entries for it. But how can we say that they
should
Alvaro Herrera [EMAIL PROTECTED] writes:
Also it would get more buildfarm coverage if it were default. If it
breaks something we'll notice earlier.
Since nothing the regression tests do even approach 1GB, the odds that
the buildfarm will notice problems are approximately zero.
Tom Lane wrote:
Does it make any sense to allow LISTEN or UNLISTEN in a prepared
transaction?
...
Comments?
Assuming I understand your question - I don't think of LISTEN or
UNLISTEN as being valuable from a transaction perspective. It's possible
I'm missing something - but I think the
Mark Mielke [EMAIL PROTECTED] writes:
... I think the transaction overhead, and
attempts to re-use PostgreSQL tables to implement LISTEN/NOTIFY to be
clever but mis-guided.
Oh, I don't disagree with you. As I already mentioned, they desperately
need to be rewritten. However, given that
Tom Lane wrote:
Mark Mielke [EMAIL PROTECTED] writes:
... I think the transaction overhead, and
attempts to re-use PostgreSQL tables to implement LISTEN/NOTIFY to be
clever but mis-guided.
Oh, I don't disagree with you. As I already mentioned, they desperately
need to be rewritten.
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Keep in mind that 99% of the excuse for people to want to use SIGTERM is
that the backend isn't responding to SIGINT. If you've fixed things so
that SIGTERM cannot get them out of any situation that SIGINT doesn't
48 matches
Mail list logo
