Re: [HACKERS] ORDER BY different locales for 8.0

2005-04-19 Thread Mario Weilguni
Am Dienstag, 19. April 2005 09:18 schrieb 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 fo

[HACKERS] Foreign keys on array elements

2005-04-19 Thread Christopher Kings-Lynne
Hi, Can you put a foreign key constraint on an array column that says that each element of the array must match a primary key? If not, is this a TODO perhaps? Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? ht

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 -

Re: [HACKERS] inet increment w/ int8

2005-04-19 Thread Ilya A. Kovalenko
BM> Greg Stark wrote: >> >> Bruce Momjian 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 over

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] [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 --- Christophe

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 to

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 so

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] inet increment w/ int8

2005-04-19 Thread Bruno Wolff III
On Tue, Apr 19, 2005 at 12:03:27 -0400, Bruce Momjian 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 > am thinking

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

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, Ste

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. > > I

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 sem

Re: [HACKERS] inet increment w/ int8

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

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. Sw

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

Re: [HACKERS] inet increment w/ int8

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

Re: [HACKERS] inet increment w/ int8

2005-04-19 Thread Greg Stark
Bruce Momjian 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 network mask. Ie, 10

Re: [HACKERS] Problem with PITR recovery

2005-04-19 Thread Tom Lane
Bruce Momjian 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 to archive every few

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 compa

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. > > > > > > Whi

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 > se

[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 http://www.

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

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] 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] 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 segme

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