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 SIGI
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.
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:
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 tra
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.
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 affe
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
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 guaran
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 bo
> 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
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
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
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 b
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
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
Tha
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 tar
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
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
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 clea
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.
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 2008-03-02
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"
"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
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]>
Cí
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
suspic
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 -fno-stric
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 dictiona
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
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
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 a
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
derisio
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 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
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
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 yours
"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.
>
>
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
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 ta
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... b
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_stati
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 droppi
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
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 you
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 d
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 effective
45 matches
Mail list logo
