Re: [HACKERS] Weirdess when altering serial column type

2005-04-19 Thread Tom Lane
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

Re: [HACKERS] Weirdess when altering serial column type

2005-04-19 Thread Christopher Kings-Lynne
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

Re: [HACKERS] Weirdess when altering serial column type

2005-04-19 Thread Tom Lane
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

Re: [HACKERS] Problem with PITR recovery

2005-04-19 Thread Simon Riggs
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

Re: [HACKERS] Problem with PITR recovery

2005-04-19 Thread Simon Riggs
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

Re: [HACKERS] inet increment w/ int8

2005-04-19 Thread Ilya A. Kovalenko
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

Re: [HACKERS] inet increment w/ int8

2005-04-19 Thread Patrick Welche
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

Re: [HACKERS] Problem with PITR recovery

2005-04-19 Thread Oleg Bartunov
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

[HACKERS] ORDER BY different locales for 8.0

2005-04-19 Thread Honza Pazdziora
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

Re: [HACKERS] SETOF function call

2005-04-19 Thread Olivier Thauvin
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

Re: [HACKERS] Problem with PITR recovery

2005-04-19 Thread Bruce Momjian
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

Re: [HACKERS] inet increment w/ int8

2005-04-19 Thread Bruce Momjian
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

Re: [HACKERS] Problem with PITR recovery

2005-04-19 Thread Tom Lane
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

Re: [HACKERS] inet increment w/ int8

2005-04-19 Thread Greg Stark
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

Re: [HACKERS] inet increment w/ int8

2005-04-19 Thread Bruce Momjian
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

Re: [HACKERS] Problem with PITR recovery

2005-04-19 Thread Alvaro Herrera
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

Re: [HACKERS] Problem with PITR recovery

2005-04-19 Thread Bruce Momjian
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

Re: [HACKERS] inet increment w/ int8

2005-04-19 Thread Greg Stark
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?

Re: [HACKERS] Problem with PITR recovery

2005-04-19 Thread Jeff Davis
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

Re: [HACKERS] Problem with PITR recovery

2005-04-19 Thread Bruce Momjian
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

Re: [HACKERS] Problem with PITR recovery

2005-04-19 Thread Oleg Bartunov
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,

Re: [HACKERS] Comparing Datum's at aminsert() stage

2005-04-19 Thread Victor Y. Yegorov
* 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

Re: [HACKERS] inet increment w/ int8

2005-04-19 Thread Bruno Wolff III
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.

Re: [HACKERS] PLM pulling from CVS nightly for testing in STP

2005-04-19 Thread Mark Wong
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

Re: [HACKERS] argtype_inherit() is dead code

2005-04-19 Thread Jim C. Nasby
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

Re: [HACKERS] [GENERAL] Idea for the statistics collector

2005-04-19 Thread Bruce Momjian
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

Re: [HACKERS] [GENERAL] Idea for the statistics collector

2005-04-19 Thread Christopher Kings-Lynne
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 ---

Re: [HACKERS] [GENERAL] Idea for the statistics collector

2005-04-19 Thread Bruce Momjian
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:

Re: [HACKERS] inet increment w/ int8

2005-04-19 Thread Ilya A. Kovalenko
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

Re: [HACKERS] inet increment w/ int8

2005-04-19 Thread Ilya A. Kovalenko
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 -