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 in the rain but
giving im a hint by time of what might happen if there was no action. I
have absolutely no
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
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
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
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 should
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
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
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 priority.
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);
When using
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 =
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
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_full =
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
behavior,
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?
Like:
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
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 translating insert
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 to 4
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
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
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.
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
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
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:
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
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
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 ...
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?
...
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.
---
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:
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 GPL ?
I
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
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
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.
When I went
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
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
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.
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
Bruce Momjian pgman@candle.pha.pa.us 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
Bruce Momjian pgman@candle.pha.pa.us 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
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 merely
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 to be
Bruce Momjian pgman@candle.pha.pa.us 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
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 that
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 use
it
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 offhand that
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
some functionality in
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_open':
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
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 need to
49 matches
Mail list logo
