Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Should that sequence really stick around as an integer, numeric and text
field???
What are you unhappy about exactly? We expended a fair amount of sweat
to make it behave just like that ...
regards, tom lane
Should that sequence really stick around as an integer, numeric and text
field???
What are you unhappy about exactly? We expended a fair amount of sweat
to make it behave just like that ...
It's confused the odd IRC user (pgsql newbie). Seems like it breaks the
'serial type' illusion...
I
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I presume they have to drop the default, then drop the sequence to get
rid of it.
Hmm. Right at the moment I don't think you *can* get rid of it, short
of dropping the column altogether.
regression=# create table z(f1 serial);
NOTICE: CREATE
On Mon, 2005-04-18 at 21:25 -0400, Bruce Momjian wrote:
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The wal file could be truncated after the log switch record, though I'd
want to make sure that didn't cause other problems.
Which it would: that would break WAL file
On Tue, 2005-04-19 at 08:55 +0400, Oleg Bartunov wrote:
On Mon, 18 Apr 2005, Simon Riggs wrote:
but I'm not sure it's best practice to delete them at that point. I
would recommend that users keep at least the last 3 backups. So, I'd
prefer the wording
...all archived WAL segments with
BM Would you modify this so it can go in /contrib or pgfoundry? Is there
BM general interest for this?
Actually, I suggested to do such or similar function as internal.
PostgreSQL has inet/cidr - excellent data type and good facilities to
examine and compare inet values, but has no facilities
On Mon, Apr 18, 2005 at 08:58:01PM -0400, Bruce Momjian wrote:
Would you modify this so it can go in /contrib or pgfoundry? Is there
general interest for this?
I was about to sit down and write the same function yesterday, when as if
by magic this appeared. In my case it is to loop over ip
On Tue, 19 Apr 2005, Simon Riggs wrote:
On Tue, 2005-04-19 at 08:55 +0400, Oleg Bartunov wrote:
On Mon, 18 Apr 2005, Simon Riggs wrote:
but I'm not sure it's best practice to delete them at that point. I
would recommend that users keep at least the last 3 backups. So, I'd
prefer the wording
...all
Hello,
the nls_string function that makes it possible to sort by arbitrary
locale has been updated to reflect the changes in error handling in
PostgreSQL 8.0, due to users using the nls_string sorting on 7.4 and
requesting it for 8.0 as well. The distribution can be downloaded from
Le Tuesday 19 April 2005 04:16, vous avez crit :
sizeof(Datum) == sizeof(long) - is that compatible with %d formatting (I'm
guessing something like vsprintf takes place in elog)? Wouldn't this need
%ld or %lu?
Sorry if this misses the point, I wasn't clear from original post if the
segfault
Simon Riggs wrote:
On Mon, 2005-04-18 at 21:25 -0400, Bruce Momjian wrote:
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The wal file could be truncated after the log switch record, though I'd
want to make sure that didn't cause other problems.
Which it would: that
Ilya A. Kovalenko wrote:
BM Would you modify this so it can go in /contrib or pgfoundry? Is there
BM general interest for this?
Actually, I suggested to do such or similar function as internal.
PostgreSQL has inet/cidr - excellent data type and good facilities to
examine and compare inet
Bruce Momjian pgman@candle.pha.pa.us writes:
I was thinking of the archiver filling because of lots of almost-empty
16mb files. If you archive every five seconds, it is 11 Gigs/hour,
which is not too bad, I guess, but I would bet compression would save
space and I/O load too.
If you wanted
Bruce Momjian pgman@candle.pha.pa.us writes:
am thinking we should support only inet + inet, like this:
SELECT '1.2.3.4'::inet + '0.0.1.2'::inet;
I don't think inet+inet makes any sense.
I think inet+int4 should work by adding to the host address and overflowing if
it exceeds the
Greg Stark wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
am thinking we should support only inet + inet, like this:
SELECT '1.2.3.4'::inet + '0.0.1.2'::inet;
I don't think inet+inet makes any sense.
I think inet+int4 should work by adding to the host address and
On Tue, Apr 19, 2005 at 11:05:32AM -0400, Bruce Momjian wrote:
Simon Riggs wrote:
The disk would only fill if the archiver doesn't keep up with
transmitting xlog files to the archive. The archive can fill up if it is
not correctly sized, even now. Switching log files every N seconds would
Alvaro Herrera wrote:
On Tue, Apr 19, 2005 at 11:05:32AM -0400, Bruce Momjian wrote:
Simon Riggs wrote:
The disk would only fill if the archiver doesn't keep up with
transmitting xlog files to the archive. The archive can fill up if it is
not correctly sized, even now. Switching log
Bruce Momjian pgman@candle.pha.pa.us writes:
Ie,
10.0.0.0/24 + 1 = 10.0.0.1/24
10.0.0.255/24 + 1 = overflow
Or
10.1/16 + 1 = 10.1.0.1/16
10.1/16 + 16384 = 10.1.64.0/16
10.1/16 + 65536 = overflow
So, do not overflow?
You mean not doing modulus arithemtic?
On Tue, 2005-04-19 at 15:23 +0400, Oleg Bartunov wrote:
This is not an argument ! It's shame we still don't understand do we really
have reliable online backup or just hype with a lot of restriction and
caution. I'm not experienced Oracle DBA but I don't want to be a blind user.
I read
Jeff Davis wrote:
Unless I misunderstand something, I think you're overreacting a bit. The
failure case is that the machine on which the database resides vaporizes
after you've done pg_stop_backup() but before the archiver archives
the WAL segments used during the backup procedure.
In
On Tue, 19 Apr 2005, Jeff Davis wrote:
Unless I misunderstand something, I think you're overreacting a bit. The
Y're right. It's all emotions :)
Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
* Tom Lane [EMAIL PROTECTED] [19.04.2005 19:48]:
That's probably what you *have* to use, since the normal deconstructors
assume they are working with heap tuples, which are different. But I
don't understand why you are waiting till after the index tuple is
formed. The aminsert function gets
On Tue, Apr 19, 2005 at 12:03:27 -0400,
Bruce Momjian pgman@candle.pha.pa.us wrote:
Agreed. Let's implement '+/-' for 'inet + int4' and put it in the
backend as standard (I can help do the system table stuff if you give me
the C functions). However, how do we handle cases where int4 255.
I have dbt-2 tests automatically running against each pull from CVS
and have started to automatically compile results here:
http://developer.osdl.org/markw/postgrescvs/
I did start with a bit of a minimalistic approach, so I'm open for any
comments, feedback, etc.
Mark
On Sun, Apr 17, 2005 at 07:01:41PM -0400, Christopher Browne wrote:
The world rejoiced as [EMAIL PROTECTED] (Jim C. Nasby) wrote:
On Sun, Apr 17, 2005 at 06:56:01AM -0700, Joshua D. Drake wrote:
Is it really an important area to improve, or are there other
priorities? I know some people
Added to TODO:
* Add tool to query pg_stat_* tables and report indexes that aren't
needed
or tables that might need indexes
---
Christopher Kings-Lynne wrote:
I was thinking of writing a command line
Good god - how old was that email? 2002???
Chris
Bruce Momjian wrote:
Added to TODO:
* Add tool to query pg_stat_* tables and report indexes that aren't
needed
or tables that might need indexes
---
Christopher Kings-Lynne wrote:
Good god - how old was that email? 2002???
Yep, and been in my mailbox since then, waiting for me to process it
into a TODO entry.
---
Chris
Bruce Momjian wrote:
Added to TODO:
BM Greg Stark wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
am thinking we should support only inet + inet, like this:
SELECT '1.2.3.4'::inet + '0.0.1.2'::inet;
I don't think inet+inet makes any sense.
I think inet+int4 should work by adding to the host address and
GS I see a use case for of generating addresses based on a sequence or some
GS primary key from the database.
GS Something like
GS CREATE SEQUENCE hosts_ip_seq MAXVALUE 65536;
GS ALTER TABLE hosts ALTER ip SET DEFAULT '10.0.0.0/16'::inet +
nextval(hosts_ip_seq')
hmm, not quite good idea -
30 matches
Mail list logo