"Neil Conway" <[EMAIL PROTECTED]> writes
>
> Wasn't the plan to rewrite pg_autovacuum to use the FSM rather than the
> stats collector?
>
I don't understand. Currently the basic logic of pg_autovacuum is to use the
pg_stat_all_tables numbers like n_tup_upd, n_tup_del to determine if a
relation ne
Qingqing Zhou wrote:
The start/stop routine is quite like Bgwriter. It requires PgStats to be
turned on.
Wasn't the plan to rewrite pg_autovacuum to use the FSM rather than the
stats collector?
-Neil
---(end of broadcast)---
TIP 3: if posting/
"Jamie Deppeler" <[EMAIL PROTECTED]> writes >
> gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -fno-strict-aliasing
> -I../../src/port -DFRONTEND -I../../src/include
> -I./src/include/port/win32 -DEXEC_BACKEND
> "-I../../src/include/port/win32" -c -o open.o open.c
> open.c: In function `win32
John Hansen wrote:
> Tom Lane [mailto:[EMAIL PROTECTED] Wrote:
> > "John Hansen" <[EMAIL PROTECTED]> writes:
> > > Right,... Let me be more specific then,
> >
> > > What are your thoughts on using the glib
> > > (http://developer.gnome.org/doc/API/2.2/glib/index.html)
> > library for
> > > s
Tom Lane [mailto:[EMAIL PROTECTED] Wrote:
> "John Hansen" <[EMAIL PROTECTED]> writes:
> > Right,... Let me be more specific then,
>
> > What are your thoughts on using the glib
> > (http://developer.gnome.org/doc/API/2.2/glib/index.html)
> library for
> > some functionality in pg?
>
> Right
"John Hansen" <[EMAIL PROTECTED]> writes:
> Right,... Let me be more specific then,
> What are your thoughts on using the glib
> (http://developer.gnome.org/doc/API/2.2/glib/index.html) library for
> some functionality in pg?
Right offhand that seems like a nonstarter. Exactly how would you
"Tom Lane" <[EMAIL PROTECTED]> writes
>
> A small problem here is that until you get at least to step 3
> (backend-standard error handling), none of it is going to be acceptable
> to commit. So I don't entirely buy Bruce's notion of bite-size pieces
> of work. You can certainly work on it in tha
"Bruce Momjian" writes
>
> One goal for 8.1 is to move /contrib/pg_autovacuum in to the backend. I
> think it has to be done in four stages:
>
> o move it into the backend and have it start/stop automatically
The start/stop routine is quite like Bgwriter. It requires PgStats to be
turned on. If
Tom Lane [mailto:[EMAIL PROTECTED] Wrote:
> "John Hansen" <[EMAIL PROTECTED]> writes:
> > Is there any reason why we would not be able to use LGPL code in PG?
>
> Another point of view on this: it's OK to use LGPL code if
> it's available on the local platform, so long as we don't
> *require* it
"John Hansen" <[EMAIL PROTECTED]> writes:
> Is there any reason why we would not be able to use LGPL code in PG?
Another point of view on this: it's OK to use LGPL code if it's
available on the local platform, so long as we don't *require* it to be
present. It's even safer if the LGPL code is mer
Bruce Momjian writes:
> One goal for 8.1 is to move /contrib/pg_autovacuum in to the backend. I
> think it has to be done in four stages:
> o move it into the backend and have it start/stop automatically
> o move the autovacuum configuration parameters into postgresql.conf
>
Bruce Momjian writes:
> Christopher Kings-Lynne wrote:
>> With this Bruce, is there any reason this was accepted now, and not
>> several years ago when I first submitted it? :D
> Uh, I wasn't around then. (No, that isn't going to work.) Uh, no idea.
> I think there is a sense now that doing BE
John Hansen wrote:
Agreed.
With libreadline, we are not taking their code or
distributing it, but merely linking to it if it exists. Now,
some say that is enough to make us GPL, but many don't agree
with that interpretation.
Right,. That's actually exactly what I meant: using GPL/
John Hansen wrote:
So, what's the story with readline?
It's only used in psql. If they made a fuss presumably we'd just remove
the hooks and use libedit instead - isn't that the default on some BSD
systems anyway?
But don't plug GPL code into the backend under any circumstances.
chee
John Hansen wrote:
So, what's the story with readline?
There is a greyish clause in the GPL that says that linking to things
normally distributed with your operating system doesn't incur the
obligations of the GPL. So assuming that readline, which is GPL, is
normally distributed with your op
> Agreed.
>
> With libreadline, we are not taking their code or
> distributing it, but merely linking to it if it exists. Now,
> some say that is enough to make us GPL, but many don't agree
> with that interpretation.
Right,. That's actually exactly what I meant: using GPL/LGPL libraries
by
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
>
> >John Hansen wrote:
> >
> >
> >>What about GPL ?
> >>I assume that's out of the question!
> >>
> >>
> >
> >If we add some GPL code, the entire binary becomes GPL, and that
> >prevents closed-source commercial versions from being produced
Bruce Momjian wrote:
John Hansen wrote:
What about GPL ?
I assume that's out of the question!
If we add some GPL code, the entire binary becomes GPL, and that
prevents closed-source commercial versions from being produced.
When I went searching for some code to make a director
Er, no. It's GPL, not LGPL software. My readline.h says:
The GNU Readline Library is free software; you can redistribute it
and/or modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2, or
(at your option) any later vers
So, what's the story with readline?
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 15, 2005 12:11 PM
> To: John Hansen
> Cc: Marc G. Fournier; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] LGPL
>
> John Hansen wrote:
> > What about G
Ooooh
I got the impression that using GPL libraries was a Bad Thing(tm)
... John
> -Original Message-
> From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 15, 2005 12:15 PM
> To: Marc G. Fournier
> Cc: John Hansen; pgsql-hackers@postgresql.org
> Subject: Re: [HA
John Hansen wrote:
> What about GPL ?
> I assume that's out of the question!
If we add some GPL code, the entire binary becomes GPL, and that
prevents closed-source commercial versions from being produced.
---
>
> > -O
Marc G. Fournier wrote:
>
> We already do ... libreadline ...
libreadline is GPL, not LGPL.
---
>
> On Wed, 15 Jun 2005, John Hansen wrote:
>
> > Is there any reason why we would not be able to use LGPL code in PG?
> >
>
What about GPL ?
I assume that's out of the question!
> -Original Message-
> From: Marc G. Fournier [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 15, 2005 11:59 AM
> To: John Hansen
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] LGPL
>
>
> We already do ... libreadline
We already do ... libreadline ...
On Wed, 15 Jun 2005, John Hansen wrote:
Is there any reason why we would not be able to use LGPL code in PG?
... John
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriat
Is there any reason why we would not be able to use LGPL code in PG?
... John
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
messag
Have we made any decision on whether the old/new NUMERIC %(mod) code was
correct, and now to handle rounding? Should we offer a non-rounding
division operator for NUMERIC?
---
Paul Tillotson wrote:
> Bruce Momjian wrote:
>
Christopher Kings-Lynne wrote:
> With this Bruce, is there any reason this was accepted now, and not
> several years ago when I first submitted it? :D
Uh, I wasn't around then. (No, that isn't going to work.) Uh, no idea.
I think there is a sense now that doing BETWEEN in gram.y isn't so bad
be
One goal for 8.1 is to move /contrib/pg_autovacuum in to the backend. I
think it has to be done in four stages:
o move it into the backend and have it start/stop automatically
o move the autovacuum configuration parameters into postgresql.conf
o modify the code to use
With this Bruce, is there any reason this was accepted now, and not
several years ago when I first submitted it? :D
Also, you can update our SQL99 compatibility list to indicate that we
now have this feature :)
Chris
Bruce Momjian wrote:
Log Message:
---
Add BETWEEN SYMMETRIC.
Pav
Abhijit Menon-Sen wrote:
I've been working on making it possible for PL/Perl users to fetch large
result sets one row at a time (the current spi_exec_query interface just
returns a big hash).
The idea is to have spi_query call SPI_prepare/SPI_open_cursor, and have
an spi_fetchrow that call
Is this being actively worked on? I and others have posted bugs lately.
Dave
Dave Cramer
[EMAIL PROTECTED]
www.postgresintl.com
ICQ #14675561
jabber [EMAIL PROTECTED]
ph (519 939 0336 )
---(end of broadcast)---
TIP 8: explain analyze is your fri
Patch applied. Thanks.
---
John Hansen wrote:
> Bruce,
>
> Attached patch replaces the original, applied today against CVS HEAD.
> Fixes the surrogates, and limits to 4 byte utf8 as per spec.
>
> Also extends UtfToLocal
On 6/12/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > I believe this isn't just my problem. Without access to a the
> > underlying column's DEFAULT, how can people implement the automated
> > WRITEable VIEWs?
>
> That's a reasonable question, but translati
I prefer this option over a GUC.
Josh Berkus wrote:
People,
On second thought, we need to have a GUC for this, whether I want it or
not. It needs to be optional to the log, yes? So it would be:
log_tablespace_full = %
with the default being "0" (don't log).
On third thought, could
People,
> On second thought, we need to have a GUC for this, whether I want it or
> not. It needs to be optional to the log, yes? So it would be:
> log_tablespace_full = %
> with the default being "0" (don't log).
On third thought, could we do this as part of the maximum size declaration?
Lik
Michael,
> I've completed my first cut of adding a day field to the interval
> struct and patched up the regression tests for places where it failed
> due to the new behavior (e.g., interval '19:00' + interval '6:00' =
> interval '25:00'). I haven't added any regression tests for the DST
> behavio
Guys,
> >>I'd like to avoid a GUC for "percent_full_warning" if we can. Can
> >> anyone see a way around this? Should we just assume 90% full?
On second thought, we need to have a GUC for this, whether I want it or not.
It needs to be optional to the log, yes? So it would be:
log_tablespace
So, are we going to go with 90% or 95% as the assumed assumption for a
warning :)
Yann Michel wrote:
I'd like to avoid a GUC for "percent_full_warning" if we can. Can anyone
see a way around this? Should we just assume 90% full?
Well, it was only an idea of not leaving the admin out
Tom Lane [mailto:[EMAIL PROTECTED] wrote:
> "John Hansen" <[EMAIL PROTECTED]> writes:
> > Given the following snippet:
> > HeapTupleHeader tuple;
> > Datum temp;
> > bool isnull;
>
> > tuple = PG_GETARG_HEAPTUPLEHEADER(0);
> > temp
"John Hansen" <[EMAIL PROTECTED]> writes:
> Given the following snippet:
> HeapTupleHeader tuple;
> Datum temp;
> bool isnull;
> tuple = PG_GETARG_HEAPTUPLEHEADER(0);
> temp = GetAttributeByName(tuple, "data", &isnull);
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> Rather than eating up the extra flag bit, though, would it be possible
>> to change the tuple to appear to contain a NULL?
> We would like to preserve NULL as non-special value because we hope to add
> support of NULLs to GiST, although it's of low pri
This seems like a good answer --- if you fix up such things during
vacuum then the performance issue won't last too long.
Rather than eating up the extra flag bit, though, would it be possible
to change the tuple to appear to contain a NULL? AFAIK, GiST can't have
a NULL (at least not in the fi
Given the following snippet:
HeapTupleHeader tuple;
Datum temp;
bool isnull;
tuple = PG_GETARG_HEAPTUPLEHEADER(0);
temp = GetAttributeByName(tuple, "data", &isnull);
When using this for a btree operator func
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> ... Which ways I see:
> 5 There is one unused bit in IndexTupleData. GiST code can use it as
> mark that this tuple contains incorrect union key. In this case, GiST
> search algorithm should keep it mind that such tuple has incorrect
> value and always sh
On 6/13/2005 2:29 PM, Marc G. Fournier wrote:
On Mon, 13 Jun 2005, Andrew Dunstan wrote:
Marc G. Fournier wrote:
On Mon, 13 Jun 2005, Jan Wieck wrote:
On 6/12/2005 8:03 PM, Marc G. Fournier wrote:
Couldn't behaviour of REINDEX DATABASE not take that into account, and
'skip' the system
btree manages to avoid calling the index support functions during WAL
restore --- can't you do the same? Perhaps you need to be including
more information in the initial xlog records, so that the cleanup step
has everything it needs. Or resort to brute-force search (which is more
or less what bt
On Mon, 13 Jun 2005, Tom Lane wrote:
Teodor Sigaev <[EMAIL PROTECTED]> wrote:
... So, if index is defined as 'using gist (a,b,c)' then, in
principle, GiST index can speed up queries like 'a=V1 and c=V2'. But
it will not usable for queries ( b=V3 and c=V2 ). By the way, instead
of '=' operation
48 matches
Mail list logo
