> Without a switch, because both full page writes and
> corresponding logical log is included in WAL, this will
> increase WAL size slightly
> (maybe about five percent or so). If everybody is happy
> with this, we
> don't need a switch.
Sorry, I still don't understand that. What is the "c
Andrew - Supernews <[EMAIL PROTECTED]> wrote:
> Actually, I think your proposal is fundamentally correct, merely incomplete.
Yeah, I fixed the patch to handle '_' correctly.
> Doing octet-based rather than character-based matching of strings is a
> _design goal_ of UTF8.
I think all "safe ASCII
Attached is an updated DSM patch. I've left the core function of DSM only
and dropped other complicated features in this release.
VACUUM finishs faster with the patch, but it's obvious... DSM vacuum
sweeps only pages that have many dead tuples and leave some of them
after vacuum.
I'll examine the
Resubmitting this patch without the legal disclaimers attached to it.
Rgds,
Arul Shaji
-- FWD: --
Subject: Re: [pgsql-patches] pg_get_domaindef
Date: Thu, 25 Jan 2007 03:18:30 +1100
From: Arul Shaji <[EMAIL PROTECTED]>
To: Neil Conway <[EMAIL PROTECTED]>
Cc: pgsql-patches@post
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
Here's an update, fixing conflict by Tom's recent commit of Simon's
patch to skip WAL-inserts when archiving is not enabled.
Hmm, wouldn't it be better if the rewriteheap.c file was in
access/heap/ instead of commands/?
Yeah, maybe. I thought o
Am Dienstag, 3. April 2007 20:33 schrieb FAST PostgreSQL:
> Attached is the completed patch for the COPY-able sql log outputs.
Could you please remove random whitespace changes from this patch?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broad
Neil Conway escribió:
> As to the implementation, calling hash_remove() in a loop seems a pretty
> unfortunate way to clear a hash table -- adding a hash_reset() function
> to the dynahash API would be cleaner and faster.
I wonder why hash_drop cannot be used?
--
Alvaro Herrera
On Fri, 2007-03-30 at 10:22 +0200, Zeugswetter Andreas ADI SD wrote:
> > Without a switch, because both full page writes and
> > corresponding logical log is included in WAL, this will
> > increase WAL size slightly
> > (maybe about five percent or so). If everybody is happy
> > with this, we
Simon Riggs wrote:
On Fri, 2007-03-30 at 10:22 +0200, Zeugswetter Andreas ADI SD wrote:
Without a switch, because both full page writes and
corresponding logical log is included in WAL, this will
increase WAL size slightly
(maybe about five percent or so). If everybody is happy
with this, w
On Fri, 2007-03-30 at 11:27 +0100, Richard Huxton wrote:
> Is that always true? Could the backup not pick up a partially-written
> page? Assuming it's being written to as the backup is in progress. (We
> are talking about when disk blocks are smaller than PG blocks here, so
> can't guarantee an
Simon Riggs wrote:
On Fri, 2007-03-30 at 11:27 +0100, Richard Huxton wrote:
Is that always true? Could the backup not pick up a partially-written
page? Assuming it's being written to as the backup is in progress. (We
are talking about when disk blocks are smaller than PG blocks here, so
can't
On 3/30/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Neil Conway escribió:
> As to the implementation, calling hash_remove() in a loop seems a pretty
> unfortunate way to clear a hash table -- adding a hash_reset() function
> to the dynahash API would be cleaner and faster.
I wonder why hash_d
Am Dienstag, 27. März 2007 03:36 schrieb Tom Dunstan:
> Here's the current version of the enums patch. Not much change from last
> time, the only thought-inducing stuff was fixing up some macros that
> changed with the VARLENA changes, and adding a regression test to do
> basic checking of RI behav
This is draft version, for discussion.
New commands:
CLOSE ALL
DEALLOCATE ALL
RESET PLANS
RESET TEMPS-- please suggest better name
RESET SESSION
So in the end RESET SESSION basically executes following commands:
ABORT;
DEALLOCATE ALL;
CLOSE ALL;
RESET ALL;
SET SESSION AUTHORIZATIO
Marko Kreen escribió:
> On 3/30/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> >Neil Conway escribió:
> >
> >> As to the implementation, calling hash_remove() in a loop seems a pretty
> >> unfortunate way to clear a hash table -- adding a hash_reset() function
> >> to the dynahash API would be cle
On 3/30/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
If by destruction you mean something different than pfree, then maybe
hash_remove in a loop is the best solution, the other idea being passing
a function pointer to hash_destroy_deep to call on each element, which
is probably too messy an API.
Marko Kreen escribió:
> On 3/30/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> >In any case it's not likely that there are going to be thousands of
> >prepared statements, so is this really an issue?
>
> I think the issue is here that its very common thing to do,
> so open-coding it everywhere i
http://www.sigaev.ru/misc/indexnulls-0.8.gz
Initially patch was developed by Martijn van Oosterhout. But it's reworked and
support of searching NULLS to GiST too. Patch adds new column named amsearchnull
to pg_am. To recognize IS NULL clause ScanKey->sk_flags contains (SK_ISNULL &
SK_INDEXFIN
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> RESET TEMPS-- please suggest better name
RESET TEMP (should allow RESET TEMPORARY too). I see no reason to add
a new keyword when the existing one will do fine.
> So in the end RESET SESSION basically executes following commands:
> ABORT
Thanks, but after lots of discussion, it turns out the community doesn't
want to add such functions, and I have removed it from the TODO list.
---
FAST PostgreSQL wrote:
> Resubmitting this patch without the legal disclaimer
Tom Lane wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > RESET TEMPS-- please suggest better name
>
> RESET TEMP (should allow RESET TEMPORARY too). I see no reason to add
> a new keyword when the existing one will do fine.
>
> > So in the end RESET SESSION basically executes
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I object to having RESET SESSION include an ABORT.
> I think we should at least throw an error if someone tries RESET SESSION
> inside a transaction, and hopefully administrators will realize they
> have a problem.
PreventTransactionC
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I object to having RESET SESSION include an ABORT.
>
> > I think we should at least throw an error if someone tries RESET SESSION
> > inside a transaction, and hopefully administrators will realize they
> > have a
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Any page written during a backup has a backup block that would not be
> removable by Koichi's tool, so yes, you'd still be safe.
How does it know not to do that?
regards, tom lane
---(end of broadcast)---
On Fri, 2007-03-30 at 16:35 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > Any page written during a backup has a backup block that would not be
> > removable by Koichi's tool, so yes, you'd still be safe.
>
> How does it know not to do that?
Not sure what you mean, but I'
Simon;
Tom;
Koichi is writing.
Your question is how to determine WAL record generated between
pg_start_backup and pg_stop_backup and here's an answer.
XLogInsert( ) already has a logic to determine if inserting WAL record
is between pg_start_backup and pg_stop_backup. Currently it is used
to
On Fri, Mar 30, 2007 at 01:45:21PM -0400, Bruce Momjian wrote:
> Thanks, but after lots of discussion, it turns out the community
> doesn't want to add such functions, and I have removed it from the
> TODO list.
>From what I recall of the discussion, the lack of interest was in
actually stepping u
David Fetter <[EMAIL PROTECTED]> writes:
> On Fri, Mar 30, 2007 at 01:45:21PM -0400, Bruce Momjian wrote:
>> Thanks, but after lots of discussion, it turns out the community
>> doesn't want to add such functions, and I have removed it from the
>> TODO list.
> From what I recall of the discussion,
28 matches
Mail list logo
