Re: [PATCHES] PITR Archive Recovery plus WIP PITR
On Fri, 2004-07-09 at 12:53, Klaus Naumann wrote: archive_program is provided with a string which contains the target directory. That doesn't really make sense. archive_dest is used for both archive and restore, thats why its set as a separate parameter. Thats the rationale...lets see what others think First of all it introduces the problem you mentioned in the README file (if the directory doesn't exist you loose xlogs). Your example quoted later is the answer use archive_dest = '/mnt/pgarch/' rather than archive_dest = '/mnt/pgarch' which is ambiguous... I thought about checking if this is a dir within the code. But this would make things too unfelxible. Yes, otherwise the check would be there Second, we could make the user responsible of what he's doing by not giving him any target. Remember, the user is specifying the archive_dest also, so the user is completely responsible for how archiving actually occurs. Like you could then do things like: archive_program = 'gzip -d %s | tar rf /dev/nst0 - ' archive_program = 'gzip -d %s | tar rf %s - ' would be how I would use it in the example you give Which adds the file to a tar archive on his tape. If he wants to archive it on disk, let him do it this way: archive_program = 'cp %s /mnt/pgarch/' archive_program = 'cp %s %s' would be the way to specify that... Thank you very much for feedback and your other contributions, Best regards, Simon Riggs ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] fix schema ownership on first connection preliminary patch v2
I have added the v2 version of this patch to the patch queue (attached). I agree with Tom that there is no need for regression tests for this feature and have removed that part of the patch. http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Fabien COELHO wrote: Dear hackers, Please find attached a preliminary patch to fix schema ownership on first connection. It is for comments and advices as I still have doubts about various how-and-where issues, thus it is not submitted to the patch list. (1) It adds a new datisinit attribute to pg_database, which tells whether the database initialization was performed or not. The documentation is updated accordingly. (2) This boolean is tested in postinit.c:ReverifyMyDatabase, and InitializeDatabase is called if necessary. (3) The routine updates pg_database datisinit, as well as pg_namespace ownership and acl stuff. The acl item update part is not yet appropriate: I'd like some answers before going on. (4) Some validation is added. It passes for me. My questions: - is the place for the first connection housekeeping updates appropriate? it seems so from ReverifyMyDatabase comments, but these are only comments. - it is quite convenient to use SPI_* stuff for this very rare updates, but I'm not that confident about the issue... On the other hand, the all-C solution would result in a much longer and less obvious code. - it is unclear to me whether it should be allowed to skip this under some condition, when the database is accessed in debug mode from a standalone postgres for instance? - also I'm wondering how to react (what to do and how to do it) on errors within or under these initialization. For instance, how to be sure that the CurrentUser is reset as expected? Thanks in advance for your answers and comments. Have a nice day. -- Fabien Coelho - [EMAIL PROTECTED] Content-Description: [ Attachment, skipping... ] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- 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 Dear hackers, Please find attached a patch to fix schema ownership on first connection, so that non system schemas reflect the database owner. This revised patch includes fixes after Tom comments on names used in the validation. However, the validation is still there. It is easy to edit it out if required, but I still think that such a test is a good thing. (1) It adds a new datisinit attribute to pg_database, which tells whether the database initialization was performed or not. The documentation is updated accordingly. (2) The datisnit boolean is tested in postinit.c:ReverifyMyDatabase, and InitializeDatabase is called if necessary. (3) The routine updates pg_database datisinit, as well as pg_namespace ownership and acl stuff. I think that the race condition if two backends connect for the first time to the same database is correctly taken care of, as only one backend will update the datisinit flag and then will fix the schema ownership. (4) Some validation is added. Some questions: - is the place for the first connection housekeeping updates appropriate? it seems so from ReverifyMyDatabase comments, but these are only comments. - it is quite convenient to use SPI_* stuff for this very rare updates, but I'm not that confident about the issue... On the other hand, the all-C solution would result in a much longer and less obvious code:-( - it is unclear to me whether it should be allowed to skip this under some condition, when the database is accessed in debug mode from a standalone postgres for instance? - also I'm wondering how to react (what to do and how to do it) on errors within or under these initialization. For instance, how to be sure that the CurrentUser is reset as expected? Thanks in advance for any comments. Have a nice day. -- Fabien. *** ./doc/src/sgml/catalogs.sgml.orig Mon Jun 7 09:08:11 2004 --- ./doc/src/sgml/catalogs.sgmlWed Jun 9 10:26:39 2004 *** *** 1536,1541 --- 1536,1552 /row row + entrystructfielddatisinit/structfield/entry + entrytypebool/type/entry + entry/entry + entry +False when a database is just created but housekeeping initialization +tasks are not performed yet. On the first connection, the initialization +is performed and the boolean is turned to true. + /entry + /row + + row
Re: [PATCHES] Digital Mars C++ - Clients
Christopher Kings-Lynne [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Other products, such as wxWindows, have seen quite a lot of Digital Mars users embrace it once it started supporting DMC++. That is an extremely poor allegory. wxWindows is a GUI TOOLKIT. PostgreSQL is an independent database server. 99.999% of our windows installations will be from the binary that we will be distributing. There seem to be enough developers working with the source to keep this newsgroup busy. g ---(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: [PATCHES] [PATCH] s_lock support for win32
Bruce Momjian [EMAIL PROTECTED] writes: Manfred Spraul wrote: But what about my libpq patch? Races in the library startup just ask for corruptions. Yes, I saw the thread locking patch and will be applying that soon. Has this been agreed to by the win32-hackers list? My recollection is that there was still considerable disagreement about the appropriate way to deal with this issue. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [PATCH] s_lock support for win32
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Manfred Spraul wrote: But what about my libpq patch? Races in the library startup just ask for corruptions. Yes, I saw the thread locking patch and will be applying that soon. Has this been agreed to by the win32-hackers list? My recollection is that there was still considerable disagreement about the appropriate way to deal with this issue. Yes, we resolved that by doing proper locking (3 weeks ago), but it turns out the code wasn't 100% proper and this fixes it. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] PgSQL 7.4.2 - NaN on Tru64 UNIX
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Nikola Milutinovic wrote: Hi guys. I have just had some problems resolved while building PostgreSQL 7.4.2 on Tru64 UNIX 5.1B. File ./src/backend/utils/adt/float.c uses NAN on two spots. It ahs a fall-back definition of NAN as: #define NAN 0.0/0.0 This compiles on Tru64 4.0D (the compiler swallows it), but fails on Tru64 UNIX 5.1B. Both basic CC and DTK Compaq CC break on that file complaining on that constant evaluation. The best way to solve it is to use system definition of Infinity Constants. This definition is best placed in src/include/port/osf1.h This will work on both 5.1B and 4.0D. This is the patch: Papa-Legba:/home/r/root/5.1/postgresql-7.4.2# diff -c src/include/port/osf.h_ORIG src/include/port/osf.h *** src/include/port/osf.h_ORIG Sun May 16 14:14:22 2004 --- src/include/port/osf.h Sun May 16 14:17:57 2004 *** *** 5,7 --- 5,17 /*typedef msemaphore slock_t;*/ #include alpha/builtins.h typedef volatile long slock_t; + + /* + * This is for NaN (Not a Number) definition. + * Note that general definition in PostgreSQL is not type specific, IOW, + * PgSQL's definition can be used in all floating point contexts. The + * definition given here is for double NaN, since all sources using it + * are using it in double float context. + */ + #include nan.h + #define NAN DBL_INFINITY The compilation has went smoothly, I'll try to run regression tests. Will let you know if something fails. Nix. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Digital Mars C++ - Clients
Stephan Szabo [EMAIL PROTECTED] writes: I'm not sure this is necessarily the right way to approach the patch in the first place. It might be better to make a port file with a popen/pclose implementation (even if it simply acts as a failed open and does nothing on close). This gets into maintenance issues as well. The patch as is basically requires that anyone who is modifying psql know and take care to wrap popen/pclose calls. I'm not sure that it's sufficiently maintainable at the moment without DMC users around to keep it honest. I think Stephan is dead on here ... the patch as given is not maintainable. Even if there were enough DMC users around to catch errors of this sort (a fact not in evidence), it's generally impolite for platforms to expect everyone else to cope with their limitations. A platform-specific coding of popen/pclose sounds much better. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
