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
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
"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
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
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
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.
> 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
> 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
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
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
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
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
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
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
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"
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
16 matches
Mail list logo
