On Thu, 2008-10-23 at 21:32 -0400, Tom Lane wrote:
> We've occasionally talked about allowing pending-trigger-event lists to
> spill to disk when there get to be so many events that it's a memory
> problem. I'm not especially interested in doing that right now, but
> I noticed recently that we c
Simon Riggs <[EMAIL PROTECTED]> writes:
> A much better objective would be to remove duplicate trigger calls, so
> there isn't any build up of trigger data in the first place. That would
> apply only to immutable functions. RI checks certainly fall into that
> category.
They're hardly "duplicates"
In view of the GiST index corruption bug that was found this week [1],
the core committee has determined that we should put out new update
releases, even though it's only been a month since the last set.
Updates will go back at least to 8.1 to fix the GiST problem ---
still undecided about whether
On Sat, 2008-10-25 at 08:48 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > A much better objective would be to remove duplicate trigger calls, so
> > there isn't any build up of trigger data in the first place. That would
> > apply only to immutable functions. RI checks certa
Tom Lane <[EMAIL PROTECTED]> writes:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>> A much better objective would be to remove duplicate trigger calls, so
>> there isn't any build up of trigger data in the first place. That would
>> apply only to immutable functions. RI checks certainly fall into th
Could someone pretty please fix the email setup on maia-4.hub.org? It
identifies itself as localhost e.g.:
Received: from localhost (unknown [200.46.204.183])
by postgresql.org (Postfix) with ESMTP id 03CF864FDE1
for <[EMAIL PROTECTED]>; Fri, 24 Oct 2008 18:23:37 -0300 (ADT)
Spama
I've recently been investigating long-running statements that,
despite statement_timeout settings and pg_cancel_backend() attempts,
remain visible in pg_stat_activity and continue to hold locks. When
this happens, a process trace and a debugger show that the backend
is blocked at the send() in sec
Michael Fuhr <[EMAIL PROTECTED]> writes:
> I've recently been investigating long-running statements that,
> despite statement_timeout settings and pg_cancel_backend() attempts,
> remain visible in pg_stat_activity and continue to hold locks. When
> this happens, a process trace and a debugger show
> There's 6 cases here, in a 2x3 array. In one dimension, the LHS can be
> either a Var or a fixed value. In the other dimension, the three
> possibilities are 1: everything on the RHS is a fixed value, 2: some fixed,
> some not, 3: everything on the RHS is a variable:
[...lengthy discussion of cas
> I really think we should have a way of telling if a array/row/record
> variable is actually set to something, and I'm pretty sure that should be
> unrelated to whether all the elements in it happen to be null.
+1. Also, can whatever syntax we introduce by something relatively
concise? Code tha
On Sat, Oct 25, 2008 at 11:59 AM, Robert Haas <[EMAIL PROTECTED]> wrote:
> > I really think we should have a way of telling if a array/row/record
> > variable is actually set to something, and I'm pretty sure that should be
> > unrelated to whether all the elements in it happen to be null.
>
> +1.
Tom Lane a écrit :
> Guillaume Lelarge <[EMAIL PROTECTED]> writes:
>> So, it seems to work. I say "seems" because there's no XLOG record that
>> says I moved all relations from one tablespace to another. Am I right in
>> thinking I need to insert a new XLOG record? should I create a new one?
>
> Y
Hi,
Here is my patch to add the ALTER DATABASE WITH TABLESPACE statement. It
is part of the TODO list. It intends to allow the move of all relations
of a database in its new default tablespace.
Comments welcome.
Regards.
--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com
AlterDat
"Robert Haas" <[EMAIL PROTECTED]> writes:
> Given that, would it make any sense to put all the
> constants in an ARRAY and use OR for any variables? i.e. given
> Whatever IN (Const1, Var1, Const2, Var2, Const3, Var3)
> Generate:
> Whatever = ANY (ARRAY[Const1, Const2, Const3]) OR Whatever = Var
On Sat, Oct 25, 2008 at 12:36:24PM -0400, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > If the write is interrupted by a timeout or cancel, can anything
> > be done here or elsewhere to abort the statement and release its
> > locks?
>
> The best thing would really be to kill the c
I'm taking a look at doing the refactoring Tom Lane and Simon Riggs
discussed here:
http://archives.postgresql.org/pgsql-patches/2008-02/msg00155.php
In terms of the buffer manager, I think we can simply introduce a new
strategy type BAS_BULKWRITE and make it behave identically to
BAS_VACUUM. An
16 matches
Mail list logo
