Re: [HACKERS] reviving dead buildfarm animals
Tom Lane wrote: > I notice that five different buildfarm members are about to slide off > the HEAD list for not having reported in within a month. Do we have any > process for pestering their owners to revive them? If the hardware went > south, or there was some other deliberate decision to retire them, > that's fine --- I'm just wondering if the owners don't realize they're > busted. owners ae usually aware since the buildfarm has a feature to notify owners about animals that have not reported in a while. As in the case of zebra/impala/shad and clownfish - I'm fully aware that they are offline and I intend to bring them back soon but some of these animals(which are in fact all on the same VMware host) there have reported rather strange failures in the weeks before like: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=zebra&dt=2007-07-21%2022:25:05 http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=zebra&dt=2007-07-23%2010:25:04 http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=zebra&dt=2007-08-04%2006:25:05 http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=clownfish&dt=2007-08-04%2005:05:34 which I had not yet time to investigate. Maybe we should have a way for buildfarm owners to be able to tag animals and/or builds with a bit of status information in such cases ? Stefan ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] reviving dead buildfarm animals
Tom, > I notice that five different buildfarm members are about to slide off > the HEAD list for not having reported in within a month. Do we have any > process for pestering their owners to revive them? If the hardware went > south, or there was some other deliberate decision to retire them, > that's fine --- I'm just wondering if the owners don't realize they're > busted. Actually, most of these seem to belong to Stefan. Stefan? -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Insufficient attention to security in contrib (mostly)
On Tuesday 28 August 2007 15:38, Tom Lane wrote: > Therefore, I propose the same choices as before for table-size (no > restriction) and database-size (must have CONNECT priv), and this > for tablespace-size: you must have the ability to create tables in > the target tablespace. This could be either an explicit CREATE > grant, or implicit because you are in a DB that has it as the default > tablespace. +1 -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] reviving dead buildfarm animals
I notice that five different buildfarm members are about to slide off the HEAD list for not having reported in within a month. Do we have any process for pestering their owners to revive them? If the hardware went south, or there was some other deliberate decision to retire them, that's fine --- I'm just wondering if the owners don't realize they're busted. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] Contrib modules documentation online
I've been working on converting the current README files for all contrib modules into sgml and add it to the documentation. There are still some fixes to do but i'd like to have some feedback. Indeed, it wasn't agreed to have all if any of the modules together with the core documentation. You can see the docs on [1] in chapter VIII. If you think these could be a good addition, please fill free to comment on how you think sections should be organized to be consistent and easy to read. [1] http://www.nan-tic.com/ftp/pgdoc ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Insufficient attention to security in contrib (mostly)
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> btreefuncs.c is a security hole a mile wide: it will happily dump the >> entire data content of an index for you. It's a good thing this hasn't >> shipped in any release yet. While we could possibly make it look up >> the index's parent table and check if you have SELECT privilege on >> that, it'd be easier just to make the functions demand superuser >> privilege, which is what the rest of the functions in this contrib >> module require. Comments? > Oh dear. Those functions were actually just moved from pgstattuple, and > has been there since 8.2. Better backpatch that to the pgstattuple > functions in 8.2. Done, thanks for the heads-up. > I doubt there's any tools out there using those functions, so > restricting them to superuser only is probably ok. If anyone complains, we could probably knock them down to SELECT privilege, but finding the parent table to apply the select priv check to seems a bit of a pain for the index cases. So I won't bother unless someone does complain. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Insufficient attention to security in contrib (mostly)
We seem to be down to arguing about what permissions are needed to execute the tablespace-size functions. I wrote: > * tablespace-size function requires being owner of current DB. > There is nothing particularly principled about the last choice, but > it's not superuser and not wide open either. > Another option for tablespace-size is that you must have CREATE on the > target tablespace. This is also not real principled, since CREATE is > more of a "write" privilege than a "read" one, but it'd at least give > DBAs some tool to work with. > Also, I don't see anything very wrong with defining USAGE on a > tablespace to mean that you can use the tablespace-size function on it. > AFAIR the overhead for allowing an existing privilege keyword to apply > to another type of object is just about nil --- a couple macro changes. Bruce and I were just chatting about this, and we came up with a couple of fairly good arguments against the first option (that DB owners can use it): * DB owners are supposed to have special permissions within their own DB, but not necessarily system-wide; so being a DB owner shouldn't in itself grant privileges to check tablespace sizes for tablespaces you otherwise have no access to. * Dave was concerned about being able to use tools that connect to postgres or template1 by default. Well, those databases are almost certainly going to be owned by postgres, so for such a tool to be able to use a DB-owner-only function, it's gonna have to be superuser or darn near. So I think I don't like that idea at all. And the third one does seem like overkill. Bruce likes the CREATE-privilege option on the grounds that if you have the right to make tables in a tablespace, you should have the right to find out how big it is. From a security point of view, you can find it out indirectly if you have some idea how big a disk partition it's mounted on: fill up a temp table until you run out of disk space, and subtract. So trying to deny the knowledge seems a bit pointless anyway. Therefore, I propose the same choices as before for table-size (no restriction) and database-size (must have CONNECT priv), and this for tablespace-size: you must have the ability to create tables in the target tablespace. This could be either an explicit CREATE grant, or implicit because you are in a DB that has it as the default tablespace. Comments? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] MSVC build system
Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> Alvaro Herrera wrote: >>> That, or we create the makefiles in a fixed system and keep the >>> Makefiles in CVS (though would be derived files). > >> IIRC, we previously looked into cmake and concluded it supported a lot >> fewer platforms than pgsql. > >> However, if we can go by Alvaros suggestion and keep the makefiles as >> derived files, that could certainly work... > > Not really, as it still disenfranchises developers who don't have or > know how to use cmake (or whatever tool you select). This is not like > bison or flex, which you can avoid learning and still be able to work on > many interesting parts of Postgres. If you can't work with the build > system then you can't even add a new source file, and that's a pretty > crippling restriction. It would require developer education, absoulutely, but it would fix the cross platform problem, which is what I was referring to. > I've never worked with cmake, but the info on their home page sounds > like it would work on all the systems we are interested in. It does look pretty good on that - probably they've fixed the ones that were missing when it was discussed before. Or my memory just sucks, that's also a clear possibility. > I think > the $64 question is whether we can make it sit up and do all the tricks > that are in our Makefiles now. Having never used it, I can't comment on that. > In any case, the conversion cost would > be pretty darn sizable --- not only the effort from a few people to do > the initial conversion, but the distributed costs of all developers > having to learn cmake. I'm not sure we want to go there ... not yet > anyway ... Oh yes, it's a huge change. I think we should go with the current method a bit longer to see how it holds up before making such a decision. //Magnus ---(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: [HACKERS] [COMMITTERS] pgsql: Fix brain fade in DefineIndex(): it was continuing to access the
Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: Tom Lane wrote: This particular issue could be implemented just by adding -DCLOBBER_CACHE_ALWAYS to CFLAGS (or CPPFLAGS if you want to be anal about it). I suppose that no new buildfarm mechanism is required --- someone just needs to set up an animal configured that way, and scheduled to run only maybe once a week or something like that. Ah. Ok. That makes sense. How long does such a regression run usually take? On my x86_64 machine (dual 2.8GHz Xeon EM64T) it's on the order of two or three hours --- I haven't timed it carefully, but somewhere along there. That's just for the core regression tests, I've never tried contrib or PL tests. It should be a separate animal, and not something that an existing one does every-so-often, or we might mistake anything it finds for an irreproducible transient failure. Consistent failures on the same animal will stand out of the noise, though. I tried this on a little P3 I have lying around: [EMAIL PROTECTED] bf]$ ./run_build.pl --test --conf=figeater.conf Mon Aug 27 17:03:55 2007: buildfarm run for figeater:HEAD starting [17:03:55] checking out source ... [17:04:17] checking if build run needed ... [17:04:18] creating vpath build dir pgsql.11834 ... [17:04:18] running configure ... [17:06:06] running make ... [17:31:14] running make check ... [00:43:28] running make contrib ... Branch: HEAD Stage Contrib failed with status 2 Good thing it failed - goodness only knows how long the extra runs would have taken :-) Does someone have a box with lots of grunt that can spare some cycles for a few hours once a week or so? cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] PickSplit method of 2 columns ... error
Has anyone come across this error before? LOG: PickSplit method of 2 columns of index 'asset_position_lines_asset_cubespacetime_idx' doesn't support secondary split This is a multi-column GiST index on an integer and a cube (a data type from the postgres cube extension module). I traced the error to the gistUserPicksplit function in the gistsplit.c file ... I surmise that this method is called whenever a page split is necessary. So, I know when this error occurs, but I don't know why. Thoughts anyone? Cheers, Kevin -- Kevin Neufeld Software Developer Refractions Research Inc. 300-1207 Douglas St. Victoria, B.C., V8W 2E7 Phone: (250) 383-3022 Email: [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Insufficient attention to security in contrib (mostly)
Dave Page <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> * tablespace-size function requires being owner of current DB. > I assume superusers will also be able to use it, not just the actual owner? Right --- it'd be an "ownercheck" call which means that superusers and anyone who's been granted membership in the owning role will succeed, not just exact matches to the role OID. However the privilege-bit alternatives might be easier to manage. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Testing the other tsearch dictionaries
Andrew Dunstan wrote: > Tom Lane wrote: >> >> No, we have the ability to run a contrib module that's already been >> installed. pg_regress cannot assume it has write privileges on >> $SHAREDIR --- consider the "make installcheck" case. > > How big are these files? If small, is there a reason we can't actually > ship them as samples? We do. Currently they have a ".sample" suffix. Admin is supposed to make a copy of them, modify, and save with the right suffix. Tom suggested that we rename them so that they can be used directly. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] FW: was [PERFORM] partitioned table and ORDER BY indexed_field DESC LIMIT 1
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Luke Lonergan wrote:
> Below is a patch against Greenplum Database that fixes the problem.
>
> - Luke
>
> -- Forwarded Message
> From: Luke Lonergan <[EMAIL PROTECTED]>
> Date: Fri, 24 Aug 2007 09:25:53 -0700
> To: Heikki Linnakangas <[EMAIL PROTECTED]>, Anton <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Conversation: [PERFORM] partitioned table and ORDER BY indexed_field DESC
> LIMIT 1
> Subject: Re: [PERFORM] partitioned table and ORDER BY indexed_field DESC
> LIMIT 1
>
> Below is a patch against 8.2.4 (more or less), Heikki can you take a look at
> it?
>
> This enables the use of index scan of a child table by recognizing sort
> order of the append node. Kurt Harriman did the work.
>
> - Luke
>
> Index: cdb-pg/src/backend/optimizer/path/indxpath.c
> ===
> RCS file:
> /data/FISHEYE_REPOSITORIES/greenplum/cvsroot/cdb2/cdb-pg/src/backend/optimiz
> er/path/indxpath.c,v
> diff -u -N -r1.22 -r1.22.2.1
> --- cdb-pg/src/backend/optimizer/path/indxpath.c25 Apr 2007 22:07:21
> -1.22
> +++ cdb-pg/src/backend/optimizer/path/indxpath.c10 Aug 2007 03:41:15
> -1.22.2.1
> @@ -379,8 +379,51 @@
> index_pathkeys = build_index_pathkeys(root, index,
>ForwardScanDirection,
>true);
> -useful_pathkeys = truncate_useless_pathkeys(root, rel,
> -index_pathkeys);
> +/*
> + * CDB: For appendrel child, pathkeys contain Var nodes in
> terms
> + * of the child's baserel. Transform the pathkey list to refer
> to
> + * columns of the appendrel.
> + */
> +if (rel->reloptkind == RELOPT_OTHER_MEMBER_REL)
> +{
> +AppendRelInfo *appinfo = NULL;
> +RelOptInfo *appendrel = NULL;
> +ListCell *appcell;
> +CdbPathLocusnotalocus;
> +
> +/* Find the appendrel of which this baserel is a child. */
> +foreach(appcell, root->append_rel_list)
> +{
> +appinfo = (AppendRelInfo *)lfirst(appcell);
> +if (appinfo->child_relid == rel->relid)
> +break;
> +}
> +Assert(appinfo);
> +appendrel = find_base_rel(root, appinfo->parent_relid);
> +
> +/*
> + * The pathkey list happens to have the same format as the
> + * partitioning key of a Hashed locus, so by disguising it
> + * we can use cdbpathlocus_pull_above_projection() to do
> the
> + * transformation.
> + */
> +CdbPathLocus_MakeHashed(¬alocus, index_pathkeys);
> +notalocus =
> +cdbpathlocus_pull_above_projection(root,
> + notalocus,
> + rel->relids,
> + rel->reltargetlist,
> +
> appendrel->reltargetlist,
> + appendrel->relid);
> +if (CdbPathLocus_IsHashed(notalocus))
> +index_pathkeys = truncate_useless_pathkeys(root,
> appendrel,
> +
> notalocus.partkey);
> +else
> +index_pathkeys = NULL;
> +}
> +
> +useful_pathkeys = truncate_useless_pathkeys(root, rel,
> +index_pathkeys);
> }
> else
> useful_pathkeys = NIL;
> Index: cdb-pg/src/backend/optimizer/path/pathkeys.c
> ===
> RCS file:
> /data/FISHEYE_REPOSITORIES/greenplum/cvsroot/cdb2/cdb-pg/src/backend/optimiz
> er/path/pathkeys.c,v
> diff -u -N -r1.18 -r1.18.2.1
> --- cdb-pg/src/backend/optimizer/path/pathkeys.c30 Apr 2007 05:44:07
> -1.18
> +++ cdb-pg/src/backend/optimizer/path/pathkeys.c10 Aug 2007 03:41:15
> -1.18.2.1
> @@ -1403,55 +1403,53 @@
> {
> PathKeyItem*item;
> Expr *newexpr;
> +AttrNumber targetindex;
>
> Assert(pathkey);
>
> -/* Use constant expr if available. Will be at head of list. */
> -if (CdbPathkeyEqualsConstant(pathkey))
> +/* Find an expr that we can rewrite to use the projected columns. */
> +item = cdbpullup_findPathKeyItemInTargetList(pathkey,
> + relids,
> +
Re: [HACKERS] Insufficient attention to security in contrib (mostly)
Tom Lane wrote: > * no restriction on database-size function *when applied to the current > database* (again, you could look into pg_class); to apply to some other > database, you must have connect privileges. (Actually, on the > assumption that you must have connect privs to current DB, I guess we > could simplify that to connect privs on target DB, full stop.) The latter would be preferrable for pgAdmin which queries database-level info from the maintenance DB (usually postgres). > * tablespace-size function requires being owner of current DB. I assume superusers will also be able to use it, not just the actual owner? /D ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Insufficient attention to security in contrib (mostly)
Josh Berkus <[EMAIL PROTECTED]> writes: > Well, that puts us back in the position of requiring a "read" or "metadata" > permission for tablespaces, or requiring superuser access. The latter is > unpalatable because there are existing tools in the field which work without > superuser access; the former is troublesome because it wouldn't be used for > anything other than the dbsize function, at least not right now. Well, what about something like the following: * no restriction on table-size function (on the grounds that you could look into pg_class) * no restriction on database-size function *when applied to the current database* (again, you could look into pg_class); to apply to some other database, you must have connect privileges. (Actually, on the assumption that you must have connect privs to current DB, I guess we could simplify that to connect privs on target DB, full stop.) * tablespace-size function requires being owner of current DB. There is nothing particularly principled about the last choice, but it's not superuser and not wide open either. Another option for tablespace-size is that you must have CREATE on the target tablespace. This is also not real principled, since CREATE is more of a "write" privilege than a "read" one, but it'd at least give DBAs some tool to work with. Also, I don't see anything very wrong with defining USAGE on a tablespace to mean that you can use the tablespace-size function on it. AFAIR the overhead for allowing an existing privilege keyword to apply to another type of object is just about nil --- a couple macro changes. With any of these three options, the tablespace-size function would change from "allowed to anyone" to "not allowed by default", unless you happened to be the DB owner. Not sure which would be preferable from the point of view of those existing tools you mention. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Insufficient attention to security in contrib (mostly)
Tom, > ... in particular, that restriction seems pretty content-free for most > practical layouts. And it's got interesting security behaviors: > DBA A, by more-or-less innocently allowing some tables in his database B > to be created in tablespace C, might be allowing his unrelated user D to > find out info about some other database E that shares use of C. I'd > like there to have to be some direct, intended connection of D to E > before D can measure E's size ... Well, that puts us back in the position of requiring a "read" or "metadata" permission for tablespaces, or requiring superuser access. The latter is unpalatable because there are existing tools in the field which work without superuser access; the former is troublesome because it wouldn't be used for anything other than the dbsize function, at least not right now. -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Testing the other tsearch dictionaries
Tom Lane wrote: No, we have the ability to run a contrib module that's already been installed. pg_regress cannot assume it has write privileges on $SHAREDIR --- consider the "make installcheck" case. How big are these files? If small, is there a reason we can't actually ship them as samples? cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [GENERAL] Undetected corruption of table files
At 11:48 PM 8/27/2007, Trevor Talbot wrote: On 8/27/07, Jonah H. Harris <[EMAIL PROTECTED]> wrote: > On 8/27/07, Tom Lane <[EMAIL PROTECTED]> wrote: > > that and the lack of evidence that they'd actually gain anything > > I find it somewhat ironic that PostgreSQL strives to be fairly > non-corruptable, yet has no way to detect a corrupted page. The only > reason for not having CRCs is because it will slow down performance... > which is exactly opposite of conventional PostgreSQL wisdom (no > performance trade-off for durability). But how does detecting a corrupted data page gain you any durability? All it means is that the platform underneath screwed up, and you've already *lost* durability. What do you do then? The benefit I see is you get to change the platform underneath earlier than later. Whether that's worth it or not I don't know - real world stats/info would be good. Even my home PATA drives tend to grumble about stuff first before they fail, so it might not be worthwhile doing the extra work. Regards, Link. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Testing the other tsearch dictionaries
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> The difficulty in testing these is that they require configuration >> files, which the regression tests really can't install. (If the >> configuration were all inside the database it wouldn't be such a >> problem, but that's a lost cause for 8.3...) > How about putting the sample config files in contrib/tsearch, and > copying them at "make install"? We have the capability to install > contrib modules at the beginning of regression tests, right? No, we have the ability to run a contrib module that's already been installed. pg_regress cannot assume it has write privileges on $SHAREDIR --- consider the "make installcheck" case. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [GENERAL] One database vs. hundreds?
(On the GENERAL list) Kamil Srot wrote: Kynn Jones wrote: I'm hoping to get some advice on a design question ... ...we use pgsql partitioning for other reasons and it has some of the features you want (data separation, query performance, ...). It can be worth reading: http://www.postgresql.org/docs/8.2/interactive/ddl-partitioning.html I'm not sure the tip is really what the OP is going to need -- I think he has a different problem in mind than that addresses -- but after a quick R of TFM, all I can say is HOLY CR** THAT IS COOL! Postrgresql was amazing when I first started using it at 7.2, and I'm continually astounded by learning new features and techniques made available by the continuing work of the development team. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Testing the other tsearch dictionaries
Tom Lane wrote: > I was a bit unhappy to realize just now that the patch Heikki sent in, > and I reviewed and applied, actually broke dict_synonym. (Modifying a > string tends to modify the result of strlen() ...) While we can't > cover *everything* in the regression tests, it now seems like a bad > idea that the tsearch.sql test has no coverage at all for the ispell, > synonym, or thesaurus templates. Agreed, we really need regression tests for this stuff one way or other. It's a lot of code, not very well tested, and likely to be modified in the future as well. > The difficulty in testing these is that they require configuration > files, which the regression tests really can't install. (If the > configuration were all inside the database it wouldn't be such a > problem, but that's a lost cause for 8.3...) How about putting the sample config files in contrib/tsearch, and copying them at "make install"? We have the capability to install contrib modules at the beginning of regression tests, right? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Diffondete......
On Tue, 28 Aug 2007 10:15:41 +0200 Enrico <[EMAIL PROTECTED]> wrote: > E troppo bello!!! I'm sorry , I apoligize. I select the wrong address. I'm sorry again. -- Enrico Pirozzi Web: http://www.enricopirozzi.info E-Mail: [EMAIL PROTECTED] Skype: sscotty71 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] Diffondete......
E troppo bello!!! http://www.youtube.com/watch?v=VU-VsLpHC3w&mode=related&search= Buona giornata Enrico -- Enrico Pirozzi Web: http://www.enricopirozzi.info E-Mail: [EMAIL PROTECTED] Skype: sscotty71 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Insufficient attention to security in contrib (mostly)
Tom Lane wrote: > btreefuncs.c is a security hole a mile wide: it will happily dump the > entire data content of an index for you. It's a good thing this hasn't > shipped in any release yet. While we could possibly make it look up > the index's parent table and check if you have SELECT privilege on > that, it'd be easier just to make the functions demand superuser > privilege, which is what the rest of the functions in this contrib > module require. Comments? Oh dear. Those functions were actually just moved from pgstattuple, and has been there since 8.2. Better backpatch that to the pgstattuple functions in 8.2. It didn't occur to me to check the permissions on the existing functions while I added the new ones. I doubt there's any tools out there using those functions, so restricting them to superuser only is probably ok. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [GENERAL] LDAP service lookup
Dawid Kuroczko wrote: > [...] and it also would be valuable to > add into pg_service.conf.sample an example ldap:// stanza, so if > person opens the file, she will be enlightened. I like that idea. > And a missing feature. Or rather treat it as feature request. :-) > A "wildcard entry". I would like to set my environment that, > on each client I would put pg_service.conf having two and only > two LDAP servers in it (second one for failover. I think the entry > might look like: > ### wildcard entry: > [%] # or [*] ? > ldap://ldap1.mycompany.com/dc=mycompany,dc=com?uniqueMember?one?(cn=%s) > ldap://ldap2.mycompany.com/dc=mycompany,dc=com?uniqueMember?one?(cn=%s) > > Which, when given: > psql "service = foobarbaz" > ..would query ...?(cn=foobarbaz) This is also worth thinking about ... it would make the code and the pg_service.conf file more complicated, but would definitely be useful if you only use the service file for LDAP lookup. Yours, Laurenz Albe ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [GENERAL] Undetected corruption of table files
Tom Lane wrote: Would it be an option to have a checksum somewhere in each data block that is verified upon read? > >>> That's been proposed before and rejected before. See the >>> archives ... > > I think > the prior discussions were around the same time WAL was initially put > in, and/or when we dropped the WAL CRC width from 64 to 32 bits. > The very measurable overhead of WAL CRCs are the main thing that's > discouraged us from having page CRCs. (Well, that and the lack of > evidence that they'd actually gain anything.) Hmmm - silence me if I'm misunderstanding this, but the most conclusive hit I had was a mail by you: http://archives.postgresql.org/pgsql-general/2001-10/msg01142.php which only got affirmative feedback. Also, there's a TODO entry: - Add optional CRC checksum to heap and index pages This seems to me to be exactly what I wish for... To the best of my knowledge, the most expensive thing in databases today is disk I/O, because CPU speed is increasing faster. Although calculating a checksum upon writing a block to disk will certainly incur CPU overhead, what may have seemed too expensive a couple of years ago could be acceptable today. I understand the argument that it's the task of hardware and OS to see that data don't get corrupted, but it would improve PostgreSQL's reliabitity if it can detect such errors and at least issue a warning. This wouldn't fix the underlying problem, but it would tell you to not overwrite last week's backup tape... Not all databases are on enterprise scale storage systems, and there's also the small possibility of PostgreSQL bugs that could be detected that way. Yours, Laurenz Albe ---(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
