[GENERAL] unstable postgres on freebsd
Hi,I seem to have an unstable/unreliable installation of postgresql, and I'm not sure how to troubleshoot it.Symptoms:$ psql postgrespsql: FATAL: semctl(851974, 3, SETVAL, 0) failed: Invalid argument (restart postgresql)$ psql postgresWelcome to psql 8.1.4, the PostgreSQL interactive terminal.(rest of welcome message and psql prompt)It will work fine for a while, but later it will stop accepting connections with the above error, until I restart postgresql again. It also happens when I call a ruby script that connects to postgres: fails with same error message sometimes, but works after restarting postgresql. Versions/Environment:Postgresql 8.1.4 (installed from ports on FreeBSD 6.1)I've already tried reinstalling the postgresql81-server and postgresql81-client ports and their dependencies via portupgrade, but the symptoms persist. What else should I try? -- Wes Sheldahl[EMAIL PROTECTED]
Re: [GENERAL] performace review
On 10/22/06, Tom Lane <[EMAIL PROTECTED]> wrote: "Joshua D. Drake" <[EMAIL PROTECTED]> writes:> Ron Johnson wrote:>> That implies malice. The people at OpenCRX apparently really>> believe what they wrote. > I believe they probably do believe it and it was probably driven by a> complete lack of understanding of PostgreSQL.> It doesn't have to be malicious for it to be FUD though.The psychological reason seems clear enough: if they can dismiss postgres as not being worthy of their time, it saves them a lot ofwork in supporting another database. By this point I'd imagine thattheir code is sufficiently mysql-centric that trying to have realsupport for other databases would be a huge undertaking; ergo, there will be great resistance to the idea that they should take postgresseriously. It's a bit of a self-fulfilling prophecy, too, becauseonce the code is sufficiently tuned for mysql you can indeed show thatany other database sucks running it ... regards, tom lane---(end of broadcast)---TIP 5: don't forget to increase your free space map settingsI think you're right, except that they don't recommend MySQL for production either; they seem happiest with MS SQL Server and Oracle, which seems a little odd for an open source project. If they haven't figured out how to get their app to work well with either MySQL or PostgreSQL, it seems a little disingenuous to claim they support them on the site's front page. Oh well. (shrug) -- Wes Sheldahl[EMAIL PROTECTED]
Re: [GENERAL] unstable postgres on freebsd
Yes, it's a VPS running FreeBSD 6.1, so presumably it's in a FreeBSD jail. I'll verify that with my hosting provider and probably follow up along these lines. http://www.postgresql.org/docs/8.1/interactive/kernel-resources.html seems to recommend running as different uid's as well. Right now it's running as pgsql, UID 70, which I'm sure is the default. Thanks, Wes SheldahlOn 10/21/06, Marc G. Fournier <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE-Hash: SHA1Are you running this in a FreeBSD jail under 6.1? It sounds like the problemthat I had where a second postmaster starts up and stomp's on the previouspostgresql's shared memory ... To "fix", you have to make sure that both instances run as different UIDs, sothat one can't stomp on the other ...- --On Friday, October 20, 2006 17:05:53 -0400 Wes Sheldahl< [EMAIL PROTECTED]> wrote:> Hi,>> I seem to have an unstable/unreliable installation of postgresql, and I'm not> sure how to troubleshoot it.>> Symptoms:> $ psql postgres > psql: FATAL: semctl(851974, 3, SETVAL, 0) failed: Invalid argument>> (restart postgresql)> $ psql postgres> Welcome to psql 8.1.4, the PostgreSQL interactive terminal.> (rest of welcome message and psql prompt) >> It will work fine for a while, but later it will stop accepting connections> with the above error, until I restart postgresql again. It also happens when> I call a ruby script that connects to postgres: fails with same error message > sometimes, but works after restarting postgresql.>> Versions/Environment:> Postgresql 8.1.4 (installed from ports on FreeBSD 6.1)>> I've already tried reinstalling the postgresql81-server and > postgresql81-client ports and their dependencies via portupgrade, but the> symptoms persist. What else should I try?>> --> Wes Sheldahl> [EMAIL PROTECTED]- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED]Yahoo . yscrappy Skype: hub.orgICQ . 7615664-BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD)iD8DBQFFOtuu4QvfyHIvDvMRAkUhAKChtw+L12z8UJhYfl8HfbzRm0kdoQCbBzjoaK5Pas9/HWfhjFNKMwnagXw==35KQ-END PGP SIGNATURE- -- Wes SheldahlSheldahl Consulting LLChttp://www.sheldahlconsulting.comPhone: 859-338-3349Fax: 866-387-4484 [EMAIL PROTECTED]
Re: [GENERAL] Is postgres installed by default in Fedora Core 5 ??
On 10/27/06, Sandeep Kumar Jakkaraju <[EMAIL PROTECTED]> wrote: Is postgres installed by default in Fedora Core 5 ?? - Sandeep Kumar Jakkaraju I know that there are Fedora 5 RPM's for postgresql, that you can easily install via yum or your favorite install method. It's *probably* included among the applications you can install during the Fedora installation process itself. To install the client and server packages via yum, you would do: yum install postgresql postgresql-serverCheers,-- Wes SheldahlSheldahl Consulting LLChttp://www.sheldahlconsulting.comPhone: 859-338-3349 Fax: 866-387-4484[EMAIL PROTECTED]
Re: [GENERAL] Is there anyway to...
On 11/2/06, AgentM <[EMAIL PROTECTED]> wrote: On Nov 2, 2006, at 14:02 , Glen Parker wrote:> louis gonzales wrote:>> Hey Brian,>> Yeah I had considered this, using cron, I just feel like that is>> too dirty.>> Actually I didn't see Andreas' post, can someone forward that? >> I'm running this application on Solaris 9. Ultimately what I want>> to know is, is there something that is internal to postgresql that>> can be used that doesn't need external action, to make it do some >> task?>> Some built in function that can be set to do some simple task on a>> daily - or other time - interval, where all of the defined users>> may not have any activity with the database for day's or week's at >> a time, but this builtin function still operates?>> Am I making any sense with how I'm asking this? I could of course>> have cron do a scheduled task of checking/incrementing/>> decrementing and define triggers to occur when one of the cron >> delivered actions sets the appropriate trigger off, but are there>> other methods that are standard in the industry or are we stuck>> with this type of external influence?>> > Just some commentary... This is exactly the sort of thing cron is> for. Duplicating that functionality in the RDBMS would be silly> IMO. I don't see why you could consider cron to be "dirty" for > this application...I actually tried to come up with something for this. There are plentyof good reasons to have some timer functionality in the database:1) it makes regular database-oriented tasks OS portable 2) your cron user needs specific permissions + authorization toaccess the database whereas postgres could handle "sudo"-likebehavior transparently3) there are triggers other than time that could be handy- on vacuum, on db start, on db quit, on NOTIFYUnfortunately, the limitation I came across was for 2). There is noway to use "set session authorization" or "set role" safely becausethe wrapped code could always exit from the sandbox. So my timer only works for db superusers.-M---(end of broadcast)---None of those are good reasons to have timer functionality in the DB. Portability can be achieved having your cron job written in a portable language, like java, ruby or perl. Consistent permissions can be handled by having the java/whatever script connect to the db as a particular user; it doesn't matter what user executes the cron job provided it can run the script. #3 has nothing to do with timer functionality. Glen was right about solving this problem with some basic date math: IF (now - startdate) > '30 days' THEN EXPIRED. This could be implemented at the application level, or in postgresql as a function that the application calls whenever it wants to know about possible expirations. So this particular problem may be better solved without any timer functionality either in OR out of the database... if you did have a cron job run to check, you would probably just have it set a boolean field on expired records or something of that sort, and run it a little after midnight, at the start of each day, assuming durations were always being measured in days. Best of luck,-- Wes Sheldahl[EMAIL PROTECTED]
