Re: [HACKERS] [PATCHES] CVS should die
Greg Stark said: > > Andrew Dunstan <[EMAIL PROTECTED]> writes: > >> This just reinforces Tom's well-made point about maturity/stability. I >> rejected using SVN on another project a few months ago for just this >> sort of reason. > > I'm not sure what this says about maturity, you realize read-only > access to CVS also does writes to the repository? There are patches to > change this floating around but it's never been merged "upstream" > because there is no "upstream" maintainer any more. I guess if you want > mature software you can't get any more mature than using orphaned > packages. > I am painfully aware of CVS's behaviour - it's given us plenty of grief getting it right on pgfoundry, as well giving me occasional grief w.r.t. other repositories I am responsible for. CVS is on the way out, for plenty of very good reasons. It is past its use-by date. I don't think anyone seriously disagrees with that. Choosing when to switch to an alternative, and what the alternative will be, is the issue. For example, unless I'm wrong there is not yet a subversion equivalent of CVSup. That's something I would personally be very reluctant to lose. cheers andrew ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [PATCHES] CVS should die
Greg Stark wrote: > > Heikki Linnakangas wrote: > > > Interestingly, the subversion repository is 585MB, and the CVS > > repository is only 260MB, > > So apparently this is a limitation of svn2cvs. It uses a lot more space to > represent tags and branches than would be required if they had been created in > svn directly. Unfortunately it's a hard problem to solve any better than it > is. > > > Markus Bertheau wrote: > > > >> Here's what the subversion book has to say about that: > >> > >> http://svnbook.red-bean.com/svnbook-1.1/ch05.html#svn-ch-5-sect-1.2.A > >> > >> We use svn over ssh and recently switched to fsfs because of the umask > >> problem and because read-only access to bdb causes writes to the > >> database. > > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > > This just reinforces Tom's well-made point about maturity/stability. I rejected > > using SVN on another project a few months ago for just this sort of reason. > > I'm not sure what this says about maturity, you realize read-only access to > CVS also does writes to the repository? There are patches to change this > floating around but it's never been merged "upstream" because there is no > "upstream" maintainer any more. I guess if you want mature software you can't > get any more mature than using orphaned packages. When software reaches perfection, it doesn't need a maintainer. (Bruce ducks for cover.) LOL -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] CVS should die
Heikki Linnakangas wrote: > Interestingly, the subversion repository is 585MB, and the CVS > repository is only 260MB, So apparently this is a limitation of svn2cvs. It uses a lot more space to represent tags and branches than would be required if they had been created in svn directly. Unfortunately it's a hard problem to solve any better than it is. > Markus Bertheau wrote: > >> Here's what the subversion book has to say about that: >> >> http://svnbook.red-bean.com/svnbook-1.1/ch05.html#svn-ch-5-sect-1.2.A >> >> We use svn over ssh and recently switched to fsfs because of the umask >> problem and because read-only access to bdb causes writes to the >> database. Andrew Dunstan <[EMAIL PROTECTED]> writes: > This just reinforces Tom's well-made point about maturity/stability. I rejected > using SVN on another project a few months ago for just this sort of reason. I'm not sure what this says about maturity, you realize read-only access to CVS also does writes to the repository? There are patches to change this floating around but it's never been merged "upstream" because there is no "upstream" maintainer any more. I guess if you want mature software you can't get any more mature than using orphaned packages. -- greg ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Using ALTER TABLESPACE in pg_dump
FYI, we need tablespace_default to control this pg_dump output for a primary key: ALTER TABLE ONLY test2 ADD CONSTRAINT test2_pkey PRIMARY KEY (x); --- Tom Lane wrote: > Philip Warner <[EMAIL PROTECTED]> writes: > > Time is at a serious premium for me at the moment (I have several projects > > all due about now); but I wrote a patch for this a few weeks back, so it > > should not be a lot of work (unless pg_dump has changed in the last couple > > of months). > > If you have a preliminary patch, you could pass it along and I'll finish > it up. > > > Excellent. I assume that anything that can have a tablespace (database, > > schema(?), table and index -- anything else?) should emit a 'set > > default_tablespace="ts"' before creation (and that this will affect > > auto-created indexes as appropriate, whatever that means). > > default_tablespace will affect both tables and auto-created indexes. > But I was under the impression that pg_dump deliberately avoids > auto-creation of indexes... isn't each one split out as an ADD > CONSTRAINT operation? > > Schemas don't have tablespaces anymore. > > regards, tom lane > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Using ALTER TABLESPACE in pg_dump
TODO item removed: * Allow database recovery where tablespaces can't be created When a pg_dump is restored, all tablespaces will attempt to be created in their original locations. If this fails, the user must be able to adjust the restore process. Not done yet, but it will be with SET default_tablespace. I don't think we need "adjust" but rather default to the default tablespace is just fine, and they can pre-create tablespaces in different locations to adjust the restore anyway. Great! --- Philip Warner wrote: > At 06:19 AM 6/11/2004, Tom Lane wrote: > >You had muttered something about wanting to add > >a TOC entry field for this --- do you still want to do the work? > >You can probably get it done faster than I could, but I dunno if you > >have time at the moment. I'd like to get it in over the weekend so > >that we can put out a new beta next week. > > Time is at a serious premium for me at the moment (I have several projects > all due about now); but I wrote a patch for this a few weeks back, so it > should not be a lot of work (unless pg_dump has changed in the last couple > of months). > > I will *try* to get it done by Monday morning your time, and will let you > know if I am going to miss this deadline as soon as I know. > > > >BTW, part of the backend changes was to stop emitting TABLESPACE > >clauses in pg_get_indexdef() and pg_get_constraintdef() output, > >so as of CVS tip pg_dump will in fact fail to restore index tablespaces > >accurately. I assume this is the backend behavior you want, but > >holler if not. > > Excellent. I assume that anything that can have a tablespace (database, > schema(?), table and index -- anything else?) should emit a 'set > default_tablespace="ts"' before creation (and that this will affect > auto-created indexes as appropriate, whatever that means). > > Thanks for all the work. > > > > > Philip Warner| __---_ > Albatross Consulting Pty. Ltd. |/ - \ > (A.B.N. 75 008 659 498) | /(@) __---_ > Tel: (+61) 0500 83 82 81 | _ \ > Fax: (+61) 03 5330 3172 | ___ | > Http://www.rhyme.com.au |/ \| > |---- > PGP key available upon request, | / > and from pgp.mit.edu:11371 |/ > > > ---(end of broadcast)--- > TIP 8: explain analyze is your friend > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Release schedule plans
In talking to people working on various items, I think we should plan for a beta next week once we have completed all the major open 8.0 items. Only the tablespace and win32 lost signals seem major. And, once the beta has been tested for a week, we should start thinking about an 8.0 release candidates. Peter has is thinking of freezing error message strings next week so others can start on translations, and we should start collecting port reports after the next beta too. --- PostgreSQL 8.0 Open Items = Current version at http://candle.pha.pa.us/cgi-bin/pgopenitems. Changes --- * Win32 o Fix shared memory on Win2k terminal server We might be able to just mark this as not supported. o Handle "lost signals" on backend startup (eg. shutdown, config file changes, etc); signals are not possible on startup (Magnus) The problem here is that the postmaster might send signals to a child before the Win32 pipe is created to accept signals. We don't have this problem on unix because we fork and inherit the signal handlers. * Tablespace (Partially completed by Tom) o Add new GUC default_tablespace to control object creation when no explicit TABLESPACE clause exists Remove default tablespace rules and use just the above. Use the GUC variable in pg_dump. TABLESPACE clause should control location of implicit indexes in CREATE TABLE. o Remove tablespace default for databases and schemas Place objects as specified by the TABLESPACE clause or default_tablespace. The database TABLESPACE clause controls only system objects and not other objects created in the database. * adjust bgwriter defaults * synchonize supported encodings and docs * fix gettext support to src/port * update release notes * add external interfaces documentation section -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Using ALTER TABLESPACE in pg_dump
Philip Warner <[EMAIL PROTECTED]> writes: > Time is at a serious premium for me at the moment (I have several projects > all due about now); but I wrote a patch for this a few weeks back, so it > should not be a lot of work (unless pg_dump has changed in the last couple > of months). If you have a preliminary patch, you could pass it along and I'll finish it up. > Excellent. I assume that anything that can have a tablespace (database, > schema(?), table and index -- anything else?) should emit a 'set > default_tablespace="ts"' before creation (and that this will affect > auto-created indexes as appropriate, whatever that means). default_tablespace will affect both tables and auto-created indexes. But I was under the impression that pg_dump deliberately avoids auto-creation of indexes... isn't each one split out as an ADD CONSTRAINT operation? Schemas don't have tablespaces anymore. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Using ALTER TABLESPACE in pg_dump
At 06:19 AM 6/11/2004, Tom Lane wrote: You had muttered something about wanting to add a TOC entry field for this --- do you still want to do the work? You can probably get it done faster than I could, but I dunno if you have time at the moment. I'd like to get it in over the weekend so that we can put out a new beta next week. Time is at a serious premium for me at the moment (I have several projects all due about now); but I wrote a patch for this a few weeks back, so it should not be a lot of work (unless pg_dump has changed in the last couple of months). I will *try* to get it done by Monday morning your time, and will let you know if I am going to miss this deadline as soon as I know. BTW, part of the backend changes was to stop emitting TABLESPACE clauses in pg_get_indexdef() and pg_get_constraintdef() output, so as of CVS tip pg_dump will in fact fail to restore index tablespaces accurately. I assume this is the backend behavior you want, but holler if not. Excellent. I assume that anything that can have a tablespace (database, schema(?), table and index -- anything else?) should emit a 'set default_tablespace="ts"' before creation (and that this will affect auto-created indexes as appropriate, whatever that means). Thanks for all the work. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp.mit.edu:11371 |/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [PATCHES] CVS should die
Markus Bertheau wrote: Ð ÐÑÐ, 05.11.2004, Ð 21:40, Heikki Linnakangas ÐÐÑÐÑ: On Fri, 5 Nov 2004, Travis P wrote: Heikki Linnakangas wrote: Interestingly, the subversion repository is 585MB, and the CVS repository is only 260MB, BDB or FSFS back-end? FSFS seems to require less space. (The BDB backend tends to pre-allocate space though, so maybe there was a big jump, but then growth will slow markedly, so making a comparison for a repository that will continue to grow is difficult.) BDB. Here's what the subversion book has to say about that: http://svnbook.red-bean.com/svnbook-1.1/ch05.html#svn-ch-5-sect-1.2.A We use svn over ssh and recently switched to fsfs because of the umask problem and because read-only access to bdb causes writes to the database. This just reinforces Tom's well-made point about maturity/stability. I rejected using SVN on another project a few months ago for just this sort of reason. cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Documentation on PITR still scarce
Hi, On Fri, Nov 05, 2004 at 10:26:55PM +, Simon Riggs wrote: > That is exactly the situation Timelines are designed to avoid. This > should not have happened. What leads you to think it has? My guess is > that it has not. If it has, its a bug. Hmm. I did the following: - I recovered to one PIT. - I verified that everything was fine. - If I shut down postmaster now and try to recover to another PIT, everything will work fine. (by re-restoring the original backup as you pointed out) However if I: - Shut down postmaster and restart it in normal mode (without a new recovery.conf) and then do some database operations, it seems to overwrite a file from my archive: [...recovery...] LOG: archive recovery complete LOG: database system is ready LOG: archived transaction log file "0002.history" Now we are at timeline 2 I guess. [...normal startup...] LOG: checkpoint record is at 0/22701F8 LOG: redo record is at 0/22701F8; undo record is at 0/0; shutdown TRUE LOG: next transaction ID: 2595; next OID: 231915 LOG: database system is ready [...I do some database action...] LOG: archived transaction log file "00010001" LOG: archived transaction log file "00020002" If I stop postmaster again, wipe out my data/ dir and re-restore the original backup, I can't do any PITRs any more... If I re-install my archive as well, it works again. > > My question is: When I've restored up to the time t_0, how can I go on > > to restore up to another point in time, later than t_0 but before the > > end of my log files. > You need to re-restore the original backup. Ah. Ok. I had the impression that the timelines save me from re-restoring the original files and that I could start off directly from there. Ok, that's why it didn't work out that well ;-) Thanks, Joachim ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] CVS should die
Ð ÐÑÐ, 05.11.2004, Ð 21:40, Heikki Linnakangas ÐÐÑÐÑ: > On Fri, 5 Nov 2004, Travis P wrote: > > > Heikki Linnakangas wrote: > >> Interestingly, the subversion repository is 585MB, and the CVS repository > > is only 260MB, > > > > BDB or FSFS back-end? FSFS seems to require less space. (The BDB backend > > tends to pre-allocate space though, so maybe there was a big jump, but then > > growth will slow markedly, so making a comparison for a repository that will > > continue to grow is difficult.) > > BDB. Here's what the subversion book has to say about that: http://svnbook.red-bean.com/svnbook-1.1/ch05.html#svn-ch-5-sect-1.2.A We use svn over ssh and recently switched to fsfs because of the umask problem and because read-only access to bdb causes writes to the database. -- Markus Bertheau <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Documentation on PITR still scarce
On Fri, 2004-11-05 at 18:10, Joachim Wieland wrote: > My first mistake was that I kept the archive_command setting and thus > overwrote my original archive files. Maybe you should add a note that one > should set it to another directory when recovering. > That is exactly the situation Timelines are designed to avoid. This should not have happened. What leads you to think it has? My guess is that it has not. If it has, its a bug. Manual (rightly) says: "a new timeline does not overwrite the WAL data generated by previous timelines" If you did not follow instruction 22.3.3, step 1, then I might understand your comment and grieve with you. > > > I would encourage you and other users to submit a documentation patch > > yourself if you find better ways of explaining what it's for, how to > > make it work etc.. > > My question is: When I've restored up to the time t_0, how can I go on to > restore up to another point in time, later than t_0 but before the end of my > log files. > Thats a good question. Perhaps one for a FAQ entry. You need to re-restore the original backup. Then specify a recovery.conf with t_1, rather than t_0, where t_1 > t_0. This should then work correctly. Maybe overkill, but that should work. You shouldn't need to specify recovery_target_timeline, because the default is to use the timeline of the original base backup. If it does not, call us. Tell us exactly what you're doing, which backup you are using etc,, When exactly would > I have to specify recovery_target_timeline? Most of the time, never. It is needed mostly to cater for some fairly obscure recovery situations. The default behaviour is good for most things. The timeline concept ensures that you can always re-run a recovery if you think you have done it incorrectly. -- Best Regards, Simon Riggs ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Backend 8.0.0B4 crash on SELECT ...
Patch applied, fixes beta4 for the query with our data. Many thanks again! James Robinson Socialserve.com ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Backend 8.0.0B4 crash on SELECT ...
James Robinson <[EMAIL PROTECTED]> writes:
> I can reproduce a 8.0.0B4 backend crash on OSX 1.3.5.
Fixed; thanks for the test case. If you need the patch right away,
here it is.
regards, tom lane
*** src/backend/optimizer/path/indxpath.c.orig Mon Oct 11 18:56:56 2004
--- src/backend/optimizer/path/indxpath.c Fri Nov 5 15:27:18 2004
***
*** 848,860
foreach(item, restrictinfo_list)
{
- RestrictInfo *restrictinfo = (RestrictInfo *) lfirst(item);
-
- Assert(IsA(restrictinfo, RestrictInfo));
-
/* if any clause implies the predicate, return true */
if (pred_test_recurse_restrict(predicate,
! (Node *)
restrictinfo->clause))
return true;
}
return false;
--- 848,856
foreach(item, restrictinfo_list)
{
/* if any clause implies the predicate, return true */
if (pred_test_recurse_restrict(predicate,
! (Node *)
lfirst(item)))
return true;
}
return false;
***
*** 865,871
* pred_test_recurse_restrict
* Does the "predicate inclusion test" for one element of a predicate
* expression. Here we recursively deal with the possibility that the
! * restriction-list element is itself an AND or OR structure.
*/
static bool
pred_test_recurse_restrict(Expr *predicate, Node *clause)
--- 861,868
* pred_test_recurse_restrict
* Does the "predicate inclusion test" for one element of a predicate
* expression. Here we recursively deal with the possibility that the
! * restriction-list element is itself an AND or OR structure; also,
! * we strip off RestrictInfo nodes to find bare predicate expressions.
*/
static bool
pred_test_recurse_restrict(Expr *predicate, Node *clause)
***
*** 874,880
ListCell *item;
Assert(clause != NULL);
! if (or_clause(clause))
{
items = ((BoolExpr *) clause)->args;
foreach(item, items)
--- 871,884
ListCell *item;
Assert(clause != NULL);
! if (IsA(clause, RestrictInfo))
! {
! RestrictInfo *restrictinfo = (RestrictInfo *) clause;
!
! return pred_test_recurse_restrict(predicate,
!
(Node *) restrictinfo->clause);
! }
! else if (or_clause(clause))
{
items = ((BoolExpr *) clause)->args;
foreach(item, items)
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] CVS should die
On Fri, 5 Nov 2004, Travis P wrote: Heikki Linnakangas wrote: Interestingly, the subversion repository is 585MB, and the CVS repository is only 260MB, BDB or FSFS back-end? FSFS seems to require less space. (The BDB backend tends to pre-allocate space though, so maybe there was a big jump, but then growth will slow markedly, so making a comparison for a repository that will continue to grow is difficult.) BDB. - Heikki ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] CVS should die
Ian Barwick <[EMAIL PROTECTED]> writes: > Aha, glad I'm not the only one. Version 1.1 has a flat-file based > backend which is not prone to BDB-permission-related problems, see: > http://svnbook.red-bean.com/svnbook-1.1/ch05.html#svn-ch-5-sect-1.4 . > It's only been around a few months though and the docs mention > possible issues with scalability. One of the reasons I'm disinclined to move is that none of the proposed alternatives seem especially, um, mature. AFAIK this project has never had CVS lose any data in the eight years we've used it. I'd want a comparable level of trust in any replacement SCM, and I haven't got it. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] unnest
On Fri, 5 Nov 2004, John Hansen wrote: > Does anyone know how to check individual array elements for NULL values? > PG_ARG_ISNULL() seems to return true if ANY array element is null; ex:: > array[1,2,3,null,4,5] Arrays cannot store NULL elements, check your above statement and see that the whole thing is NULL when you introduce a NULL element: # select array[1,2,3,null,4,5]; array --- (1 row) or # select array[1,2,3,null,4,5] IS NULL; ?column? -- t (1 row) Kris Jurka ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [PATCHES] CVS should die
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Heikki Linnakangas wrote: | Have you looked at TortoiseCVS (www.tortoisecvs.org)? I think | TortoiseSVN is a fork of that. I didn't know the existence, is not even listed in the subproject on CVS home page, I discovered TortoiseSVN on the Subversion home page. Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBi9bJ7UpzwH2SGd4RAgraAKCcNLaMJPPjVxfqRQ1yGG2+GssiAACeJFg3 zULofgK2ouUum3wNSjUmG3U= =Bq/a -END PGP SIGNATURE- ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Using ALTER TABLESPACE in pg_dump
Philip, I've just committed the backend changes involved in setting up a "default_tablespace" GUC variable for pg_dump to use, but I didn't do anything to convert pg_dump to doing so instead of using explicit TABLESPACE clauses. You had muttered something about wanting to add a TOC entry field for this --- do you still want to do the work? You can probably get it done faster than I could, but I dunno if you have time at the moment. I'd like to get it in over the weekend so that we can put out a new beta next week. BTW, part of the backend changes was to stop emitting TABLESPACE clauses in pg_get_indexdef() and pg_get_constraintdef() output, so as of CVS tip pg_dump will in fact fail to restore index tablespaces accurately. I assume this is the backend behavior you want, but holler if not. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] CVS should die
On Fri, 5 Nov 2004, Gaetano Mendola wrote: Heikki Linnakangas wrote: FWIW, I think Peter's idea of offering Subversion as an alternative in pgfoundry is very good. Mmm, do you mean createing periodically "snapshot"? Yes this could be a good idea. No, I mean that each project could choose to use either cvs or svn, like they do at Apache. Sure, if you could have both, that would be even better. I like subversion very much, but one thing that troubles me a bit is the number of extra libraries required to compile and run it. Also, is there pre-compiled binaries for all the platforms that PostgreSQL supports? I don't know about the server, but for sure what is more important here is the client side and now that the win environment matter more then before, I have to say that TortoiseSVN ( tortoisesvn.tigris.org ) is much better then WinCVS. True. Looking at the Subversion downloads page, they seem to have binaries for various Linux distributions, FreeBSD, NetBSD and OpenBSD, Solaris, Mac OS X and Win32. According to the supported platforms chapter in pgsql documentation, we also support AIX, BSD/OS, HP-UX, IRIX, Tru64 UNIX, UnixWare, and Linux on Alpha, arm41, m64, MIPS, PPC, S/390 and Sparc. Developers on those platforms would have to compile subversion themselves, or compile pgsql from source tarballs. Have you looked at TortoiseCVS (www.tortoisecvs.org)? I think TortoiseSVN is a fork of that. - Heikki ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [PATCHES] CVS should die
On Fri, 5 Nov 2004 16:22:55 +0100, Peter Eisentraut <[EMAIL PROTECTED]> wrote: > Am Freitag, 5. November 2004 14:13 schrieb Andrew Dunstan: > > I'll repeat an observation I made (more or less) last time we had this > > discussion: the loudest voice in it belongs to those who actually use > > the repository most. When Tom or Bruce or Peter (for example) tell us we > > need to change I'll take lots more notice. > > I'm certainly open to considering subversion, although I have a certain > traumatic experience with it that may or may not be related to the BDB > backend that it uses. Aha, glad I'm not the only one. Version 1.1 has a flat-file based backend which is not prone to BDB-permission-related problems, see: http://svnbook.red-bean.com/svnbook-1.1/ch05.html#svn-ch-5-sect-1.4 . It's only been around a few months though and the docs mention possible issues with scalability. Ian Barwick [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] CVS should die
Heikki Linnakangas wrote: I tried that yesterday out of curiosity. It had problems with 3 files which I removed manually: /pgsql/src/interfaces/perl5/Attic/ApachePg.pl,v /pgsql/src/interfaces/perl5/Attic/test.pl.newstyle,v /pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle.pl,v Otherwise, no problems. Interestingly, the subversion repository is 585MB, and the CVS repository is only 260MB, so apparently Subversion is not very good at compressing the repository. Not that it matters, though. FWIW, I think Peter's idea of offering Subversion as an alternative in pgfoundry is very good. Mmm, do you mean createing periodically "snapshot"? Yes this could be a good idea. I also agree with Andrew's observation that it's really up to the committers since they are the ones that have to work with whatever system we have. That's true, but is really sad see Tom Lane think twice to move a file or not because CVS. I like subversion very much, but one thing that troubles me a bit is the number of extra libraries required to compile and run it. Also, is there pre-compiled binaries for all the platforms that PostgreSQL supports? I don't know about the server, but for sure what is more important here is the client side and now that the win environment matter more then before, I have to say that TortoiseSVN ( tortoisesvn.tigris.org ) is much better then WinCVS. Regards Gaetano Mendola ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Documentation on PITR still scarce
Simon, thanks for that quick and detailed answer. On Fri, Nov 05, 2004 at 05:42:01PM +0100, [EMAIL PROTECTED] wrote: > The sample file gives additional information, just as occurs with > pg_hba.conf. I don't see any need to replicate the sample file in the > docs, do you? Well, maybe one could add just a few lines. pg_hba.conf and postgresql.conf are also documented in the documentation itself. > If you have specific questions, I can answer those. There haven't been > any specific questions asked that aren't covered in the docs or the > sample file, other than these: My first mistake was that I kept the archive_command setting and thus overwrote my original archive files. Maybe you should add a note that one should set it to another directory when recovering. > I would encourage you and other users to submit a documentation patch > yourself if you find better ways of explaining what it's for, how to > make it work etc.. My question is: When I've restored up to the time t_0, how can I go on to restore up to another point in time, later than t_0 but before the end of my log files. I've set another recovery_target_time but it won't work. When exactly would I have to specify recovery_target_timeline? Thanks for your words of wisdom, Joachim ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Backend 8.0.0B4 crash on SELECT ...
I can reproduce a 8.0.0B4 backend crash on OSX 1.3.5. I can't even get
it to analyze the query to get an idea of what the plan it is trying.
What can I do to help diagnose what is going on?
Here's the query:
SELECT unit.id FROM unit WHERE unit.delete = 'f' AND unit.status=2
AND (
(unit.rent >= 100.0 AND unit.rent <= 600.0)
OR (unit.rent_type = 2 AND (
(unit.slidinglow >= 100.0 AND
unit.slidinglow <= 600.0)
OR (unit.slidinglow < 100.0 AND unit.rent
> 600.0)
)))
AND unit.belowHUDFMR = 't' AND unit.features & 1::INT8 =1::INT8;
Basically, it is trying to pull in all available (status=2) rental
(unit.features & 1::INT8 =1::INT8) unit listings between 100 and 600
dollars per month (rent_type 2 is sliding scale rent, which we have to
test for any overlap between the query values and the listing's sliding
scale rent range). This query was produced by a bug in our middleware,
neglecting to include city-limiting clauses (hence then being able to
use an index, specifically "unit_rental_search". But still, pg ought
not to belly up.
It works on 8.0.0B3, with query plan:
Seq Scan on unit (cost=0.00..2480.16 rows=11 width=8) (actual
time=0.242..452.632 rows=2326 loops=1)
Filter: (("delete" = false) AND (status = 2) AND (((rent >=
100::double precision) AND (rent <= 600::double precision)) OR
((rent_type = 2) AND (((slidinglow >= 100::double precision) AND
(slidinglow <= 600::double precision)) OR ((slidinglow < 100::double
precision) AND (rent > 600::double precision) AND (belowhudfmr =
true) AND ((features & 1::bigint) = 1::bigint))
Total runtime: 464.402 ms
(2326 rows returned)
Here's the backtrace ...
#0 0x900429ac in kill ()
#1 0x9009eb1c in abort ()
#2 0x002c10f4 in ExceptionalCondition (conditionName=0x31fd18
"!(Node*)(restrictinfo))->type) == T_RestrictInfo))",
errorType=0x2fca7c "FailedAssertion", fileName=0x31fe60 "indxpath.c",
lineNumber=853) at assert.c:51
#3 0x00186948 in pred_test_restrict_list (predicate=0xc7f444,
restrictinfo_list=0xc8176c) at indxpath.c:853
#4 0x00186890 in pred_test_recurse_pred (predicate=0xc7f444,
restrictinfo_list=0xc8176c) at indxpath.c:834
#5 0x001866cc in pred_test (predicate_list=0xc7f484,
restrictinfo_list=0xc8176c) at indxpath.c:788
#6 0x0018bb60 in best_or_subclause_index (root=0x201ff38,
rel=0x20200e4, subclause=0xc7fef0, retIndexInfo=0xbfffdf8c,
retIndexClauses=0xbfffdf90, retIndexQuals=0xbfffdf94,
retStartupCost=0xbfffdf98, retTotalCost=0xbfffdfa0) at orindxpath.c:379
#7 0x0018b8dc in best_or_subclause_indexes (root=0x201ff38,
rel=0x20200e4, subclauses=0xc7f9ec) at orindxpath.c:264
#8 0x0018b7d8 in create_or_index_paths (root=0x201ff38, rel=0x20200e4)
at orindxpath.c:207
#9 0x001804c0 in set_plain_rel_pathlist (root=0x201ff38,
rel=0x20200e4, rte=0x201ffc4) at allpaths.c:181
#10 0x00180400 in set_base_rel_pathlists (root=0x201ff38) at
allpaths.c:135
#11 0x001801b8 in make_one_rel (root=0x201ff38) at allpaths.c:79
#12 0x00194604 in query_planner (root=0x201ff38, tlist=0xc7b2c4,
tuple_fraction=0, cheapest_path=0xbfffe278, sorted_path=0xbfffe27c) at
planmain.c:154
#13 0x00195b28 in grouping_planner (parse=0x201ff38, tuple_fraction=0)
at planner.c:935
#14 0x00194d6c in subquery_planner (parse=0x201ff38, tuple_fraction=0)
at planner.c:326
#15 0x001948b4 in planner (parse=0x201ff38, isCursor=0 '\0',
cursorOptions=0, boundParams=0x0) at planner.c:129
#16 0x001fdbb8 in pg_plan_query (querytree=0x201ff38, boundParams=0x0)
at postgres.c:647
#17 0x001fdd04 in pg_plan_queries (querytrees=0xc7b24c,
boundParams=0x0, needSnapshot=0 '\0') at postgres.c:715
#18 0x001fe02c in exec_simple_query (query_string=0x201e634 "SELECT
unit.id FROM unit WHERE unit.delete = 'f' AND unit.status=2\nAND
(\n(unit.rent >= 100.0 AND unit.rent <= 600.0)\nOR (unit.rent_type = 2
AND (\n(unit.slidinglow >= 100.0 AND unit.slidinglow <= 600."...) at
postgres.c:874
#19 0x00201a0c in PostgresMain (argc=5, argv=0x2001c74,
username=0x2001c4c "social") at postgres.c:2961
#20 0x001b29e0 in BackendRun (port=0xd00e70) at postmaster.c:2773
#21 0x001b1dfc in BackendStartup (port=0xd00e70) at postmaster.c:2399
#22 0x001af454 in ServerLoop () at postmaster.c:1144
#23 0x001aec64 in PostmasterMain (argc=6, argv=0xd00760) at
postmaster.c:863
#24 0x001539ec in main (argc=6, argv=0xd00760) at main.c:270
Here's the table and index definitions ...
(sorry table is *huge* -- gotta bust it up one of these days).
social=# \d unit
Table "public.unit"
Column | Type | Modifiers
---+--+---
id| bigint | not null
city | bigint |
zipcode | bigint |
building
Re: [HACKERS] [PATCHES] CVS should die
Heikki Linnakangas wrote: On Fri, 5 Nov 2004, Gaetano Mendola wrote: Peter Eisentraut wrote: I'm certainly open to considering subversion, although I have a certain traumatic experience with it that may or may not be related to the BDB backend that it uses. I think for a start it would be nice if pgfoundry could optionally offer subversion (and/or arch) for source control, so that some developer groups and also our system administrators could get some experience with it. I good very start point is see if cvs2svn can handle the postgresql CVS without errors. I tried that yesterday out of curiosity. It had problems with 3 files which I removed manually: /pgsql/src/interfaces/perl5/Attic/ApachePg.pl,v /pgsql/src/interfaces/perl5/Attic/test.pl.newstyle,v /pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle.pl,v Otherwise, no problems. Interestingly, the subversion repository is 585MB, and the CVS repository is only 260MB, so apparently Subversion is not very good at compressing the repository. Not that it matters, though. Subversion, I believe uses SleepycatDb (eg Db4). Thus it isn't flat files like CVS. I also agree with Andrew's observation that it's really up to the committers since they are the ones that have to work with whatever system we have. I like subversion very much, but one thing that troubles me a bit is the number of extra libraries required to compile and run it. Also, is there pre-compiled binaries for all the platforms that PostgreSQL supports? Doubtful. Also there are known issues with Subversion on >FC1 if you are running newer versions of it. You have to compile specially with --without-posix-mutexes (I think that was the flag). Sincerely, Joshua D. Drake - Heikki ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL begin:vcard fn:Joshua Drake n:Drake;Joshua org:Command Prompt, Inc. adr:;;PO Box 215 ;Cascade Locks;OR;97014;US email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 x-mozilla-html:FALSE url:http://www.commandprompt.com version:2.1 end:vcard ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [PATCHES] CVS should die
On Fri, 5 Nov 2004, Gaetano Mendola wrote: Peter Eisentraut wrote: I'm certainly open to considering subversion, although I have a certain traumatic experience with it that may or may not be related to the BDB backend that it uses. I think for a start it would be nice if pgfoundry could optionally offer subversion (and/or arch) for source control, so that some developer groups and also our system administrators could get some experience with it. I good very start point is see if cvs2svn can handle the postgresql CVS without errors. I tried that yesterday out of curiosity. It had problems with 3 files which I removed manually: /pgsql/src/interfaces/perl5/Attic/ApachePg.pl,v /pgsql/src/interfaces/perl5/Attic/test.pl.newstyle,v /pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle.pl,v Otherwise, no problems. Interestingly, the subversion repository is 585MB, and the CVS repository is only 260MB, so apparently Subversion is not very good at compressing the repository. Not that it matters, though. FWIW, I think Peter's idea of offering Subversion as an alternative in pgfoundry is very good. I also agree with Andrew's observation that it's really up to the committers since they are the ones that have to work with whatever system we have. I like subversion very much, but one thing that troubles me a bit is the number of extra libraries required to compile and run it. Also, is there pre-compiled binaries for all the platforms that PostgreSQL supports? - Heikki ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [pgsql-www] pg_autovacuum is nice ... but ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Treat wrote: | On Friday 05 November 2004 07:48, Gaetano Mendola wrote: | |>Neil Conway wrote: |> > Gaetano Mendola wrote: |> >> Right but we can create a new segment and use it too. I don't know how |> >> these segments are used but I used to do it in the past, of course you |> >> have |> >> to create a memory manager that handle not ccntinuous segments. |> > |> > The TelegraphCQ folks have already done this: |> > |> > http://archives.postgresql.org/pgsql-hackers/2003-05/msg00336.php |> > |> > I haven't had a chance to look at the patch, though. |> |>Not bad, however that post is more than one year old. Implement a resizable |>shared memory could really improve postgres performances ? |> | | | Well it certainly would in the sense that we could make the database a little | more self tuning. Yes, but someone ( I do not remember who in this list ) is scared about to be "paged" during the night because the DB is slow because a planned changed autonomously. Unfortunatelly this is the "major" argument ( I do not understand why ) against have a database self tuning. Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBi7qz7UpzwH2SGd4RAtaUAKC2Fij5hA9FF+TxFEGBq72LSGahpgCg4+D3 OTeNKU02YK8OgsJCaODZLn0= =CI+E -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Documentation on PITR still scarce
Joachim Wieland <[EMAIL PROTECTED]> wrote on 05.11.2004, 16:28:38: > Hi there, > > I just wanted to try the PITR feature in beta and got it working somehow. > However I think the docs on this point are still not sufficient enough. > > We have to assume that people will have a closer look at the backup/recovery > documentation as soon as 8.0 ships, because we're kinda heavily advertizing > for 8.0 with the PITR feature. > > In chapter 22, "Backup and Restore", there is not a single example of a > recovery.conf, nor is any of these parameters even mentioned: > > recovery_target_time > recovery_target_xid > recovery_target_timeline > recovery_target_inclusive > > There's an example file in the source tree in backend/access/transam > however. > > So from looking at the docs only it's quite difficult to figure out how it > works in practice. I'd appreciate an example with multiple timelines as > well. > Joachim, Thanks for your interest in PITR and your feedback, which is much appreciated. I'm sorry you've had difficulty. I've read the documentation again, so can vouch for the accuracy of it - it also contains descriptions and advisories that are useful to you. Tom wrote this and my opinion was/is that it is very clear and helpful. Ch22 does specifically point you to the recovery.conf.sample file and describes where to find it. It also tells you the type of information you can specify within it, though you are right in that it doesn't specifically describe each parameter. The sample file gives additional information, just as occurs with pg_hba.conf. I don't see any need to replicate the sample file in the docs, do you? You're not the first person to ask for more docs. It's difficult for me to see how to improve what's there. I'm hampered by understanding it already, if that makes sense. PostgreSQL transactional recovery is very similar to SQL Server, DB2 and Oracle recovery. Obviously, if you're new to the whole subject of transactional recovery then the docs are fairly sparse ... but the docs aren't intended to be a basic course in database transactional recovery. Oracle, for example, cover this in a 3 day course. [My company teaches a short course on PostgreSQL PITR, which is one way that we recoup the cost of developing the software... It's possible for me to arrange courses outside of the UK also, if I get invitations or there is general demand. ...Please excuse OT discussion] I did originally submit some documentation for this to PATCHES, as of mid-August; perhaps that may shed more light. That did contain some descriptive examples, but not worked ones. If you have specific questions, I can answer those. There haven't been any specific questions asked that aren't covered in the docs or the sample file, other than these: > recovery_target_time This is the stopping point mentioned in the docs. > recovery_target_inclusive This parameter allows you to specify whether you should stop AT/ON (i.e. inclusive [<=]) or just before the recovery_target (i.e. exclusive [<]). I'll add a few more lines to the chapter to include those descriptions. I would encourage you and other users to submit a documentation patch yourself if you find better ways of explaining what it's for, how to make it work etc.. Best Regards, Simon Riggs 2nd Quadrant www.2ndquadrant.com ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [pgsql-hackers] fsm_ variables ...
Marc, > Just thought of something after reading and deleting Gavin's email ... > don't we have a 'pgtune' utility, or wasn't that something someone was > working? Âhow many settings, like fsm, can be determined by analzying a > database? Well, Justin started writing something (see pg_autotune on GBorg) but it: a) was in C and b) was based on tuning for the hardware using pgbench and not tuning for the database. I started something doing Q&A in Perl (e.g. "How large do you expect your database to be?") but quickly ran into the issue that I didn't have good mathematical formulas for most settings, just rules-of-thumb (and a perusal of the Performance list for the last month will show that a lot of these rules-of-thumb were based on incorrect assumptions, even if they work). max_fsm_pages actually becomes *very* easy if you're running pg_autovacuum. If your vacuum threshold is set to, for example, 50% updates, then you set max_fsm_pages to about 50% of the pages you have on disk (obtainable from pg_class). However, this has a couple of issues with doing *automatically* without user input: 1) this may require increasing SHMMAX/SHMALL, which requires a reboot on some systems, and root access on all systems; 2) fsm_pages can only be set at server start, so if the user expects the database to grow dramatically over time, FSM needs to be allocated based on the expected maximum size of the DB, not on the current size; Plus there's the fact that some database applications should not use autovacuum and will turn it off. -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [PATCHES] CVS should die
Peter Eisentraut wrote: Am Freitag, 5. November 2004 14:13 schrieb Andrew Dunstan: I'll repeat an observation I made (more or less) last time we had this discussion: the loudest voice in it belongs to those who actually use the repository most. When Tom or Bruce or Peter (for example) tell us we need to change I'll take lots more notice. I'm certainly open to considering subversion, although I have a certain traumatic experience with it that may or may not be related to the BDB backend that it uses. I think for a start it would be nice if pgfoundry could optionally offer subversion (and/or arch) for source control, so that some developer groups and also our system administrators could get some experience with it. I good very start point is see if cvs2svn can handle the postgresql CVS without errors. Regards Gaetano Mendola ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [PATCHES] CVS should die
Peter Eisentraut wrote: I think for a start it would be nice if pgfoundry could optionally offer subversion (and/or arch) for source control, so that some developer groups and also our system administrators could get some experience with it. I agree. We (the pgfoundry admins) will see what can be done - no promises at this stage. cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Documentation on PITR still scarce
Hi there, I just wanted to try the PITR feature in beta and got it working somehow. However I think the docs on this point are still not sufficient enough. We have to assume that people will have a closer look at the backup/recovery documentation as soon as 8.0 ships, because we're kinda heavily advertizing for 8.0 with the PITR feature. In chapter 22, "Backup and Restore", there is not a single example of a recovery.conf, nor is any of these parameters even mentioned: recovery_target_time recovery_target_xid recovery_target_timeline recovery_target_inclusive There's an example file in the source tree in backend/access/transam however. So from looking at the docs only it's quite difficult to figure out how it works in practice. I'd appreciate an example with multiple timelines as well. Joachim ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [PATCHES] CVS should die
Am Freitag, 5. November 2004 14:13 schrieb Andrew Dunstan: > I'll repeat an observation I made (more or less) last time we had this > discussion: the loudest voice in it belongs to those who actually use > the repository most. When Tom or Bruce or Peter (for example) tell us we > need to change I'll take lots more notice. I'm certainly open to considering subversion, although I have a certain traumatic experience with it that may or may not be related to the BDB backend that it uses. I think for a start it would be nice if pgfoundry could optionally offer subversion (and/or arch) for source control, so that some developer groups and also our system administrators could get some experience with it. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] CVS should die
Andrew Dunstan wrote: Neil Conway wrote: Thomas Hallgren wrote: Another compelling reason to use SVN is that one of their long term goals is to use an SQL backend. That is about as far from a "compelling reason" to use a particular version control system as I can imagine. Yeah. I see these considerations as being important: . does tool x do what we need? . is tool x FOSS software? . is the benefit to be gained from moving to tool x worth the pain involved? Duh! Bad wording on my part. I didn't mean that their future use of SQL backend should be a criteria. So "compelling reason" was a bad choice of words. What I meant was, that at some point, we might be able to help the SVN people reach their SQL objective and at the same time push for PostgreSQL as the best choice. If PostgreSQL uses SVN (for the reasons mentioned by Andrew), then some knowledge will be gained and relationships established that might make such a collaboration very natural. Once a PostgreSQL based backend is well tested and very stable, PostgreSQL can make the switch to use it for their own production. From an SVN standpoint, it must be a perfect reference to be able to say "Look, PostgreSQL uses SVN with their own database to store their own code". A better proof of concept doesn't exist! From a PostgreSQL standpoint? Well SVN already have a high amount of users and it is growing rapidly, i.e. the visibility is great. It also struck me that the requirements for an SCM backend store must be especially well handled by an MVCC type system. New data is added frequently but very rarely updated or deleted. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] CVS should die
Neil Conway wrote: Thomas Hallgren wrote: Another compelling reason to use SVN is that one of their long term goals is to use an SQL backend. That is about as far from a "compelling reason" to use a particular version control system as I can imagine. Yeah. I see these considerations as being important: . does tool x do what we need? . is tool x FOSS software? . is the benefit to be gained from moving to tool x worth the pain involved? I'll repeat an observation I made (more or less) last time we had this discussion: the loudest voice in it belongs to those who actually use the repository most. When Tom or Bruce or Peter (for example) tell us we need to change I'll take lots more notice. I have little doubt that we will one day move away from CVS. What we will move to is still open - and I don't yet see a reason to rush into the arms of Subversion. cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [pgsql-www] pg_autovacuum is nice ... but ...
Neil Conway wrote: > Gaetano Mendola wrote: > >> Right but we can create a new segment and use it too. I don't know how >> these segments are used but I used to do it in the past, of course you >> have >> to create a memory manager that handle not ccntinuous segments. > > > The TelegraphCQ folks have already done this: > > http://archives.postgresql.org/pgsql-hackers/2003-05/msg00336.php > > I haven't had a chance to look at the patch, though. Not bad, however that post is more than one year old. Implement a resizable shared memory could really improve postgres performances ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] CVS should die
Thomas Hallgren wrote: Another compelling reason to use SVN is that one of their long term goals is to use an SQL backend. That is about as far from a "compelling reason" to use a particular version control system as I can imagine. -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [pgsql-www] pg_autovacuum is nice ... but ...
Gaetano Mendola wrote: Right but we can create a new segment and use it too. I don't know how these segments are used but I used to do it in the past, of course you have to create a memory manager that handle not ccntinuous segments. The TelegraphCQ folks have already done this: http://archives.postgresql.org/pgsql-hackers/2003-05/msg00336.php I haven't had a chance to look at the patch, though. -Neil ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] CVS should die
Joerg Hessdoerfer wrote: Yes, some do. At least SVN (Subversion) can handle moves very well, and especially it doesn't loose history on moves/renames. SVN holds it's repo entries in a database like 'filesystem', which can be backed by BDB4 or flat files (as of 1.1). SVN has proven to be stable in many OSS projects, and vastly superior over CVS especially in handling multi-GB projects containing binary files in our company. I refrain from listing all the advantages, if interested, have a look for yourself at http://subversion.tigris.org Another compelling reason to use SVN is that one of their long term goals is to use an SQL backend. PostreSQL must be the absolute best choice for that, right? So knowledge of SVN and some future collaboration could perhaps be beneficial for both parties. SVN is also targeted as a CVS replacement and a CVS user will feel very much at home. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [pgsql-www] pg_autovacuum is nice ... but ...
Tom Lane wrote: > "Marc G. Fournier" <[EMAIL PROTECTED]> writes: > >>Moved to -hackers where this belongs :) > > >>On Fri, 5 Nov 2004, Justin Clift wrote: >> >>>Would making max_fsm_relations and max_fsm_pages dynamically update >>>themselves whilst PostgreSQL runs be useful? > > > Possibly, but it isn't happening in the foreseeable future, for the same > reason that we don't auto-update shared_buffers and the other shared > memory sizing parameters: we can't resize shared memory on the fly. Right but we can create a new segment and use it too. I don't know how these segments are used but I used to do it in the past, of course you have to create a memory manager that handle not ccntinuous segments. Of course this only if the effort to do it can justify the man power working on it. Regards Gaetano Mendola ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] unnest
Attached, array -> rows iterator. select * from unnest(array[1,2,3,4,5]); Unnest --- 1 2 3 4 5 5 rows The switch statement could probably be done in a different way, but there doesn't seem to be any good examples of how to return anyitem. If anyone have a better way, please let me know. Does anyone know how to check individual array elements for NULL values? PG_ARG_ISNULL() seems to return true if ANY array element is null; ex:: array[1,2,3,null,4,5] Comments / improvements welcome. Kind regards, John Makefile Description: Makefile unnest.c Description: unnest.c unnest.sql Description: unnest.sql ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] CVS should die (was: Possible make_oidjoins_check ...)
The intuitive understanding of a file is certainly something like "a file called 'baz.c' residing at 'foo/bar/', which contains the BAZ subsystem". Now, when renaming/moving a file such an intuitive understanding is partially lost. UI-wise that's a problem which I haven't ever seen solved well. However, other SCM systems such as Subversion and Continuus (and our to-be-released system Maint, and certainly others) treat files as unique entities unrelated to their path, and thus don't have problems with moves. With regards to modes of working this, it boils down to two methods. One is treating directories as first class entities (opposed to CVS which treats dirs as semi-relevant appendices to real files), versioned to contain a list of children, or simpler yet, to store the parent directory as an meaningful attribute of an object. Both methods have their pros and cons, the latter is somehow simpler to intuitively grasp for people. This doesn't really answer the question of what tool Postgres might change to, but it seems that Subversion is a good tool one should consider. And by golly, CVS is bad. Just consider the cons – having to forbid renames in all but the most necessary cases – it just invites cruft into any project. d. -- David Helgason, Business Development et al., Over the Edge I/S (http://otee.dk) Direct line +45 2620 0663 Main line +45 3264 5049 On 4. nov 2004, at 20:41, Tom Lane wrote: "Marc G. Fournier" <[EMAIL PROTECTED]> writes: why would we lose CVS history? I can physically move the files in /cvsroot to accomplish this ... just tell me what needs to move, and to where ... If you physically move the files, that would retroactively change their placement in back versions, no? ie, it would appear that all previous releases had had 'em under src/tools as well. AFAICS the only nondestructive way to do this is to cvs delete and cvs add, with a commit comment saying where the files were moved from. Then when you are looking at them in CVS, you'd have to navigate over to the previous location (by hand, probably; the commit comment isn't going to automate this for you) and look in the Attic to read the prior CVS history. It's not impossible, certainly, but it discourages moving files for less than the very best of reasons. (I'm rather interested to know whether any other SCMs have a better solution to this problem, and if so what it is. It's not obvious how to do better.) regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] use of IDE's an tools
Dear people, Would you please be so kind to help me with some pointers about which IDE’s you use in order to compile and take a look at the sources? Any comment is appreciated. Regards, Gevik.
