Re: [HACKERS] Statistical Lacunae in Interval type
David Fetter wrote: > I just ran across this, and was wondering whether it's worth a > back-patch. New features are not back-patched. > The interval type has an aggregate for average (AVG), > but not one for standard deviation (STDDEV) or variance (VARIANCE). > > Is this a bug? No, it's a missing feature. :-) > Is there some problem with defining variance over > intervals? If all the operations that are used as part of the calculation of stddev are available for intervals, then I don't see one. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Status report
Justin Clift wrote: Bruce Momjian wrote: If you get full control of PostgreSQL, you can dictate what will happen. Until then, I will follow the community consensus, which may or may not match your opinion. Um, let's take the time to get the features in, otherwise we'll be waiting another year (roughly) to get PITR and others out to end users. We can't affort not having PITR or NT in 7.5; we announced it already everywhere. But it's not a real problem if we need some more time to release, we always tell "we don't release according to a release plan, but if things are mature". Regards, Andreas ---(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] patch for allowing multiple -t options to pg_dump
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scott Marlowe wrote: | On Sun, 2004-07-11 at 19:00, Bruce Momjian wrote: | |>Andreas Joseph Krogh wrote: |>[ PGP not available, raw data follows ] |> |>>-BEGIN PGP SIGNED MESSAGE- |>>Hash: SHA1 |>> |>>Hi, I've prepared a patch(against CVS HEAD of today) to pg_dump.c to |>>make pg_dump understand multiple -t options for dumping multiple tables |>>in one command. |>>Eks: |>>pg_dump -t table1 -t table2 -t table3 |>> |>>The patch is here: |>>http://home.officenet.no/~andreak/pg_dump.patch |>> |>>Any comments, flames? |>> |>>Is it too late for it to make it into 7.5? I submitted a patch against |>>7.4 a while ago, but was then told it had to wait until 7.5, and, well, |>>now it's 7.5-time:-) |> |>Uh, I see your patch posted on July 6. Is that the one? We started a |>feature freeze on July 1. | | | Is this a feature or a bug fix? I'd say it's more of a bug fix, since | multiple -t switches seems like an obvious thing to support. Now, if we | were adding wild card matching that would seem like an enhancement. I | can't imagine this patch is more than a dozen lines or so. And I can't | imagine it impacting anything else going on right now. I agree that it's more a bugfix than a feature, and yes, it's not a big patch, so it should be fairy safe. - -- Andreas Joseph Krogh <[EMAIL PROTECTED]> Senior Software Developer / Manager gpg public_key: http://dev.officenet.no/~andreak/public_key.asc - +-+ OfficeNet AS| - a tool should do one job, and do it well. | Hoffsveien 17 | | PO. Box 425 Skøyen | | 0213 Oslo | | NORWAY | | Phone : +47 22 13 01 00 | | Direct: +47 22 13 10 03 | | Mobile: +47 909 56 963 | | - +-+ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA8kmmUopImDh2gfQRAm3pAJ90/AXtxeZGPJpk7uEb7d6qsOCGtwCeK0+y vbZ1YMuhnxdcr4w10EKLN9A= =uSAs -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: [Re] Re: [HACKERS] PREPARE and transactions
On Sun, Jul 11, 2004 at 07:23:13PM -0400, Bruce Momjian wrote: > > Were are we on deciding how PREPARE in aborted transactions should behave? Haven't gotten much further than agreeing that current behaviour is quirky. It does not follow that we agree it's bad. I would say most of us agree that it may have been a little rash to unify prepared statements on the fe/be protocol level and those on the SQL level into the same namespace. One piece of progress we did make is a layercake model to facilitate discussion of the fe/be protocol and other interface issues: SQL session - tables & queries and stuff Interchance - dat a representation, encodings &c. Protocol - bind/prepare/execute, portals &c. Connection - sockets and such Some observations we can make based on this: - Transactionality plays at the upper three levels. Should the upper level be exclusively transactional? In other words, should we have an ACID SQL implementation? This issue can in principle be separated from any choices at the lower levels, but currently prepared statements and cursors cross the divide. - Session variables see significant use at the Interchange level, yet are manipulated at the SQL level. This means they're transactional although some would like to see them work nontransactionally. - To make things easier we've lumped everything between the client socket and client-side business logic under the term "middleware." - Some middleware such as language drivers hide only the lowest levels but leave SQL alone (JDBC), or hide only the Protocol level, expose the Connection level, and leave everything else to further client software (libpq), and some hides the lower 2 levels, gets involved in the upper level, but doesn't touch the Interchange level (libpqxx). This may influence how easy it is for the middleware to support transactionality for various features, and where we would like to have it and where we wouldn't. Having nontransactional behaviour is convenient for middleware that uses prepared statements and is not transaction-aware. - There is also a layercake at the client side. Middleware's naming choices for e.g. prepared statements must not clash with those of other layers, and this currently requires specific documentation. I would describe that as another namespace problem. Basically the whole problem probably wouldn't be with us if prepared statements on the SQL level were different from the identically-named concept in the fe/be protocol. Jeroen ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [subxacts] Aborting a function
On 07/10/04:27/6, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > (We could talk about exception support in plpgsql or other language
> > handlers but I don't think this is going to happen for 7.5.)
>
> Au contraire ... I think it *must* happen, and indeed that
> subtransaction support in plpgsql is not different from exceptions.
> Per Honza Pazdziora's recent post:
>
> >> The syntax of handling exceptions is (in PL/SQL):
> >>
> >>BEGIN
> >>some code, for example a bunch of SQL commands;
> >>EXCEPTION
> >>WHEN nameofexception THEN
> >>handle the exception, maybe ROLLBACK;
> >>END;
Shortly, does that snippet imply that an extension author will have the
ability to catch and "resolve" ERRORs, and have access to the error data?
[I was planning on bringing this up at a later time, but this thread seems
directly related to a feature that I would like plpy to have.]
Does the above snippet mean what I think it means? That is, will one be able to
trap ERRORs without being required to raise it like one would do now
--siglongjmp'ing Warn_restart, and such. Will one have access to the currently
static ErrorData in elog.c? This would seem necessary if one is going to
be able to test anything about exception that occurred('nameofexception').
This is what I would hope from looking at the above snippet of PL/PgSQL code,
but I hope such a feature would be available independent of subxacts(tho, not
within the context of a PL/PgSQL procedure, I suppose).
Putting it in the context of PL/Py:
try:
r = Postgres.Relation("primary_source")
except Postgres.Error:
r = someOtherObjectTheProvidesTheNecessaryInfoWithACompatibleInterface
# --- or, perhaps ---
raise MyDBAppException(
"More appropriate error message than 'failed to
open primary_source', with description about how to resolve error
specific the DB application/template a user might be using",
detail="some good details"
hint="a good hint"
)
...
In Python it is quite common to do something like that, rather than testing
ahead of the action.
I've whined about this a couple times on #postgresql, both times the responses
raised the same good question, "What would you do with the error when you get
it?". I think that the best response to that is that depends on the user's
application, and the context of his/her usage.
It should also be noted that I have, with _apparent_ success, caught an
ERROR, and continued on my merry way without raising it. To say the
least, it was done without elegance as the client is likely to get
the ERROR message from errstart. That and the fact that I cannot access the
static ErrorData is what kept me from keeping that functionality.
(I basically stored and restored the state of a couple globals which may have
been changed by an elog(ERROR), ie, InError)
--
Regards,
James William Pye
pgpyI2cKg2mlM.pgp
Description: PGP signature
Re: [HACKERS] Statistical Lacunae in Interval type
David Fetter <[EMAIL PROTECTED]> writes: > I just ran across this, and was wondering whether it's worth a > back-patch. The interval type has an aggregate for average (AVG), but > not one for standard deviation (STDDEV) or variance (VARIANCE). AFAICS, stddev/variance require the concept of multiplying two input values together (square, and also square root, are in the formulas). I don't know what it means to multiply two intervals --- there's no such operator in Postgres, anyway. You could possibly approximate the behavior you want with something like stddev(extract(epoch from interval_col)) which mashes the intervals down to seconds. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Statistical Lacunae in Interval type
Tom Lane wrote: > AFAICS, stddev/variance require the concept of multiplying two input > values together (square, and also square root, are in the formulas). > I don't know what it means to multiply two intervals --- there's no > such operator in Postgres, anyway. The problem is not much different than recording temperature measurements in a numeric column and then taking the standard deviation. Kelvin squared does not make much sense, but it's only an intermediate quantity. The problem is that an interval datum already implies the units, so in order to allow interval * interval we would have to add a new type "interval squared", which would probably be considered to be a bit foolish. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Statistical Lacunae in Interval type
Peter Eisentraut <[EMAIL PROTECTED]> writes: > The problem is that an interval datum already implies the units, so in > order to allow interval * interval we would have to add a new type > "interval squared", which would probably be considered to be a bit > foolish. Not only foolish but complicated. Remember that interval internally is "N months plus X seconds" (where N is integral but X needn't be). To avoid losing information, a product datatype would have to look something like "N months-squared plus X months-seconds plus Y seconds-squared", which offers no intuition whatever about how to operate on it. I doubt there's even a unique way to define square-rooting this. Add on top the fact that we really need to change interval to be "M months plus N days plus X seconds" to solve the ever-popular daylight-savings-transition issues, and a product datatype would get out of hand altogether. When I said "mash it down to seconds first", I was speaking very literally... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Statistical Lacunae in Interval type
On Mon, Jul 12, 2004 at 11:10:34AM -0400, Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > The problem is that an interval datum already implies the units, > > so in order to allow interval * interval we would have to add a > > new type "interval squared", which would probably be considered to > > be a bit foolish. > > Not only foolish but complicated. Remember that interval internally > is "N months plus X seconds" (where N is integral but X needn't be). > To avoid losing information, a product datatype would have to look > something like "N months-squared plus X months-seconds plus Y > seconds-squared", which offers no intuition whatever about how to > operate on it. I doubt there's even a unique way to define > square-rooting this. That's kinda what I was afraid of. If an interval were defined internally as a unique number of seconds, it would be easy. > Add on top the fact that we really need to change interval to be "M > months plus N days plus X seconds" to solve the ever-popular > daylight-savings-transition issues, and a product datatype would get > out of hand altogether. Yeah. > When I said "mash it down to seconds first", I was speaking very > literally... OK. So it looks like (oddly) interval can have a std. deviation, which is measured in seconds, but not a variance. Is that pretty close? Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Beta date
Our current release schedule is: o apply most oustanding patches this week o take two weeks to finalize open issues o beta August 1 -- 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
[HACKERS] [subxacts] Open nested xact items
List of open nested transactions items. Implement named savepoint syntax, with SQL2003 semantics. Work in progress, foundations done. Needs polishing and testing. Fix issues with cursors. Need to mess with open portals at subxact abort. Allow support for exceptions in functions. Allow registering at-subxact-abort callback? Report transaction nesting level to client. Use a non-GUC ParameterStatus message when the nesting is changed? Comments need work (xact.c and htup.h mainly) Make TransactionIdIsInProgress more efficient. Make a subxid cache and a negative xid cache. Short-circuit using RecentGlobalXmin. Bruce: use a bit in tuple header to signal Xmin/Xmax was written on a subxact? Marking children transactions as committed during transaction commit may be wrong (or too costly to check). Prove/profile. Revert the change? Make Catcache state saving more efficient. Maybe relcache too? Correctly handle large objects. WIP. Write documentation for the new syntax in SQL reference and in the tutorial. Write regression tests. Open questions from Tom: Need to think about pg_locks view now that single backend may have multiple XIDs --- do we need more info in pg_locks?? I wonder whether we shouldn't rename TopTransactionContext. Any existing references to TopTransactionContext are more than likely wrong given the way its semantics have been subtly changed. (I checked everything in standard distro, but what about external PLs and user-written fns ...) Check order of operations in subtransaction start/commit/abort. Is there a good reason not to be fully consistent with top-level cases? Document where there is. Couldn't we simplify IsSubTransaction into a check on nest depth? plpgsql: is it okay for simple_eval_estate to live throughout the toplevel xact? subxact abort might release resources that are still ref'd in estate, leading to trouble at top commit? Maybe we need one simple_eval_estate per subxact ... We should think about whether there's not a better way for VACUUM FULL to work than session locks now. xact_redo seems a bit optimistic about alignment? Might be OK, not sure. Need to test on alignment-picky box such as HP... Not sure about logic for OnCommitActions, take another look. DONE/CANCELED logic for triggers looks fishy too, particularly test at line 1946ff (2003ff in my committed patch) Most if not all of the uses of SubTransXidsHaveCommonAncestor should probably go away, since it's rare to apply this test only once. Better to fold the probe XID to its toplevel parent once instead of N times. More generally, we have replaced cheap tests with expensive ones in many places in tqual.c; this needs more thought. Note TransactionIdIsCurrentTransactionId has become much looser. Need to look at its uses ... (seems okay in a quick look but I'm not totally convinced...) *why* can't you make a subtrans read only? (Probably just temporary until GUC rollback is worked on?) See assign_transaction_read_only. Need to make sure you can't loosen the constraint, though (no r/w subxact of r/o parent), so we do need an assign hook to check that. Seems like subtrans could/should be truncated much sooner than clog. What we need here is a short-circuit test to avoid pursuing parent of a subtrans older than, say, RecentGlobalXmin. If it isn't yet marked committed then it must be aborted, no need to look at parent. But think about race conditions and order of marking subxacts during commit/abort. Don't much like using lfirst_int etc for XIDs ... probably should at least invent some macros lfirst_xid and so on. Stuff that still needs examination: localbuf refcounts (decide if we are changing bufmgr behavior, first) EOXact callbacks API needs extension namespace (temp namespace cleanup) files password file SetReindexProcessing -- Alvaro Herrera () It does it in a really, really complicated way why does it need to be complicated? Because it's MakeMaker. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Is "trust" really a good default?
Is it really such a good idea to have "trust" authentication enabled for localhost (TCP/IP and Unix sockets) by default? Since this pretty much means that anybody with shell access on the server (which depending on the situation can be only dba people, or a whole lot of other people as well) can do anything they want with the database, regardless of permissions? In some situations this is certainly safe (say a dedicated db server which only trusted dba:s have access to). In others it's very definitly not (say a shared hosting machine with hundreds of users). And even in the first case, it provides a really simple way to get around any auditing that is set up. Wouldn't it be safer if you had to explicitly ask for this level if you really know what you're doing, and default to using password auth (and then probably have initdb require a superuser password to be specified)? //Magnus ---(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] Is "trust" really a good default?
"Magnus Hagander" <[EMAIL PROTECTED]> writes: > Is it really such a good idea to have "trust" authentication enabled for > localhost (TCP/IP and Unix sockets) by default? No, but none of the others are better. See previous discussions in the archives. I don't think the situation has changed any since the last time we hashed this out. regards, tom lane ---(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] Is "trust" really a good default?
Tom Lane wrote: > "Magnus Hagander" <[EMAIL PROTECTED]> writes: > > Is it really such a good idea to have "trust" authentication enabled for > > localhost (TCP/IP and Unix sockets) by default? > > No, but none of the others are better. See previous discussions in the > archives. I don't think the situation has changed any since the last > time we hashed this out. If they supply a password to initdb, shouldn't we then require a password in pg_hba.conf. -- 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
[HACKERS] Problems logging into CVS server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, We currently experience problems while logging into CVS server: [EMAIL PROTECTED] pgsql75]$ cvs -z3 -d :pserver:[EMAIL PROTECTED]:/projects/cvsroot co -P pgsql cvs checkout: authorization failed: server anoncvs.postgresql.org rejected access to /projects/cvsroot for user anoncvs FYI... - -- Devrim GUNDUZ devrim~gunduz.org devrim.gunduz~linux.org.tr http://www.tdmsoft.com http://www.gunduz.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFA8vh/tl86P3SPfQ4RAqy8AJ0RT1BoFpJjiWZgfbSxpookbTaZTACfeIGo UCNQv5zjByUhdjMt7w6TCYI= =m2Ks -END PGP SIGNATURE- ---(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] Beta date
On Mon, 2004-07-12 at 18:49, Bruce Momjian wrote: > Our current release schedule is: > > o apply most oustanding patches this week > o take two weeks to finalize open issues > o beta August 1 I will work to support this timeline. I'm still hacking at the stop-at-point-in-time part, which is definitely the last planned thing on the menu. My own schedule means I will not be able to contribute new code from 28 July for 10 days, though will be available to answer calls. 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] Is "trust" really a good default?
Bruce Momjian <[EMAIL PROTECTED]> writes: > If they supply a password to initdb, shouldn't we then require a > password in pg_hba.conf. We could, but I'm a bit disturbed about the issues of documenting two fundamentally different out-of-the-box behaviors. The ensuing confusion might be worse than the existing problem. (For instance, I can see people expecting that if they assign the superuser a password later, they should magically arrive at the same security state as if they'd done it at initdb time.) We'd also have some issues with the distributions that override the default local auth method to be IDENT --- how would this interact with that choice? (Note that the RPMs have completely failed to document this change, which doesn't make me any happier.) The bottom line to my mind is that if there were a one-size-fits-all authentication solution, we'd not have so many to choose from. I don't think we are doing DBAs any service by pretending that they might not need to think about their choice of auth method. I could make a good case that the initial entry ought to be REJECT, so that you get nothing at all until you've adjusted pg_hba.conf ... 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] Is "trust" really a good default?
tom lane wrote: > The bottom line to my mind is that if there were a one-size-fits-all > authentication solution, we'd not have so many to choose from. I don't > think we are doing DBAs any service by pretending that they might not > need to think about their choice of auth method. I could make a good > case that the initial entry ought to be REJECT, so that you get nothing > at all until you've adjusted pg_hba.conf ... The approach towards security from the default installation seems a little inconsistent, and inconsistency could lead to complacency and danger. The server is default configured to not allow root execution, which is a very good feature, but might lead one to believe that the default installation is secure. The win32 people just received a server drubbing regarding the admin account issue. However, trust based auth from localhost is very insecure out of the box because anybody with shell access can root your database...they can even bring their own psql along for the ride. IMO, forcing su password at initdb time (allowing blank password with a very stern warning) and bumping localhost to auth is the right way to go. As far as RPM's, etc. I don't think RPM considerations should be driving security concerns. Merlin ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Is "trust" really a good default?
"Merlin Moncure" <[EMAIL PROTECTED]> writes: > IMO, forcing su password at initdb time (allowing blank password with a > very stern warning) and bumping localhost to auth is the right way to > go. This isn't happening for a number of reasons, the most obvious being that we cannot require initdb to be run interactively. (That stern warning will not impress /dev/null.) regards, tom lane ---(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] [pgsql-www] Problems logging into CVS server
Damn ... I'll have to look at it ... we had a hacker get in through the way anoncvs was setup, so I set a passwd on in /etc/passwd (but didn't touch the anoncvs setup itself) ... will play with it tonight and see if I can figure out how to do a more secure anon-cvs ;( I have to be missing something in the config *sigh* On Mon, 12 Jul 2004, Devrim GUNDUZ wrote: -- /usr/local/libexec/ppf_verify: pgp command failed gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: Signature made Mon Jul 12 17:45:51 2004 ADT using DSA key ID 748F7D0E gpg: Can't check signature: public key not found -- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, We currently experience problems while logging into CVS server: [EMAIL PROTECTED] pgsql75]$ cvs -z3 -d :pserver:[EMAIL PROTECTED]:/projects/cvsroot co -P pgsql cvs checkout: authorization failed: server anoncvs.postgresql.org rejected access to /projects/cvsroot for user anoncvs FYI... - -- Devrim GUNDUZ devrim~gunduz.org devrim.gunduz~linux.org.tr http://www.tdmsoft.com http://www.gunduz.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFA8vh/tl86P3SPfQ4RAqy8AJ0RT1BoFpJjiWZgfbSxpookbTaZTACfeIGo UCNQv5zjByUhdjMt7w6TCYI= =m2Ks -END PGP SIGNATURE- ---(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 Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [subxacts] Open nested xact items
Alvaro Herrera wrote: Fix issues with cursors. Need to mess with open portals at subxact abort. One quick question here -- how does subtransaction commit interact with WITHOUT HOLD cursors? I'm hoping they stay open.. -O ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SAN, clustering, MPI, Backplane Re: Postgresql on SAN
Tom Lane wrote: Andrew Piskorski <[EMAIL PROTECTED]> writes: Another thing I've been wondering about, but haven't been able to find any discussion of: Just how closely tied is PostgreSQL to its use of shared memory? Pretty damn closely. You would not be happy with the performance of anything that tried to insert a network communication layer into access to what we think of as shared memory. For a datapoint, check the list archives for discussions a few months ago about performance with multiple Xeons. We were seeing significant performance degradation simply because the communications architecture for multiple Xeon chips on one motherboard is badly designed :-( The particular issue we were able to document was cache-line swapping for spinlock variables, but AFAICS the issue would not go away even if we had a magic zero-overhead locking mechanism: the Xeons would still suck, because of contention for access to the shared variables that the spinlocks are protecting. OpenMosix is in the category of "does not work, and would be unusably slow if it did work" ... AFAIK any similar design would have the same problem. However shall be nice if the postmaster is not selfish as is it now (two postmastera are not able to work on the same shared memory segment), projects like cashmere ( www.cs.rochester.edu/research/cashmere/ ) or this www.tu-chemnitz.de/informatik/HomePages/RA/projects/VIA_SCI/via_sci_hardware.html are able to run a single database mananged by a postmaster for each node in a distributed architecture. I seen these hardware working at CeBIT some years ago and it's possible to setup any kind of configuration: linear, triangular, cube, ipercube. Basically each node share part of the local RAM in order to create a big shared memory segment and the shared memory is managed "without kernel intervention". Regards Gaetano Mendola ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [subxacts] Open nested xact items
On Tue, Jul 13, 2004 at 10:34:08AM +1200, Oliver Jowett wrote: > Alvaro Herrera wrote: > > >Fix issues with cursors. Need to mess with open portals at subxact abort. > > One quick question here -- how does subtransaction commit interact with > WITHOUT HOLD cursors? I'm hoping they stay open.. That's the intended goal; to make them stay open and retain their execution status. -- Alvaro Herrera () "La tristeza es un muro entre dos jardines" (Khalil Gibran) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Is "trust" really a good default?
It has probably be said before, but new users need to be able to get up and running on their *development* system quickly. Throwing new users for a loop with the password configuration issues would be a problem. Most people would put up a test server first anyway in order to check things out and configure as necessary. --elein On Mon, Jul 12, 2004 at 05:27:23PM -0400, Tom Lane wrote: > "Merlin Moncure" <[EMAIL PROTECTED]> writes: > > IMO, forcing su password at initdb time (allowing blank password with a > > very stern warning) and bumping localhost to auth is the right way to > > go. > > This isn't happening for a number of reasons, the most obvious being > that we cannot require initdb to be run interactively. (That stern > warning will not impress /dev/null.) > > regards, tom lane > > ---(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 ---(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-www] Problems logging into CVS server
On Tue, 13 Jul 2004, Justin Clift wrote: Marc G. Fournier wrote: Damn ... I'll have to look at it ... we had a hacker get in through the way anoncvs was setup, so I set a passwd on in /etc/passwd (but didn't touch the anoncvs setup itself) ... will play with it tonight and see if I can figure out how to do a more secure anon-cvs ;( I have to be missing something in the config *sigh* Um, that sounds worrying. Was the activity of the hacker anything that would affect PG code, or access to anything sensitive (account passwords, etc)? No ... anoncvs is not part of the same group as the primary cvsroot, so not able to commit to the source tree ... the anoncvs cvsroot is a different directory structure altogether (/projects/cvsroot vs /cvsroot), and the anoncvs user has no write permissions on /cvsroot ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Anoncvs down?
-bash-2.05b$ cvs up cvs update: authorization failed: server anoncvs.postgresql.org rejected access to /projects/cvsroot for user anoncvs Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Is "trust" really a good default?
No, but none of the others are better. See previous discussions in the archives. I don't think the situation has changed any since the last time we hashed this out. I'll chime in from the phpPgAdmin point of view. The thing with phpPgAdmin is that it breaks the 'localhost' access is safe rule that the existing trust stuff assumes. This is because the most common setup is Apache and PostgreSQL on the same machine. The situation got SO BAD with being able to just Google for 'phpPgAdmin Login' and then just log straight in as 'pgsql' and no password that since version 3.2 or so we have had "extra login security". That means that by default in phpPgAdmin we disallow any login as the 'pgsql', 'postgres', 'root', or 'administrator' users, and you cannot log into any account without a password. This has fixed the problem greatly, however we get heaps of people who cannot understand why they cannot log in. Those are the people we save from themselves. I think that pg_hba.conf should have md5 on all by default, and the -W initdb parameter should be required. Chris ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Is "trust" really a good default?
No, but none of the others are better. See previous discussions in the archives. I don't think the situation has changed any since the last time we hashed this out. If they supply a password to initdb, shouldn't we then require a password in pg_hba.conf. This is further to my previous suggestion that we output the encoding that is being defaulted to. NEW USERS DO NOT KNOW THAT -W EXISTS! Even the majority of experienced users don't! It's a real pain in the butt that stuff like -E and -W aren't required parameters to initdb. Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Anoncvs down?
temporarily while I figure out what I screwed up that allowed a hacker to make use of he anoncvs account :( and, no, anoncvs doesn't have access to the core cvsroot ... On Tue, 13 Jul 2004, Christopher Kings-Lynne wrote: -bash-2.05b$ cvs up cvs update: authorization failed: server anoncvs.postgresql.org rejected access to /projects/cvsroot for user anoncvs Chris Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] Anoncvs down?
Marc G. Fournier wrote: temporarily while I figure out what I screwed up that allowed a hacker to make use of he anoncvs account :( and, no, anoncvs doesn't have access to the core cvsroot ... Did it have anything to do with this CERT advisory? http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=40B74B73.6080702%40mascari.com Mike Mascari ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] possibly updating techdocs; mysql2pgsql on gborg
Robert, Bruce, > > > If anybody still has access to that page, the project has moved to > > > gborg specifically over to > > > > > > http://gborg.postgresql.org/project/mysql2psql/projdisplay.php > > > > > > where a new version of the perl conversion script is located. There's one of these on GBorg too? I started on on pgFoundry because I made a bunch of changes to the script (which now need debugging). Since this one needs nothing but CVS, any objections to just migrating it? -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
