Re: [PATCHES] Bug in WAL backup documentation
On Sun, Nov 05, 2006 at 11:49:36 -0500, Tom Lane [EMAIL PROTECTED] wrote: As already discussed upthread, anyone who wants the path can get it from `pwd` or local equivalent --- and that mechanism is robust (as long as the directory move doesn't happen while any particular instance of the script is running). I don't see why we should go out of our way to provide a bad substitute for pwd. I think you also still need read access to the intervening directories. If the command works by walking up and matching inode numbers with names, then it will break if it can't read the names. (For example /bin/pwd breaks when it can't read a parent directories filenames.) ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [HACKERS] Performance testing of COPY (SELECT) TO
On Mon, Aug 28, 2006 at 19:35:11 +0200, Zoltan Boszormenyi [EMAIL PROTECTED] wrote: (BTW, is there anyone as high-ranking as them, or the committee is a duumvirate? :-) ) There is a group referred to as core that is the final arbitrator of things. Tom and Bruce are both members of this group. Tom and Bruce tend to be the most visibly active committers for getting patches committed for people that can't do it themselves. So you will see them speak up more than others on the patches list. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT
On Fri, Jan 06, 2006 at 19:11:27 +0200, Marko Kreen [EMAIL PROTECTED] wrote: On 1/6/06, Bruce Momjian pgman@candle.pha.pa.us wrote: Considering there's no currval() without nextval(), what point is disallowing currval() when user is able to call nextval()? I rather want to allow nextval/currval and disable setval as it allows regular user to DoS the database. What I was thinking with this, is that you might allow someone the ability to insert records into a table which would make use of nextval, but not allow them to run nextval directly. But after inserting a record allow them to use currval to see what value was assigned. People could still mess with things by doing INSERTs and aborting the transaction, so this may not be the best example for why you would want this. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT
On Thu, Jan 05, 2006 at 11:44:24 -0800, Josh Berkus josh@agliodbs.com wrote: Bruce, Tom, The permissions for a sequence aren't the same as they are for a table. We've sort of ignored the point to date, but if we're going to add special syntax for granting on a sequence, I don't think we should continue to ignore it. Uh, how are they different? You mean just UPDATE and none of the others do anything? Yes, it would be nice to have real permissions for sequences, specifically USE (which allows nextval() and currval()) and UPDATE (which would allow setval() ). However, I don't know that the added functionality would justify breaking backwards-compatibility. It might be nice to split nextval and currval access as well. nextval access corresponds to INSERT and currval access to SELECT. ---(end of broadcast)--- TIP 1: 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] CRC32 function
On Thu, Aug 25, 2005 at 16:14:04 -0400, Bruce Momjian pgman@candle.pha.pa.us wrote: Ilia Kantor wrote: Both backend and users may have a nice use of the function. Nice and fast hashing when one doesn't need encryption. We already have MD5 encryption in the server. Why would someone want CRC32? Lower CPU utiliization. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] CRC32 function
On Thu, Aug 25, 2005 at 18:44:13 -0400, Tom Lane [EMAIL PROTECTED] wrote: Bruno Wolff III [EMAIL PROTECTED] writes: Bruce Momjian pgman@candle.pha.pa.us wrote: We already have MD5 encryption in the server. Why would someone want CRC32? Lower CPU utiliization. Like Bruce, I don't really think there is demand for such a function. But if we were going to offer it, it at least ought to use the existing implementation in pg_crc.c, instead of duplicating code yet again. Maybe I should have elaborated. I was just responding directly to Bruce's question. I doubt the CPU usage is a big deal in typical use and that that the already available cryptographic hashes have advantages such that I don't expect many people to use CRC32. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [patch 0/2] Add Fortuna PRNG to pgcrypto
On Fri, Jul 08, 2005 at 20:54:40 +0300, Marko Kreen marko@l-t.ee wrote: The idea is to initially seed Fortuna with randomness from system and later feed SHA1 of user data into it too. Just to keep it from degenerating into pure PRNG. How is fortuna getting entropy? Wouldn't this be better placed in the OS as the source of /dev/urandom rather than as part of Postgres? ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [patch 0/2] Add Fortuna PRNG to pgcrypto
On Fri, Jul 08, 2005 at 23:03:49 +0300, Marko Kreen marko@l-t.ee wrote: Well, those OS'es that already have urandom/random, don't need it. And those that don't - I really don't feel responsibility to write one... But fortuna is essentially a high quality /dev/urandom. It doesn't make seem to much sense to implement it on top on /dev/urandom. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] thousands comma numeric formatting in psql
On Tue, Jun 21, 2005 at 08:42:16 +0300, Eugen Nedelcu [EMAIL PROTECTED] wrote: One solution to deal with this is to use to_char function, but for complex selects against multiple tables it's not a good option. Why not? You only have to apply it to the output expressions that need it. Note that if you output numbers like this, you also need to be able to read them back in. I don't think adding complexity for doing that is worth not having to add a few to_char calls in your select queries. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] thousands comma numeric formatting in psql
On Tue, Jun 21, 2005 at 16:03:43 +0300, Eugen Nedelcu [EMAIL PROTECTED] wrote: This is a patch for psql client and not for the backend. It's role is to output numbers to screen in easy readable form (2,345,675,454,543 is much easier to read then 2345675454543.456). I think graphical clients like pgAdmin or phppgadmin have a way to do this. I don't know this for sure but I will investigate it. I did miss that this was a psql only feature. I still don't see a great need, but it isn't going to cause a problem for copy or pg_dump that way. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] default database creation with initdb
On Sat, Jun 18, 2005 at 09:27:49 -0400, Robert Treat [EMAIL PROTECTED] wrote: On Saturday 18 June 2005 04:55, Andreas Pflug wrote: Magnus Hagander wrote: Umm. Tiny item, but your comment still refers to the database as pg_system ;-) What is the purpose of this database? A generalized, shared resource for tool makers and add-on packages to store information in PostgreSQL, or a working database that is usable (and to be used) out of the box for new users? I really don't think we want the latter... I can see users connecting via psql and then playing around with different add/create type statements. It is all too common a question from newbies... does postgresql have a default database to get started with? They'll see this database and begin creating schema and using this as thier main database, and I think we ought to avoid that. If people don't like pg_system, pg_addons seem like a much safer name to go with imho. I believe the intention is that things that need to connect to some database to do their work (e.g. psql -l, createuser) will connect to that database. createdb will still connect to template1, but now will be less likely to have a conflict with another user being connected to template1 at the same time. I didn't check the patch to see if the behavior of the psql -l and createuser were changed or if just the initdb behavior was changed. I don't think it will be a big deal if people put stuff in that database. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] O_DIRECT for WAL writes
On Fri, Jun 03, 2005 at 09:43:13 -0700, Mary Edie Meredith [EMAIL PROTECTED] wrote: Looking at this from another angle, is there really any way that you can say a write is truly guaranteed in the event of a failure? I think in the end to be safe, you cannot. That's why (and I'm not telling you anything new) there is no substitute for backups and log archiving for databases. Databases must be able to recognize the last _good transaction logged and roll forward to that from the backup (including detecting partial writes to the log). I'm sure the PostgreSQL community has worked hard to do the equivalent of that within the PostgreSQL architecture. Some assumptions are made about what order blocks are written to the disk. If these assumptions are not true, you may not be able to recover using the WAL log and have to resort to falling back to your last consistant snapshot. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Updated COPY CSV patch
On Tue, Apr 13, 2004 at 06:58:24 -0400, Andrew Dunstan [EMAIL PROTECTED] wrote: One area that we should think about as an enhancement is NOT NULL fields. As it stands now, we will get what we normally get when we try to insert a null into a NOT NULL field, namely an error. If the field has a simple literal default we could force that. And in the special case of text/varchar fields, it would be reasonable to force an empty string even if no default is set. There isn't a nice easy answer, I'm afraid. We shouldn't hold up putting this in on that account, but handling this better is certainly a TODO. If you try to insert NULLs into a nonnull field you should get an error. If you have unquoted empty strings, and are not using the empty string as the NULL marker, then you can just not set the NULL code to be the empty string. If you need to turn this on and off by column, then perhaps it would be better to do that externally. As for setting default values, I think that is a good idea. I suggested a while back. There could be another keyword, DEFAULT, on the COPY FROM command that is used to define a code that will be replaced by the default value (or NULL if there is no default for a column) similar to how the NULL code is replaced by NULL. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] COPY for CSV documentation
On Mon, Apr 12, 2004 at 02:26:14 -0400, Andrew Dunstan [EMAIL PROTECTED] wrote: a few points: . in CSV mode, NULL should default to '' - that was in what I sent in. Postgres normally treats an empty string as an empty string. Are you sure you really want it to be treated as a NULL by default in this one place? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] COPY for CSV documentation
On Mon, Apr 12, 2004 at 10:30:22 -0400, Bruce Momjian [EMAIL PROTECTED] wrote: It is my understanding that \N is a valid column value (no backslash escape in CSV, right?), so we can't use it for NULL. The only thing I can think of is for NULL to be: ,, (no quotes) and a zero-length string to be: ,, How do most applications handle those two cases? If they accept either, can we use that so we can read our own CSV files without losing the NULL specification? I think the above are going to be treated as equvialent by most CSV parsers. There doesn't seem to be a standard for CSV. From what I found describing it, there isn't any feature for distinguishing NULLs from empty strings. So whatever gets done is going to be application specific. ---(end of broadcast)--- TIP 8: explain analyze is your friend
