Re: [GENERAL] Annoying Reply-To
Angel Alvarez wrote: Well but the RFC's were in fact prior to thunderbird So for he most of its life, when few people was using it, Thiunderbird was a sad example of your botched attempt of creating a standar of NOT FOLLOWING THE RFC's... But, as I mentioned, nobody cares about this particular standard. In my opinion a standard which is totally ignored by almost everyone is effectively dead and worthless. Well, also M$ thought they invented internet so its a common mistake. I thought that was Al Gore that invented the internet. ;-) May be you can push Thunderbird guys a bit to include a little more funcionailty other than complaining others that try to follow what to seemed to be the right way. Are we going to try be standars compliant or we keep trying to reinvent the wheel? Poor RFC people, what a waste of time... Standards are all well and good but anything should be evaluated for it's utility. If a standard is undesirable then it's undesirable. Most mailing lists do not exhibit the same behavior as this list not because they are all ignorant of the standard but because they feel that following the standard is not desirable. I'm perfectly fine to follow the convention of this list. Some lists like top posting. Not this one. That's ok, I'll bottom or interleaved post. All I'm saying is that one cannot look to standards as gospel and disengage their brains. It's perfectly acceptable to say 'this standard sucks!' And so, I along with a couple of other people from this list, say 'this standard sucks.' -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Annoying Reply-To
Angel Alvarez wrote: What's such most advanced mail reader?? No one, ive seen, seems to be perfect nor thunderbird. By the way kmail has 4 options (reply, reply to all, reply to author, reply to list) in addition to be able to use list headers included in the message. in fact many other mail-list dont have such extended features, as not all of the previous 4 options works as expected. For me this makes postgres lists the most complete about the RFC. So is about, thunderbird to move forward one step, not to cripple standars back. In fact this remembers me the M$ way of doing things.. Regards, Angel One could argue that a standard which is respected by nobody but a few people from this list is NOT a standard but rather a botched attempt at creating a standard which no one wanted. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Annoying Reply-To
Bruce Momjian wrote: Mikkel is right, every other well-organized mailing list I've ever been on handles things the sensible way he suggests, but everybody on his side who's been on lists here for a while already knows this issue is a dead horse. Since I use the most advanced e-mail client on the market I just work around that the settings here are weird, it does annoy me a bit anytime I stop to think about it though. I think this is the crux of the problem --- if I subscribed to multiple email lists, and some have "rely" going to the list and some have "reply" going to the author, I would have to think about the right reply option every time I send email. Fortunately, every email list I subscribe to and manage behaves like the Postgres lists. I find it difficult to believe that every list you subscribe to behaves as the Postgres list does. Not that I'm doubting you, just that it's difficult given that the PG list is the ONLY list I've ever been on to use Reply as just replying to the author. Every other list I've ever seen has reply as the list address and requires Reply All to reply to the original poster. Thus, I would fall into the category of people who have to think hard in order to do the correct thing when posting to this list. I've checked and I can't even find an option to make Thunderbird (the client I use in windows) reply to the list properly with the reply button (it just cannot be set that way.) You must use Reply All. You might say that that makes Thunderbird crippled but I see it more as a sign that nobody outside of a few fussy RFC worshipping types would ever want the behavior of the Postgre list. Yes, I'll have to live with the current behavior. Yes, it's an RFC standard. But, even after having heard the arguments I'm not convinced that this list's behavior is desirable. YMMV. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Annoying Reply-To
I resent that you're trying to make this a personal thing. I was going to answer the rest of this email, then I realized that the real problem was right here, and discussing anything else was dancing around the issue and wasting time. You can resent it or not, but this _is_ a personal thing. It's personal because you are the only one complaining about it. Despite the large number of people on this list, I don't see anyone jumping in to defend you. I'm not saying your problems aren't real, I'm just saying you're apparently the only person in this community that has enough trouble with them to take the time to start a discussion. To that degree, the problem is very personal to you. I was going to stay out of this but I'll jump in and defend him. The people on this list are so pedantic, so sure that their way is the only way that they absolutely rain nuclear fire down on anyone who dares to disagree. And you wonder why no one sprang to his defense??? And, I do agree with him on this issue. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Timezone issue - Is it me or is this a massive bug?
I have read the post and understand the issue. I am wondering why
this is not mentioned in the documentation. Or even worse why the
PostgreSQL documentation explicitly lists all the timezones correctly
in table B-4
http://www.postgresql.org/docs/8.1/static/datetime-keywords.html#DATETIME-TIMEZONE-INPUT-TABLE
In that table it has Melbourne, Australia as
LIGT+10:00 Melbourne, Australia
But according to the post you linked to that is not correct... I must
instead specifiy -10:00. Should the documentation not note this?
On Sat, Jun 21, 2008 at 9:54 AM, Adrian Klaver <[EMAIL PROTECTED]> wrote:
> On Friday 20 June 2008 1:19 pm, Collin Peters wrote:
>> I have a server of which the OS timezone is set to Pacific time
>> (currently -7). I run the following query on it
>>
>> SELECTnow(), now() AT TIME ZONE 'GMT+10:00', now() AT TIME ZONE
>> 'GMT-10:00', now() AT TIME ZONE 'Australia/Melbourne'
>>
>> I would expect this to return:
>> * column 1 - the current time in the pacific (-7) - "2008-06-20
>> 13:09:39.245641-07"
>> * column 2 - the GMT +10 - "2008-06-21 06:09:39.245641"
>> * column 3 - the GMT -10 - "2008-06-20 10:09:39.245641"
>> * column 4 - the current time in Melbourne Australia - "2008-06-21
>> 06:09:39.245641"
>>
>> Instead it returns:
>> * column 1 - the current time in the pacific (-7) ("2008-06-20
>> 13:09:39.245641-07" - CORRECT)
>> * column 2 - the current time MINUS 10 ("2008-06-20 10:09:39.245641" -
>> WRONG) * column 3 - the current time PLUS 10 ("2008-06-21 06:09:39.245641"
>> - WRONG) * column 4 - the current time in Melbourne Australia ("2008-06-21
>> 06:09:39.245641" - CORRECT)
>>
>>
>> Am I missing something obvious? Seems when I specify GMT+10:00 it
>> returns GMT-10:00 and vice versa. Note that column 2 & 3 are
>> timestamp withOUT timezone while 1 & 4 are timestamp WITH timezone.
>> But I still see this as totally wrong.
>>
>> Regards,
>> Collin Peters
>
> See this message for the explanation:
> http://archives.postgresql.org/pgsql-bugs/2008-04/msg00077.php
> --
> Adrian Klaver
> [EMAIL PROTECTED]
>
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Timezone issue - Is it me or is this a massive bug?
I have a server of which the OS timezone is set to Pacific time
(currently -7). I run the following query on it
SELECT now(), now() AT TIME ZONE 'GMT+10:00', now() AT TIME ZONE
'GMT-10:00', now() AT TIME ZONE 'Australia/Melbourne'
I would expect this to return:
* column 1 - the current time in the pacific (-7) - "2008-06-20
13:09:39.245641-07"
* column 2 - the GMT +10 - "2008-06-21 06:09:39.245641"
* column 3 - the GMT -10 - "2008-06-20 10:09:39.245641"
* column 4 - the current time in Melbourne Australia - "2008-06-21
06:09:39.245641"
Instead it returns:
* column 1 - the current time in the pacific (-7) ("2008-06-20
13:09:39.245641-07" - CORRECT)
* column 2 - the current time MINUS 10 ("2008-06-20 10:09:39.245641" - WRONG)
* column 3 - the current time PLUS 10 ("2008-06-21 06:09:39.245641" - WRONG)
* column 4 - the current time in Melbourne Australia ("2008-06-21
06:09:39.245641" - CORRECT)
Am I missing something obvious? Seems when I specify GMT+10:00 it
returns GMT-10:00 and vice versa. Note that column 2 & 3 are
timestamp withOUT timezone while 1 & 4 are timestamp WITH timezone.
But I still see this as totally wrong.
Regards,
Collin Peters
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pgAdmin complains about vacuuming required after fresh 8.1 install
Bump Does anyone have *any* thoughts on this? This seems to be a fairly common problem. Does anybody have any good links that they can provide to find an answer? My current test is that I have a table where all the rows were purged, and then new ones inserted using a specific job. pgAdmin reports 0 estimated rows and 46 counted rows and therefore displays the popup saying a vacuum should be run. I see in the PostgreSQL log that autovacuum is vacuuming this database regularly. Is this simply because pgAdmin has tighter settings and autovacuum hasn't actually done anything with this table yet? On Thu, Jun 5, 2008 at 5:47 PM, Collin Peters <[EMAIL PROTECTED]> wrote: > Hi all - I am wondering if I can get a consensus on what to do about > this minor issue. I have looked through the archives and can't find a > definitive answer. > > So I have a new 8.1 install on Linux (have not yet been able to > upgrade to 8.3). The documentation say that autovacuum is enabled by > default in 8.1 and sure enough I see messages in the logs that > autovacuum is "processing database "postgres"", etc... > > In my postgresql.conf I see 'autovacuum = on', 'stats_start_collector > = on', and 'stats_row_level = on' > > However, despite all this pgAdmin still gives me messages on certain > tables recommending a vacuum to be run. I see some messages saying > that you need to run a VACUUM ANALYZE every week or night to 'make > sure things are up to date', but then in the commits I see a comment: > "Update documentation to mention that autovacuum also does analyze so > we don't need to recommend nightly analyzes anymore unless autovacuum > is off." > > So I am looking for the definitive answer on this. Is pgAdmin wrong > and I should ignore the messages? Is autovacuum not fully running? > Do they just have different threshold values and pgadmin is a bit > pickier? > > Regards, > Collin > -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] pgAdmin complains about vacuuming required after fresh 8.1 install
Hi all - I am wondering if I can get a consensus on what to do about this minor issue. I have looked through the archives and can't find a definitive answer. So I have a new 8.1 install on Linux (have not yet been able to upgrade to 8.3). The documentation say that autovacuum is enabled by default in 8.1 and sure enough I see messages in the logs that autovacuum is "processing database "postgres"", etc... In my postgresql.conf I see 'autovacuum = on', 'stats_start_collector = on', and 'stats_row_level = on' However, despite all this pgAdmin still gives me messages on certain tables recommending a vacuum to be run. I see some messages saying that you need to run a VACUUM ANALYZE every week or night to 'make sure things are up to date', but then in the commits I see a comment: "Update documentation to mention that autovacuum also does analyze so we don't need to recommend nightly analyzes anymore unless autovacuum is off." So I am looking for the definitive answer on this. Is pgAdmin wrong and I should ignore the messages? Is autovacuum not fully running? Do they just have different threshold values and pgadmin is a bit pickier? Regards, Collin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Connect to postgres from a dynamic IP
But make it "hostssl" instead of "host", to require some cryptography in the channel used, specially to authenticate the connection. Opening your access to everyone without crypto sounds like something you don't want to do. Specially if users can change their own passwords... My understanding is no password is sent in the clear with md5 per: http://www.postgresql.org/docs/8.3/interactive/auth-methods.html#AUTH-PASSWORD Paul However, it depends on the sort of data you are accessing. Sending a MD5 password is all well and good but if your data consists of credit card info or trade secrets then you'll want that encrypted too. ---(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: [GENERAL] [pgsql-advocacy] PostgreSQL Certification
Lewis Cunningham wrote: --- Gregory Stark <[EMAIL PROTECTED]> wrote: pgsql-hackers pgsql-users There really aren't any other groups of people. "people who want to talk about There are hackers (contribute to PostgreSQL), DBAs (administer the database), Developers (write application to interact with the database) and users (use a tool like pgAdmin to query the database)? When talking about coders, there are pl/pgSQL, PL/xxx, SQL, external langauges. I think there are many groups. If a person is interested in all the groups, is it hard to subscribe? No. If all groups are in one, is it hard to filter out? Yes. LewisC Lewis R Cunningham An Expert's Guide to Oracle Technology http://blogs.ittoolbox.com/oracle/guide/ LewisC's Random Thoughts http://lewiscsrandomthoughts.blogspot.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq ---(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: [GENERAL] Would it be OK if I put db file on a ext2 filesystem?
Magicloud Wang wrote: Dear, I think database has its own operation journal, and different journal filesystem does give different performance. So if I put database file on a non-journal filesystem, would it be safe? Does this like using a raw device? You lose a little bit of data integrity in exchange for a little bit of speed. I suppose it'd be a fine thing to do so long as you can live with that trade off. If you want good data integrity you are more likely to get it from battery backed RAID5 or RAID10 or something of that sort rather than just trusting something like EXT3 or Reiser. EXT2 isn't a bad file system. ---(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: [GENERAL] top posting
I agree with Joshua on this point. It's entirely possible to discuss this without resorting to immaturity. If you make a decent point, then diminish it by cursing or insulting everybody here, you've lost the point and it's effectiveness entirely. Yes, once again, I apologize. At times I seem to fail at running what I really think though the ol' appropriateness filter. This has been one of those times. I'm sorry for what has amounted to personal attacks and trolling. It wasn't really my intent but looking back now I can see that I've acted improperly. This is something I'll have to try to work on. Sorry all! ---(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: [GENERAL] top posting
I felt I was 'responding in kind' wrt 'it really irritates me when people cry like 4 year olds about top posting. It's not that bad, get over it.' posting. My apologies if I've taken it to a level of rude that it had not already reached. I suppose that the post was probably directed at me as much as it was at you. For my part in the rudeness I also apologize (and for the reply that I sent you which hasn't shown up on the list yet but will.) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] top posting
Geoffrey wrote: Collin Kidder wrote: I have to suffer through dealing with people like the two of you quoted above. You can deal with people who'd like to top post. Anything else is just being a spoiled baby who can't deal with minor issues. If all the energy spent crying about top posting were used to fuel cities none of us would be paying for power right now. Sorry to be so blunt but it really irritates me when people cry like 4 year olds about top posting. It's not that bad, get over it. If it's not brought to the attention of the masses, then it will simply grow, and it simply is not the way it's done on this list. Get use to it. Now who's doing the 4 year old crying?? Yes, I'm bitching, crying, or whatever you'd like to call it. But you notice, I'm still attempting to follow the proper posting etiquette for this list. However, I do not see any actual valid reason that top posting cannot ever be acceptable except that some people are way too stuck in a mental rut and refuse to allow for anything other than their way. You will also notice that I am far from the only one who follows the rules while simultaneously questioning whether there is any point in condemning top posting. I believe that my conforming to the "rule" shows that I am willing to cater to the wishes of the overly anal people on this list. That they cannot allow any deviation from their narrow mindset shows you that the real problem we've been talking about is with them. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] top posting
Scott Marlowe wrote: On Dec 11, 2007 11:41 AM, Leif B. Kristensen <[EMAIL PROTECTED]> wrote: It certainly isn't a crime. But it's a bit like thread hijacking in the sense that a well-formed inline posting is more likely to attract intelligent replies. I don't think that I'm the only one who tends to skip top posting replies on mailing lists. You're certainly not. I can't tell you how many times I've carefully replied to someone with inline quoting, only to get some top post response. I then ask them politely not to top post, fix the format, reply, and get another top post reponse. At that point I just move on to the next thread. I've already made it clear on this list that I would rather top post but I've been bottom posting because nothing in this world is more irritating than a pedantic computer nerd and well... this is a list about a database server... I have to suffer through dealing with people like the two of you quoted above. You can deal with people who'd like to top post. Anything else is just being a spoiled baby who can't deal with minor issues. If all the energy spent crying about top posting were used to fuel cities none of us would be paying for power right now. Sorry to be so blunt but it really irritates me when people cry like 4 year olds about top posting. It's not that bad, get over it. ---(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: [GENERAL] Syntax error in a large COPY
My point is: with top-posting I don't care how many lines were repeated because I don't have to scroll. Considering there is an RFC that recommends inline posting over top-posting (http://tools.ietf.org/html/rfc1855), and considering the fact that this topic has been beat to death on dozens of mailing lists and the predominant preference is _not_ for top-posting -- perhaps you should either follow the preferences of the group, or leave the group. I'm with Thomas. I think that, while inline posting is a good thing, bottom posting is dead stupid and wastes my time. It is far easier to follow a thread with top posting as the relevant text is right there at the top ready to be read. But this horse has been beat to death before... Obviously not, as it keeps coming back to life. I guess it's an undead horse? No, just not everyone agrees with your viewpoint on this topic. Top posting has it's place and some of us prefer it. Obviously I'm not doing it but it's only because of the large amount of anal retentive people on lists like this. And so... with that my view is out there. I hate bottom posting. But I for one will do it to keep the peace. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Syntax error in a large COPY
This is offtopic but there is nothing wrong with top posting. Is there a mail list policy on it or are you just picky about it? Scott Marlowe wrote: On 11/6/07, Reg Me Please <[EMAIL PROTECTED]> wrote: That seems not to be the case. The last line has a \. by its own and the last but one is well formed. (Please don't top post...) Got a self contained test case you can post? ---(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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Migration from PervasiveSQL
What about Perl? DBI? Not sure if it supports PervasiveSQL The OP stated he already had ODBC connectors setup. Yes, I already have ODBC setup. I'm basically just writing a little something myself that uses the existing Pervasive and Postgres tools as much as possible. On a side note, not that it surprises me but it is a little weird that Pervasive supported postgresql for a while but yet there is no really good way to convert from pervasive to postgres. I've always thought that Pervasive backing out had a lot more to do with them suddenly realizing they were showing the world a better product than theirs and not because of the large amount of support postgresql already had (like they claimed the reason was...) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[GENERAL] Migration from PervasiveSQL
Well, the subject says it pretty well but to elaborate: I have a database from our ERP package that uses btrieve (PervasiveSQL) for it's database engine. I'd like to transition all of the data to PostgreSQL. I've been having trouble finding a suitable program to automatically get all of the data transferred over. I have the proper DDF files and an ODBC link in place to the data. Maestro DataDump (from the Postgresql Data Wizard program) only locks my machine up and it seemed to be the only think I could find that would take an ODBC link to the btrieve data and use it to extract the table defs and data to postgresql. Is there some other utility I could use or am I stuck writing a custom program to do it? I could maybe extract the btrieve data to CSV files but I don't have any easy way of doing that quickly for so many tables (and there are a lot!) Any help would be appreciated. Thanks! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
[GENERAL] Auto vacuum documentation
Where is the definitive source for all things autovacuuming? I have seen http://www.postgresql.org/docs/8.1/static/maintenance.html#AUTOVACUUM. Ultimately the issue I am having is that the postgresql logs show each of the databases being 'autovacuumed' (actually quite often), but when I click around in pgAdmin it still prompts me to vacuum for many of the tables. I am wondering if there are any sites that tell me the ins-n-outs of autovacuuming. Regards, Collin ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[GENERAL] Extremely slow performance with 'select *' after insert of 37,000 records
The table in question is a simple users table. The details are at the bottom of this message. The performance on this table was fine during testing with less than 100 users. Then we inserted about 37,000 records into the table. Now a 'SELECT * FROM pp_users' takes over 40 seconds!!. 37,000 records is not much at all so I am wondering why the slow execution time. Here are some stats and log output files. Running the query 'SELECT * FROM pp_users' -- On LAN connection (using pgadmin): Total query runtime: 14547 ms. Data retrieval runtime: 10453 ms. 37326 rows retrieved. On Internet connection (using pgadmin): Total query runtime: 32703 ms. Data retrieval runtime: 16109 ms. 37326 rows retrieved. On db server using psql (somewhat better but still slow for 37000 rows): devel=# select * from pp_users; Time: 912.779 ms Running the query 'EXPLAIN ANALYZE SELECT * FROM pp_users' --- "Seq Scan on pp_users (cost=0.00..1597.26 rows=37326 width=1102) (actual time=0.029..33.043 rows=37326 loops=1)" "Total runtime: 44.344 ms" (same stats when run on all computers (lan/internet/localhost) Anybody know what would cause things to be so slow? Seems kind of absurd really. Indexes shouldn't play a role since a 'select *' does a sequential scan. Even so there will be an index on the primary key (user_id) which is proved with the query: EXPLAIN ANALYZE SELECT * FROM pp_users WHERE user_id < 100 "Index Scan using pp_users_pkey on pp_users (cost=0.00..7.80 rows=4 width=1102) (actual time=0.080..0.246 rows=54 loops=1)" " Index Cond: (user_id < 100)" Let me know if any more information would help. This is postgresql 7.4.7 (also a unicode database). Regards, Collin - -- Table: pp_users -- DROP TABLE pp_users; CREATE TABLE pp_users ( user_id serial NOT NULL, title varchar(10), firstname varchar(40) NOT NULL, lastname varchar(40) NOT NULL, shortname varchar(20) NOT NULL, username varchar(20), "password" varchar(40) NOT NULL, birthdate date, sex char(1), weight int4, company varchar(40), email varchar(60), tel1 varchar(40), tel2 varchar(40), fax varchar(40), street varchar(40), city varchar(40), zipcode varchar(10), state varchar(30), country varchar(40), "language" varchar(5), cellphone varchar(40), userstatus_id int4 NOT NULL DEFAULT 1, acc_deleteme varchar(4), proxy text, settings text, creationdate date DEFAULT now(), createdby_user_id int4, div1 varchar(40), div2 varchar(40), div3 varchar(40), div4 varchar(40), role_id int4, joined_date date DEFAULT now(), membership_id varchar(40), password_status int4, CONSTRAINT pp_users_pkey PRIMARY KEY (user_id), CONSTRAINT "$3" FOREIGN KEY (userstatus_id) REFERENCES userstatuses (userstatus_id) ON UPDATE RESTRICT ON DELETE RESTRICT, CONSTRAINT role_id_fk FOREIGN KEY (role_id) REFERENCES pp_roles (role_id) ON UPDATE RESTRICT ON DELETE RESTRICT ) WITH OIDS; ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[GENERAL] Best practices for migrating a development database to a release database
I have searched the Internet... but haven't found much relating to this. I am wondering on what the best practices are for migrating a developmemnt database to a release database. Here is the simplest example of my situation (real world would be more complex). Say you have two versions of your application. A release version and a development version. After a month of developing you are ready to release a new version. There have been many changes to the development database that are not in the release database. However, the release database contains all your real information (customers, etc...). What is the best practice for migrating the development database to the release database? I have thought of the following situations: -Simply track all the changes you made to the development database and make the same changes to the release database -Back up the release database... overwrite it with the development database... then copy all your real data back into the release database (this last step is probably quite difficult) -Perhaps some combination of the two Does anybody have any recommendations? Regards, Collin Peters ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: SV: [GENERAL] Postmaster startup problems
I am just trying to connect locally. Only one machine involved. Is there a way to tell what port the postmaster is running on if it is running at all. Collin On Sun, 8 Oct 2000 10:55:32 +0200, Jarmo Paavilainen said: > > > > I'm having problems starting postgres. What happens is > > that I start it but then it says it isn't running. > > > DEBUG: Data Base System is starting up at Sat Oct 7 13:13:29 2000 > > DEBUG: Data Base System was shut down at Sat Oct 7 13:13:25 2000 > > DEBUG: Data Base System is in production state at Sat Oct 7 13:13:29 2000 > > > Which leads me to think that it is in fact running. But I can't > > connect!! Is it maybe running on a different port or something? Another > > From where are you trying to connect? If your not connecting locally you > must add the -i option to postmaster. > > // Jarmo > >
[GENERAL] Postmaster startup problems
I'm having problems starting postgres. What happens is that I start it but then it says it isn't running. In one terminal window: postgres@the-kernel:~$ postmaster -D /usr/local/pgsql/data/ >$HOME/pm.log DEBUG: Data Base System is starting up at Sat Oct 7 13:13:29 2000 DEBUG: Data Base System was shut down at Sat Oct 7 13:13:25 2000 DEBUG: Data Base System is in production state at Sat Oct 7 13:13:29 2000 In another terminal window while still looking at postmaster 'running' in the other: postgres@the-kernel:~$ psql psql: connectDBStart() -- connect() failed: Connection refused Is the postmaster running at 'localhost' and accepting connections on Unix socket '5432'? If I try to start postmaster again: postgres@the-kernel:~$ postmaster -D /usr/local/pgsql/data/ >$HOME/pm.log FATAL: StreamServerPort: bind() failed: Address already in use Is another postmaster already running on that port? If not, remove socket node (/tmp/.s.PGSQL.5432) and retry. /usr/local/pgsql/bin//postmaster: cannot create UNIX stream port Which leads me to think that it is in fact running. But I can't connect!! Is it maybe running on a different port or something? Another strange thing is that TOP reports the running process to be /usr/local/pgsql/bin instead of /usr/local/pgsql/bin/postmaster which is the way I remember it running before. Collin Peters
