Re: [HACKERS]
The warn 'em in several places seems like a very good approach. regards Mark Matthew T. O'Connor wrote: There will always be people who won't read the notes, or ignore the notes, as there will always be people doing all sorts of stupid things that we can't protect them from. There is only so much we can and should do to protect these types of people. I think if we just make sure we warn people in several places so that anyone who does read the release notes will find it. ---(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] Latest requests from IRC
Just my two pence contribution: * Allow GRANT/REVOKE permissions to be given to all schema objects with one command GRANT SELECT ON TABLE myschema.* TO foo As for the style of the syntax, maybe one could consider to reuse already available sql regexpr rather than import shell-like regexpr? GRANT SELECT ON TABLE 'myschema.%' TO calvin; Also, there is no reason why the schema themselves could not been fixed similarly: REVOKE ALL FROM SCHEMA 'abc%' FROM hobbes; On the other hand, having actual sql regexpr may make a potential implementation harder wrt just handling a 'myschema.*' special case. Have a nice day, -- Fabien. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Slony-I questions
Does anybody know answer for these questions? 1) Does Slony-I supports replicating large objects? 2) Is Slony-I a sync or async replication system? Since Slony-I bases on trigger I suspect it's kind of async replication system. -- Tatsuo Ishii ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Big problem
Hi guys, A guy on the IRC channel managed to accidentally click the wrong thing in phpPgAdmin and managed to remove superuser privileges from his only superuser. We thought and though but it seems that there is no way to recover from this situation except a re-init and reload. And what user is he even going to dump as? Is there anything he can do? Also, shouldn't we prevent this situation from ever occurring? Please reply to all as he isn't subscribed. Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Slony-I questions
Tatsuo Ishii wrote: Does anybody know answer for these questions? 1) Does Slony-I supports replicating large objects? Slony-I does no replicate large objects. 2) Is Slony-I a sync or async replication system? Since Slony-I bases on trigger I suspect it's kind of async replication system. Slony-I is an asynchronous master-slave replication system based on a generic C language trigger function plus an external client process (one per database participating in replication). Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS]
Magnus Hagander wrote: FWIW, I think reporting a differnt version is just a *terrible* idea. Any client side program (say, pgadmin for example) that tries to determine what version backend it's connected to in order to know if a feature exists or not will be confused, in many cases to the point of being unusable. If the 'server_version' parameter emitted at startup and/or the results of 'SELECT version()' reports something less than 7.5 for a 7.5 server, the JDBC driver will certainly break. -O ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Syntax question
For what it's worth, I like the second form better. Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Christopher Kings-Lynne Sent: Sunday, May 23, 2004 6:08 AM To: PostgreSQL-development Subject: [HACKERS] Syntax question Here are the two syntaxes we can use for turning off clustering: 1) ALTER TABLE / SET WITHOUT CLUSTER This will turn off clusting on any index on the table that has it enabled. It won't recurse so as to match the CLUSTER ON syntax. However, this form makes the non-standardy SET WITHOUT form more emphasised... 2) ALTER TABLE / DROP CLUSTER ON idx I like this form, however to make it work, we need to bump CLUSTER to being a reserved keyword. This form looks more like SQL standard, and is related to the CLUSTER ON form. Which one do we want? Chris ---(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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] MySQL Lays Path for SAP Integration
Wonder how real this is? http://www.amrresearch.com/search/view.asp?id=17298 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Big problem
On Mon, May 24, 2004 at 09:54:20PM +0800, Christopher Kings-Lynne wrote: in phpPgAdmin and managed to remove superuser privileges from his only superuser. We thought and though but it seems that there is no way to recover from this situation except a re-init and reload. And what user is he even going to dump as? Hmm ... I'm not sure but maybe with a standalone backend it can be recovered? If not, I'd suggest compiling a hacked backend with the permission check for the ALTER USER ripped out, use that to correct the problem, and then erase it (and the patch). -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) One man's impedance mismatch is another man's layer of abstraction. (Lincoln Yeoh) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Big problem
Christopher Kings-Lynne [EMAIL PROTECTED] writes: A guy on the IRC channel managed to accidentally click the wrong thing in phpPgAdmin and managed to remove superuser privileges from his only superuser. No sweat; we've seen this one before. Stop postmaster and start a standalone backend. Now you are a superuser, and you can create a new superuser, or just go in and UPDATE pg_shadow to make your original user super again. Exit standalone backend, restart postmaster, have a beer. The REINDEX man page is worth reading if you've never used a standalone backend before; it covers some of the gory details. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Big problem
No sweat; we've seen this one before. Should this situation be prevented though? Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Big problem
Christopher Kings-Lynne [EMAIL PROTECTED] writes: No sweat; we've seen this one before. Should this situation be prevented though? I think the cure would probably be worse than the disease. To make any serious attempt at preventing remove-the-last-superuser, we'd have to make operations on pg_shadow grab exclusive lock. For instance, you couldn't allow two backends to DROP USER in parallel; they might be dropping the last two superusers, but neither one would think it was creating a problem. And while we could theoretically make CREATE/ALTER/DROP USER take such locks, I dunno how you make a straight DELETE FROM pg_shadow do so. The mistake has only come up two or three times that I can remember, which doesn't elevate it to the category of stuff that I want to install a lot of mechanism to prevent. Especially not mechanism that would get in the way of reasonable uses. I think it's sufficient to have a recovery procedure. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Big problem
, 24.05.2004, 16:12, Tom Lane : Christopher Kings-Lynne [EMAIL PROTECTED] writes: A guy on the IRC channel managed to accidentally click the wrong thing in phpPgAdmin and managed to remove superuser privileges from his only superuser. No sweat; we've seen this one before. Stop postmaster and start a standalone backend. Now you are a superuser, and you can create a new superuser, or just go in and UPDATE pg_shadow to make your original user super again. Exit standalone backend, restart postmaster, have a beer. The question whether we should prevent this from happening stands; I think we should. -- Markus Bertheau [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Big problem
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Hmmm - I agree it's difficult, but somehow I think it's something we should do. Just imagine if some major user of postgres did it - they'd be screaming blue murder... Shrug. Superusers can *always* shoot themselves in the foot in Postgres. Try delete from pg_proc, for instance. This sounds right up there with the notion of preventing a Unix superuser from doing rm -rf /. regards, tom lane ---(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] Big problem
The mistake has only come up two or three times that I can remember, which doesn't elevate it to the category of stuff that I want to install a lot of mechanism to prevent. Especially not mechanism that would get in the way of reasonable uses. I think it's sufficient to have a recovery procedure. Hmmm - I agree it's difficult, but somehow I think it's something we should do. Just imagine if some major user of postgres did it - they'd be screaming blue murder... We could always implement it without locks, thereby taking care of 99.9% of the times it might happen, with still the availability of a cure even if they manage to get through that... Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Big problem
On Mon, 24 May 2004, Tom Lane wrote: I think the cure would probably be worse than the disease. To make any serious attempt at preventing remove-the-last-superuser, we'd have to make operations on pg_shadow grab exclusive lock. For instance, you couldn't allow two backends to DROP USER in parallel; they might be dropping the last two superusers, but neither one would think it was creating a problem. And while we could theoretically make CREATE/ALTER/DROP USER take such locks, I dunno how you make a straight DELETE FROM pg_shadow do so. Isn't it just enough to prevent the user with userid 1 from losing the superuser status. If one want to allow it one could prevent it just when doing the ALTER USER stuff and allow it when editing pg_shadow directly. Or maybe have some guc variable that write locks the user with id 1. Given that it was so simple to restore I'm not sure if it's worth it or not, but restricting just user 1 does not give any of the problems you wrote about. -- /Dennis Björklund ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Big problem
Isn't it just enough to prevent the user with userid 1 from losing the superuser status. If one want to allow it one could prevent it just when doing the ALTER USER stuff and allow it when editing pg_shadow directly. Or maybe have some guc variable that write locks the user with id 1. That gets my vote - can't take superuser off id 1... Given that it was so simple to restore I'm not sure if it's worth it or not, but restricting just user 1 does not give any of the problems you wrote about. Well, sergio sure wasn't very happy... And if I ever get around to my patch that separates out superuser and catalog modification privileges, superusers will no longer necessarily be able to 'delete from pg_proc'; Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] New horology failure
[resending...] On Sun, 23 May 2004 11:38:51 +0800, Christopher Kings-Lynne [EMAIL PROTECTED] wrote: I get this since Tom's commit. --- ./results/horology.out Sun May 23 11:39:49 2004 *** *** 1787,1796 ! | Sat Sep 22 18:19:20 2001 PDT | @ 34 years| Fri Sep 22 18:19:20 1967 PDT [...] --- 1787,1796 ! | Sat Sep 22 18:19:20 2001 PDT | @ 34 years| Fri Sep 22 18:19:20 1967 PST [...] I got the same with snapshot-20040521 yesterday [i.e. 2004-05-22] afternoon when I ran make check. But only once. make installcheck passed all tests, and the failure didn't reappear when I tried make check again. I just got the failure again with make check after having configured with a new install directory. My guess is that horology needs some datafile from the install location. Servus Manfred ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] zero-column table behavior
[resending...] On Sat, 22 May 2004 20:28:43 -0400, Neil Conway [EMAIL PROTECTED] wrote: -- Why is there a blank line before the -- that indicates the -- end of the result set? -- separates the header line from the *start* of the result set. The empty line is the header line, containing zero column headers. -- If the result set contains two rows, ISTM the psql output -- should emit either two or three blank lines before the -- -- that indicates the end of the result set One empty header line before -- and then two empty data lines. Servus Manfred ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Optimizer bug??
Hi everybody,1 EXPLAIN SELECT COUNT(*) AS c FROM articletbl WHERE ((mydate BETWEEN '2004-04-24' AND '2004-05-24' ))2 EXPLAIN SELECT COUNT(*) AS c FROM articletbl WHERE ((mydate = '2004-04-24'))(I ran VACUUM ANALYZE before running those)mydate is an indexed date column.The optimizer optimizes the second query but, it doesn't optimize the firstone and decides to make a "sequential scan".Is this a bug?Or may someone explain me the reason?Thanks in advance.Ismail Kizir
Re: [HACKERS] Optimizer bug??
Ismail Kizir wrote: Hi everybody, 1 EXPLAIN SELECT COUNT(*) AS c FROM articletbl WHERE ((mydate BETWEEN '2004-04-24' AND '2004-05-24' ) ) 2 EXPLAIN SELECT COUNT(*) AS c FROM articletbl WHERE ((mydate = '2004-04-24') ) (I ran VACUUM ANALYZE before running those) mydate is an indexed date column. The optimizer optimizes the second query but, it doesn't optimize the first one and decides to make a sequential scan. Is this a bug? Or may someone explain me the reason? Thanks in advance. Ismail Kizir If 2004-04-24 to 2004-05-24 make up let's say 90% of your data PostgreSQL will find out that it is cheaper to use a seq scan instead of an index. This is not a bug at all - this is normal and desired behaviour ... Regards, Hans -- Cybertec Geschwinde u Schoenig Schoengrabern 134, A-2020 Hollabrunn, Austria Tel: +43/720/10 1234567 or +43/664/233 90 75 www.cybertec.at, www.postgresql.at, kernel.cybertec.at ---(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] Big problem
Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: Hmmm - I agree it's difficult, but somehow I think it's something we should do. Just imagine if some major user of postgres did it - they'd be screaming blue murder... Shrug. Superusers can *always* shoot themselves in the foot in Postgres. Try delete from pg_proc, for instance. This sounds right up there with the notion of preventing a Unix superuser from doing rm -rf /. I have to agree. FWIW, I've seen a unix superuser do a recursive chmod 777 on /, and I've seen a Windows server admin recursively deny EVERYTHING from EVERYBODY starting at c:\. In both cases, we found that's why we keep regular backups ;-) Joe ---(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] Optimizer bug??
Thanks Hans, The optimizer does an indexed scan up to 20 days, and then, it decides to make a sequential scan. But i am still not sure about the efficiency of this decision. Here is a list of number of items on a daily basis: 2002-10-20;151 2002-10-19;163 2002-10-18;175 2002-10-17;183 2002-10-16;186 2002-10-15;159 2002-10-14;179 2002-10-13;133 2002-10-12;130 2002-10-11;173 2002-10-10;145 2002-10-09;178 2002-10-08;197 2002-10-07;159 2002-10-06;155 2002-10-05;150 2002-10-04;194 2002-10-03;211 2002-10-02;197 2002-10-01;192 2002-09-30;169 2002-09-29;148 2002-09-28;179 2002-09-27;174 2002-09-26;224 2002-09-25;206 2002-09-24;286 2002-09-23;220 2002-09-22;242 2002-09-21;252 2002-09-20;306 2002-09-19;289 2002-09-18;298 2002-09-17;307 2002-09-16;257 2002-09-15;257 2002-09-14;264 2002-09-13;297 2002-09-12;289 2002-09-11;284 2002-09-10;256 2002-09-09;251 2002-09-08;374 2002-09-07;250 2002-09-06;248 2002-09-05;269 2002-09-04;291 2002-09-03;286 2002-09-02;268 2002-09-01;258 2002-08-31;259 2002-08-30;259 2002-08-29;284 2002-08-28;285 2002-08-27;271 2002-08-26;248 2002-08-25;258 2002-08-24;256 2002-08-23;296 2002-08-22;269 2002-08-21;291 2002-08-20;209 2002-08-19;190 2002-08-18;182 2002-08-17;189 2002-08-16;195 2002-08-15;217 2002-08-14;222 2002-08-13;221 2002-08-12;210 2002-08-11;190 2002-08-10;183 2002-08-09;189 2002-08-08;227 2002-08-07;245 2002-08-06;235 2002-08-05;209 2002-08-04;193 2002-08-03;189 2002-08-02;233 2002-08-01;227 2002-07-31;233 2002-07-30;234 2002-07-29;200 2002-07-28;193 2002-07-27;200 2002-07-26;216 2002-07-25;220 2002-07-24;219 2002-07-23;201 2002-07-22;205 2002-07-21;197 2002-07-20;204 2002-07-19;231 2002-07-18;244 2002-07-17;238 2002-07-16;242 2002-07-15;304 2002-07-14;168 2002-07-13;195 2002-07-12;188 2002-07-11;205 2002-07-10;234 2002-07-09;200 2002-07-08;189 2002-07-07;175 2002-07-06;193 2002-07-05;195 2002-07-04;220 2002-07-03;214 2002-07-02;220 2002-07-01;176 2002-06-30;169 2002-06-29;187 2002-06-28;193 2002-06-27;193 2002-06-26;187 2002-06-25;189 2002-06-24;178 2002-06-23;168 2002-06-22;185 2002-06-21;197 2002-06-20;206 2002-06-19;172 2002-06-18;180 2002-06-17;179 2002-06-16;163 2002-06-15;197 2002-06-14;209 2002-06-13;199 2002-06-12;244 2002-06-11;232 2002-06-10;182 2002-06-09;176 2002-06-08;185 2002-06-07;218 2002-06-06;206 2002-06-05;216 2002-06-04;227 2002-06-03;164 2002-06-02;163 2002-06-01;199 2002-05-31;184 2002-05-30;198 2002-05-29;212 2002-05-28;204 2002-05-27;196 2002-05-26;172 2002-05-25;161 2002-05-24;196 2002-05-23;207 2002-05-22;200 2002-05-21;221 2002-05-20;198 2002-05-19;161 2002-05-18;179 2002-05-17;183 2002-05-16;226 2002-05-15;239 2002-05-14;208 2002-05-13;203 2002-05-12;191 2002-05-11;179 2002-05-10;216 2002-05-09;209 2002-05-08;236 2002-05-07;199 2002-05-06;176 2002-05-05;175 2002-05-04;188 2002-05-03;192 2002-05-02;196 2002-05-01;232 2002-04-30;209 2002-04-29;201 2002-04-28;187 2002-04-27;217 2002-04-26;158 2002-04-25;206 2002-04-24;232 2002-04-23;203 2002-04-22;196 2002-04-21;224 2002-04-20;189 2002-04-19;188 2002-04-18;218 2002-04-17;209 2002-04-16;153 2002-04-15;200 2002-04-14;159 2002-04-13;220 2002-04-12;172 2002-04-11;239 2002-04-10;246 2002-04-09;249 2002-04-08;164 2002-04-07;202 2002-04-06;189 2002-04-05;231 2002-04-04;221 2002-04-03;185 2002-04-02;205 2002-04-01;183 2002-03-31;182 2002-03-30;230 2002-03-29;199 2002-03-28;233 2002-03-27;216 2002-03-26;232 2002-03-25;208 2002-03-24;190 2002-03-23;199 2002-03-22;193 2002-03-21;183 2002-03-20;217 2002-03-19;212 2002-03-18;166 2002-03-17;185 2002-03-16;202 2002-03-15;197 2002-03-14;178 2002-03-13;205 2002-03-12;211 2002-03-11;180 2002-03-10;154 2002-03-09;155 2002-03-08;144 2002-03-07;190 2002-03-06;190 2002-03-05;188 2002-03-04;177 2002-03-03;163 2002-03-02;171 2002-03-01;188 2002-02-28;208 2002-02-27;197 2002-02-26;131 2002-02-25;122 2002-02-24;141 2002-02-23;134 2002-02-22;148 2002-02-21;168 2002-02-20;183 2002-02-19;180 2002-02-18;177 2002-02-17;163 2002-02-16;148 2002-02-15;173 2002-02-14;178 2002-02-13;170 2002-02-12;164 2002-02-11;164 2002-02-10;188 2002-02-09;231 2002-02-08;228 2002-02-07;212 2002-02-06;240 2002-02-05;227 2002-02-04;210 2002-02-03;184 2002-02-02;276 2002-02-01;189 2002-01-31;242 2002-01-30;240 2002-01-29;238 2002-01-28;211 2002-01-27;197 2002-01-26;220 2002-01-25;220 2002-01-24;230 2002-01-23;224 2002-01-22;233 2002-01-21;209 2002-01-20;187 2002-01-19;225 2002-01-18;184 2002-01-17;233 2002-01-16;218 2002-01-15;195 2002-01-14;212 2002-01-13;192 2002-01-12;200 2002-01-11;205 2002-01-10;200 2002-01-09;185 2002-01-08;215 2002-01-07;222 2002-01-06;177 2002-01-05;203 2002-01-04;314 2002-01-03;308 2002-01-02;326 2002-01-01;362 2004-05-24;212 2004-05-19;123 2004-05-18;159 2004-05-17;506 2004-05-16;774 2004-05-15;871 2004-05-14;756 2004-05-13;724 2004-05-12;871 2004-05-11;791 2004-05-10;676 2004-05-09;847 2004-05-08;729 2004-05-07;692 2004-05-06;760 2004-05-05;711 2004-05-04;789 2004-05-03;567 2004-05-02;788 2004-05-01;721 2004-04-30;773 2004-04-29;843 2004-04-28;843 2004-04-27;915 2004-04-26;709
Re: [HACKERS] Optimizer bug??
Ismail Kizir [EMAIL PROTECTED] writes: Thanks Hans, The optimizer does an indexed scan up to 20 days, and then, it decides to make a sequential scan. What are the results of explain analyze query for the various queries? -- greg ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Big problem
On Mon, May 24, 2004 at 11:23:09AM -0700, Joe Conway wrote: Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: Hmmm - I agree it's difficult, but somehow I think it's something we should do. Just imagine if some major user of postgres did it - they'd be screaming blue murder... Shrug. Superusers can *always* shoot themselves in the foot in Postgres. Try delete from pg_proc, for instance. This sounds right up there with the notion of preventing a Unix superuser from doing rm -rf /. FWIW, I've seen a unix superuser do a recursive chmod 777 on /, and I've seen a Windows server admin recursively deny EVERYTHING from EVERYBODY starting at c:\. In both cases, we found that's why we keep regular backups ;-) I've personally done rm -fr /, but this doesn't mean we couldn't do better than imitate Unix permission scheme. In fact, latest efforts are trying to get rid of a all-powerful superuser by using more granular capabilities. Maybe we don't need to exclusive-lock the entire ALTER USER operation; perhaps a lock escalation method could be used. OTOH I agree this particular problem may not need a solution. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) La grandeza es una experiencia transitoria. Nunca es consistente. Depende en gran parte de la imaginación humana creadora de mitos (Irulan) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Optimizer bug??
On Mon, May 24, 2004 at 08:27:01PM +0300, Ismail Kizir wrote: The optimizer does an indexed scan up to 20 days, and then, it decides to make a sequential scan. But i am still not sure about the efficiency of this decision. Huh, so what was the EXPLAIN ANALYZE of the query with BETWEEN? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Syntax error: function hell() needs an argument. Please choose what hell you want to involve. ---(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] New horology failure
I get this since Tom's commit. --- ./results/horology.out Sun May 23 11:39:49 2004 *** *** 1787,1796 ! | Sat Sep 22 18:19:20 2001 PDT | @ 34 years | Fri Sep 22 18:19:20 1967 PDT [...] --- 1787,1796 ! | Sat Sep 22 18:19:20 2001 PDT | @ 34 years | Fri Sep 22 18:19:20 1967 PST [...] I got the same with snapshot-20040521 yesterday [i.e. 2004-05-22] afternoon when I ran make check. But only once. make installcheck passed all tests, and the failure didn't reappear when I tried make check again. I just got the failure again with make check after having configured with a new install directory. My guess is that horology needs some datafile from the install location. Not only a file, but the entire directory pginstall/share/timezone, with subdirs. Without it, it will parse PST8PDT using the default DST rules. If it finds the file (named PST8PDT in that directory), it will use the correct DST rules. //Magnus ---(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] Optimizer bug??
Alvaro, For the query : EXPLAIN SELECT count(tarih) AS c FROM articletbl WHERE sitekodu = 12 AND ((tarih='2004-04-24' AND tarih'2004-05-24' )) QUERY PLAN is Aggregate (cost=41619.34..41619.34 rows=1 width=4) - Seq Scan on articletbl (cost=0.00..41618.46 rows=353 width=4) Filter: ((sitekodu = 12) AND (tarih = '2004-04-24'::date) AND (tarih '2004-05-24'::date)) And for the query : EXPLAIN SELECT count(tarih) AS c FROM articletbl WHERE sitekodu = 12 AND ((tarih='2004-05-10' AND tarih'2004-05-24' )) QUERY PLAN Aggregate (cost=20279.72..20279.72 rows=1 width=4) - Index Scan using ind_articletbltrh on articletbl (cost=0.00..20279.40 rows=127 width=4) Index Cond: ((tarih = '2004-05-10'::date) AND (tarih '2004-05-24'::date)) Filter: (sitekodu = 12) Have you got an idea? Thanks in advance Ismail Kizir - Original Message - From: Alvaro Herrera [EMAIL PROTECTED] To: Ismail Kizir [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, May 24, 2004 9:23 PM Subject: Re: [HACKERS] Optimizer bug?? On Mon, May 24, 2004 at 08:27:01PM +0300, Ismail Kizir wrote: The optimizer does an indexed scan up to 20 days, and then, it decides to make a sequential scan. But i am still not sure about the efficiency of this decision. Huh, so what was the EXPLAIN ANALYZE of the query with BETWEEN? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Syntax error: function hell() needs an argument. Please choose what hell you want to involve. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(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] Optimizer bug??
Ismail Kizir wrote: Hi everybody, 1 EXPLAIN SELECT COUNT(*) AS c FROM articletbl WHERE ((mydate BETWEEN '2004-04-24' AND '2004-05-24' ) ) 2 EXPLAIN SELECT COUNT(*) AS c FROM articletbl WHERE ((mydate = '2004-04-24') ) (I ran VACUUM ANALYZE before running those) mydate is an indexed date column. The optimizer optimizes the second query but, it doesn't optimize the first one and decides to make a sequential scan. Is this a bug? Or may someone explain me the reason? give us the result of these queries: SELECT COUNT(*) FROM articletbl; SELECT COUNT(*) AS c FROM articletbl WHERE mydate BETWEEN '2004-04-24' AND '2004-05-24'; SELECT COUNT(*) AS c FROM articletbl WHERE mydate = '2004-04-24'; Regards Gaetano Mendola ---(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] Big problem
Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: Hmmm - I agree it's difficult, but somehow I think it's something we should do. Just imagine if some major user of postgres did it - they'd be screaming blue murder... Shrug. Superusers can *always* shoot themselves in the foot in Postgres. Try delete from pg_proc, for instance. This sounds right up there with the notion of preventing a Unix superuser from doing rm -rf /. Why not simply add a flag undeleteable applicable only to super user? In this way is enough in the initdb fase create the postgres user as undeleateable. I think this is resonable. Regards Gaetano Mendola ---(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] Optimizer bug??
Hi all, give us the result of these queries: SELECT COUNT(*) FROM articletbl; 268726 records, it takes 34169 ms. to compute this SELECT COUNT(*) AS c FROM articletbl WHERE mydate BETWEEN '2004-04-24' AND '2004-05-24'; 18982 records, it takes 34249 ms. to compute this. SELECT COUNT(*) AS c FROM articletbl WHERE mydate = '2004-04-24'; 850 records, it takes only 40 ms. to compute this. It is evident that there is a problem here! Am I wrong?? Regards Ismail Kizir ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Optimizer bug??
On Mon, 24 May 2004, Ismail Kizir wrote: Hi all, give us the result of these queries: SELECT COUNT(*) FROM articletbl; 268726 records, it takes 34169 ms. to compute this SELECT COUNT(*) AS c FROM articletbl WHERE mydate BETWEEN '2004-04-24' AND '2004-05-24'; 18982 records, it takes 34249 ms. to compute this. SELECT COUNT(*) AS c FROM articletbl WHERE mydate = '2004-04-24'; 850 records, it takes only 40 ms. to compute this. It is evident that there is a problem here! Am I wrong?? What does explain analyze show for the between query (not just explain) and what does it show if enable_seqscan is set to false? It's possible that it's badly overestimating the cost of the range query, but that's hard to say at this point. There is a point at which in general an index scan becomes more costly than a sequence scan, and it's possible to move that point by changing optimizer settings in the configuration. ---(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] Optimizer bug??
Ismail Kizir wrote: Hi all, give us the result of these queries: SELECT COUNT(*) FROM articletbl; 268726 records, it takes 34169 ms. to compute this SELECT COUNT(*) AS c FROM articletbl WHERE mydate BETWEEN '2004-04-24' AND '2004-05-24'; 18982 records, it takes 34249 ms. to compute this. SELECT COUNT(*) AS c FROM articletbl WHERE mydate = '2004-04-24'; 850 records, it takes only 40 ms. to compute this. It is evident that there is a problem here! Am I wrong?? Try to do an explain analyze for both queries, and repeat the explain analyze but before disable the sequential scan ( set enable_seq_scan=off ). For sure what do you have is extimated cost higher, what do you have to do is decrease that cost, try with these values: random_page_cost = 2.5 cpu_tuple_cost = 0.005 cpu_index_tuple_cost = 0.0005 cpu_operator_cost = 0.0025 these are values that are good for a modern machine. Hackers, what about to decrease the default values for this quantities ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Big problem
Christopher Kings-Lynne wrote: The mistake has only come up two or three times that I can remember, which doesn't elevate it to the category of stuff that I want to install a lot of mechanism to prevent. Especially not mechanism that would get in the way of reasonable uses. I think it's sufficient to have a recovery procedure. Hmmm - I agree it's difficult, but somehow I think it's something we should do. Just imagine if some major user of postgres did it - they'd be screaming blue murder... IMHO we (that is Christopher, me and others maintaining easy to (mis)use tools) should warn the users about what they're going to do. Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] New horology failure
Magnus Hagander [EMAIL PROTECTED] writes: I just got the failure again with make check after having configured with a new install directory. My guess is that horology needs some datafile from the install location. Not only a file, but the entire directory pginstall/share/timezone, with subdirs. Hmm, maybe the problem is that the tz files aren't installed into the right place during make check? Or the temp postmaster fails to look in the right place? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Big problem
IMHO we (that is Christopher, me and others maintaining easy to (mis)use tools) should warn the users about what they're going to do. Yes, I'm going to have to modify phpPgAdmin methinks. Chris ---(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
[HACKERS] log_statement and Parse/Bind
I notice that when using the extended query protocol, statement logging appears to happen only when a Parse message is received. This is less than ideal: - statements can be logged that are not actually executed (i.e. a Parse/Bind with no corresponding Execute). - if statements are re-executed without an intervening Parse (i.e. Parse/Bind/Execute/Bind/Execute/...), only the first execution is logged. There's also a lesser problem with using parameterized queries: the actual parameter values used in a Bind are not visible. This is the same as the PREPARE/EXECUTE case, except that it's more likely to be done transparently by the client's interface library (so we can't just tell the application developer don't do that, then!) Are there any plans to change this? Should I look at making a change along the lines of logging the statement on the first Execute of a portal, instead of on Parse? -O ---(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
[HACKERS] Ingres to be released as open source
[ BCC to hackers and advocacy.] Ingres is to be released as open source: http://developers.slashdot.org/article.pl?sid=04/05/25/0043219mode=nestedtid=126tid=137tid=163tid=185tid=198 -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] New horology failure
Magnus Hagander [EMAIL PROTECTED] writes: I get this since Tom's commit. Ah-hah. It fails if you do make check and have not got any installation at the configured place, *and* the configured place isn't under someplace like /home/postgres. The reason is that relative_path doesn't work. On my test system, configured with --prefix = '/home/tgl/testversion', we end up with PGBINDIR = '/home/tgl/testversion/bin' PGSHAREDIR = '/home/tgl/testversion/share/postgresql' because Makefile.global attaches /postgresql to PGSHAREDIR. The discrepancy in path length causes relative_path to return false ... and even if it returned true, get_share_path would do the wrong thing, because it assumes it need only append /share after stripping /bin. The reason this only affects timezone is that there isn't anything else in /share that the backend needs to access. However I'm not quite sure why get_pkglib_path seems not to be having the same confusion... In short the relative path stuff still needs a lot more work. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] New horology failure
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: I get this since Tom's commit. Ah-hah. It fails if you do make check and have not got any installation at the configured place, *and* the configured place isn't under someplace like /home/postgres. The reason is that relative_path doesn't work. On my test system, configured with --prefix = '/home/tgl/testversion', we end up with PGBINDIR = '/home/tgl/testversion/bin' PGSHAREDIR = '/home/tgl/testversion/share/postgresql' because Makefile.global attaches /postgresql to PGSHAREDIR. The discrepancy in path length causes relative_path to return false ... and even if it returned true, get_share_path would do the wrong thing, because it assumes it need only append /share after stripping /bin. The reason this only affects timezone is that there isn't anything else in /share that the backend needs to access. However I'm not quite sure why get_pkglib_path seems not to be having the same confusion... In short the relative path stuff still needs a lot more work. Well, in the case you have an install prefix of /usr, we wouldn't want relative installs because you would have /usr/bin and /usr/lib/postgresql and that wouldn't be relocatable. I think the weird part is appending /postgresql on any install that doesn't already have a pgsql/postgresql in the directory path. That is pretty weird, and doesn't interact well with the relocation code. However, I can't think of a good way to clean that up. -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] log_statement and Parse/Bind
Bruce Momjian wrote: Well, at execute time, we don't have easy access to the original prepare statement, especially at that stage in the code. Do you see anyway to improve that? We have portal-sourceText which looks like it should contain the original query. (note that I'm talking about the V3 protocol Execute message, not the SQL EXECUTE command) -o ---(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] log_statement and Parse/Bind
Oliver Jowett wrote: I notice that when using the extended query protocol, statement logging appears to happen only when a Parse message is received. This is less than ideal: - statements can be logged that are not actually executed (i.e. a Parse/Bind with no corresponding Execute). - if statements are re-executed without an intervening Parse (i.e. Parse/Bind/Execute/Bind/Execute/...), only the first execution is logged. There's also a lesser problem with using parameterized queries: the actual parameter values used in a Bind are not visible. This is the same as the PREPARE/EXECUTE case, except that it's more likely to be done transparently by the client's interface library (so we can't just tell the application developer don't do that, then!) Are there any plans to change this? Should I look at making a change along the lines of logging the statement on the first Execute of a portal, instead of on Parse? Well, at execute time, we don't have easy access to the original prepare statement, especially at that stage in the code. Do you see anyway to improve that? -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] New horology failure
I said: The reason this only affects timezone is that there isn't anything else in /share that the backend needs to access. However I'm not quite sure why get_pkglib_path seems not to be having the same confusion... Actually, get_pkglib_path is wrong too. But the regression tests do not exercise it. There are two places that probably *should* exercise it: the creation of the character set conversion functions during initdb and the creation of the plpgsql call handler function. In normal situations I'd expect both of these to be relative to $libdir (hence pkglib_path). But the regression test script carefully overrides that. Maybe we should consider taking out the override --- it wouldn't be needed anymore if the relative-path stuff were doing its thing correctly. 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] Ingres to be released as open source
Ingres is to be released as open source: http://developers.slashdot.org/article.pl?sid=04/05/25/0043219mode=nestedtid=126tid=137tid=163tid=185tid=198 Like the article says, I wonder if these is any synergy between the products. ie. Can we grab features from their codebase? Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] New horology failure
Bruce Momjian [EMAIL PROTECTED] writes: Well, in the case you have an install prefix of /usr, we wouldn't want relative installs because you would have /usr/bin and /usr/lib/postgresql and that wouldn't be relocatable. Why not? ISTM that the algorithm should go something like this: 1. Take PGBINDIR and strip off the last component (presumably bin). 2. See if this matches the configured SHAREDIR, PKGLIBDIR, or whatever *for as many components as are in the stripped BINDIR*. Do not assume that SHAREDIR must have the same number of components. 3. If match, then what you should do is use the remaining unmatched part of SHAREDIR etc as what to append to the trimmed exec_path. For example given the test situation I had: PGBINDIR = '/home/tgl/testversion/bin' PGSHAREDIR = '/home/tgl/testversion/share/postgresql' my_exec_path = '/home/tgl/pgsql-list/src/test/regress/./tmp_check/install//home/tgl/testversion/bin/postmaster' ret_path = '/home/tgl/testversion/share/postgresql' what *should* have happened was compare /home/tgl/testversion to /home/tgl/testversion, decide they agree, and extract share/postgresql as the part to attach to my_exec_path. Then you'd strip two components from my_exec_path (bin and program name) and attach share/postgresql. Voila ... right answer. 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] log_statement and Parse/Bind
Oliver Jowett [EMAIL PROTECTED] writes: I notice that when using the extended query protocol, statement logging appears to happen only when a Parse message is received. This is less than ideal: I agree, but I didn't have time at the end of the 7.4 development cycle to work out what should happen. I do not think that regurgitating the statement three times would make anyone very happy, so some thought has to go into what's appropriate. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Timezone fun (bugs and a request)
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: First I initdb'd without TZ set. So every time I start the server I get LOG: could not recognize system timezone, defaulting to Etc/GMT-4 HINT: You can specify the correct timezone in postgresql.conf. I've fixed the minor issue here, which is that the sign is backwards --- it ought to select Etc/GMT+4. The larger issue is that it's not recognizing your system timezone because the only name it can cons up for the zone is CLT4CLST, which doesn't work because it has the wrong DST rules. (I think it's just luck that it realizes that, actually :-(). With a freshly updated CVS tree I get the wrong sign on the timezone here: LOG: could not recognize system timezone, defaulting to Etc/GMT-12 HINT: You can specify the correct timezone in postgresql.conf. LOG: database system was shut down at 2004-05-25 15:15:44 GMT-12 My timezone is NZST which is GMT+12. TZ is not set. This is a Debian box with libc-2.3.2. [EMAIL PROTECTED]:~$ ls -l /etc/localtime lrwxrwxrwx1 root root 36 Feb 2 17:08 /etc/localtime - /usr/share/zoneinfo/Pacific/Auckland [EMAIL PROTECTED]:~$ date Tue May 25 15:14:53 NZST 2004 [EMAIL PROTECTED]:~$ date +'%c %z' Tue May 25 15:30:11 2004 +1200 Also, unless I'm missing something, shouldn't Chile (Alvaro's timezone?) be behind GMT (GMT-something) not ahead of it (GMT+something)? -O ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Dump problems with superusers
Hi, There are several objects in PostgreSQL that you can only create if you are a superuser, eg. procedural languages. If you do this, you break the dump: 1. create a superuser 2. install a language as that superuser 3. drop the superuser privs from that superuser 4. dump the database 5. attempt to restore the database It fails because this is what gets dumped: CREATE USER test WITH SYSID 100 NOCREATEDB NOCREATEUSER; ... SET SESSION AUTHORIZATION 'test'; CREATE FUNCTION plpgsql_call_handler() RETURNS language_handler AS '$libdir/plpgsql', 'plpgsql_call_handler' LANGUAGE c; CREATE FUNCTION plpgsql_validator(oid) RETURNS void AS '$libdir/plpgsql', 'plpgsql_validator' LANGUAGE c; SET SESSION AUTHORIZATION DEFAULT; CREATE TRUSTED PROCEDURAL LANGUAGE plpgsql HANDLER plpgsql_call_handler VALIDATOR plpgsql_validator; Now it cannot restore the dump as the 'test' user no longer has permissions to do so. Chris ---(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] Timezone fun (bugs and a request)
Oliver Jowett [EMAIL PROTECTED] writes: Also, unless I'm missing something, shouldn't Chile (Alvaro's timezone?) be behind GMT (GMT-something) not ahead of it (GMT+something)? Part of the confusion here is that the zone names in the zic database follow POSIX rules: plus is west of Greenwich. AFAICS it's doing the right thing in selecting Etc/GMT-12 for you. Have you checked the actual time values reported by the server to see if they look okay? I'm a bit hesitant to reverse the sign convention in the zic database to agree with SQL conventions --- that seems certain to lead to even more confusion. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New horology failure
OK, I will work on that. With everything now centralized it should be easier. --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Well, in the case you have an install prefix of /usr, we wouldn't want relative installs because you would have /usr/bin and /usr/lib/postgresql and that wouldn't be relocatable. Why not? ISTM that the algorithm should go something like this: 1. Take PGBINDIR and strip off the last component (presumably bin). 2. See if this matches the configured SHAREDIR, PKGLIBDIR, or whatever *for as many components as are in the stripped BINDIR*. Do not assume that SHAREDIR must have the same number of components. 3. If match, then what you should do is use the remaining unmatched part of SHAREDIR etc as what to append to the trimmed exec_path. For example given the test situation I had: PGBINDIR = '/home/tgl/testversion/bin' PGSHAREDIR = '/home/tgl/testversion/share/postgresql' my_exec_path = '/home/tgl/pgsql-list/src/test/regress/./tmp_check/install//home/tgl/testversion/bin/postmaster' ret_path = '/home/tgl/testversion/share/postgresql' what *should* have happened was compare /home/tgl/testversion to /home/tgl/testversion, decide they agree, and extract share/postgresql as the part to attach to my_exec_path. Then you'd strip two components from my_exec_path (bin and program name) and attach share/postgresql. Voila ... right answer. regards, tom lane -- 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 4: Don't 'kill -9' the postmaster
[HACKERS] pg_ctl.c
I am almost finished Andrew's version of pg_ctl.c. Here is the current
version I am using.
--
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
/*-
*
* pg_ctl --- start/stops/restarts the PostgreSQL server
*
* Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group
*
* $PostgreSQL: pgsql-server/src/bin/initdb/initdb.c,v 1.32 2004/05/18 03:36:36
momjian Exp $
*
*-
*/
#include libpq-fe.h
#include postgres_fe.h
#include signal.h
#include errno.h
#include libpq/pqsignal.h
#include string.h
#include sys/types.h
#include sys/stat.h
#define _(x) gettext((x))
/* postmaster version ident string */
#define PM_VERSIONSTR postmaster (PostgreSQL) PG_VERSION \n
typedef enum
{
SMART_MODE,
FAST_MODE,
IMMEDIATE_MODE
} ShutdownMode;
typedef enum
{
NO_COMMAND = 0,
START_COMMAND,
STOP_COMMAND,
RESTART_COMMAND,
RELOAD_COMMAND,
STATUS_COMMAND,
KILL_COMMAND
} CtlCommand;
static bool do_wait = false;
static bool wait_set = false;
static int wait_seconds = 60;
static bool silence_echo = false;
static ShutdownMode shutdown_mode = SMART_MODE;
static int sig;
static int killproc;
static CtlCommand ctl_command = NO_COMMAND;
static char *pg_data_opts = NULL;
static char *pg_data = NULL;
static char *post_opts = NULL;
static const char *progname;
static char *log_file = NULL;
static char *postgres_path = NULL;
static char *argv0 = NULL;
static void *xmalloc(size_t size);
static char *xstrdup(const char *s);
static void do_advice(void);
static void do_help(void);
static void set_mode(char *modeopt);
static void set_sig(char *signame);
static void do_start();
static void do_stop(void);
static void do_restart(void);
static void do_reload(void);
static void do_status(void);
static void do_kill(void);
static long get_pgpid(void);
static char **readfile(char *path);
static void start_postmaster(void);
static bool test_postmaster_connection(void);
static char def_postopts_file[MAXPGPATH];
static char postopts_file[MAXPGPATH];
static char pid_file[MAXPGPATH];
static char conf_file[MAXPGPATH];
/*
* routines to check mem allocations and fail noisily.
*
*/
static void *
xmalloc(size_t size)
{
void *result;
result = malloc(size);
if (!result)
{
fprintf(stderr, _(%s: out of memory\n), progname);
exit(1);
}
return result;
}
static char *
xstrdup(const char *s)
{
char *result;
result = strdup(s);
if (!result)
{
fprintf(stderr, _(%s: out of memory\n), progname);
exit(1);
}
return result;
}
static long
get_pgpid(void)
{
FILE *pidf;
longpid;
pidf = fopen(pid_file, r);
if (pidf == NULL)
{
/* No pid file, not an error */
if (errno == ENOENT)
return 0;
else
{
perror(openning pid file);
exit(1);
}
}
fscanf(pidf, %ld, pid);
fclose(pidf);
return pid;
}
/*
* get the lines from a text file - return NULL if file can't be opened
*/
static char **
readfile(char *path)
{
FILE *infile;
int maxlength = 0,
linelen = 0;
int nlines = 0;
char **result;
char *buffer;
int c;
if ((infile = fopen(path, r)) == NULL)
return NULL;
/* pass over the file twice - the first time to size the result */
while ((c = fgetc(infile)) != EOF)
{
linelen++;
if (c == '\n')
{
nlines++;
if (linelen maxlength)
maxlength = linelen;
linelen = 0;
}
}
/* handle last line without a terminating newline (yuck) */
if (linelen)
nlines++;
if (linelen maxlength)
maxlength = linelen;
/* set up the result and the line buffer */
result = (char **) xmalloc((nlines + 1) * sizeof(char *));
buffer = (char *) xmalloc(maxlength + 1);
/* now reprocess the file and store the lines */
rewind(infile);
nlines = 0;
while (fgets(buffer, maxlength + 1, infile) != NULL)
result[nlines++] = xstrdup(buffer);
Re: [HACKERS] Timezone fun (bugs and a request)
Tom Lane wrote: Oliver Jowett [EMAIL PROTECTED] writes: Also, unless I'm missing something, shouldn't Chile (Alvaro's timezone?) be behind GMT (GMT-something) not ahead of it (GMT+something)? Part of the confusion here is that the zone names in the zic database follow POSIX rules: plus is west of Greenwich. AFAICS it's doing the right thing in selecting Etc/GMT-12 for you. Ew! That's disgusting! What possessed POSIX to do this the opposite way to pretty much everything else? Have you checked the actual time values reported by the server to see if they look okay? Indeed, the timezone is actually correct: oliver=# select now(); now --- 2004-05-25 16:08:05.688408+12 (1 row) What confused me is that the times in the log don't follow the SQL-and-everything-else convention: LOG: database system was shut down at 2004-05-25 15:15:44 GMT-12 For comparison, 7.4.1 on the same system says: LOG: database system was shut down at 2004-05-25 16:03:43 NZST and apache says: 127.0.0.1 - - [25/May/2004:16:06:16 +1200] GET / HTTP/1.0 200 4110 - Wget/1.9.1 I'm a bit hesitant to reverse the sign convention in the zic database to agree with SQL conventions --- that seems certain to lead to even more confusion. Can we keep the zic database convention unchanged but change the display format in the logs to be consistent with the SQL conventions? -O ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Timezone fun (bugs and a request)
Oliver Jowett [EMAIL PROTECTED] writes: What confused me is that the times in the log don't follow the SQL-and-everything-else convention: LOG: database system was shut down at 2004-05-25 15:15:44 GMT-12 For comparison, 7.4.1 on the same system says: LOG: database system was shut down at 2004-05-25 16:03:43 NZST Right now, to get that you need to set a TimeZone setting that will select the appropriate New Zealand time zone by name. (I think 'Pacific/Auckland' is the one you want.) Hopefully we will find some way of deducing the correct time zone name more automatically, but right now it's a work in progress. 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
