Re: [HACKERS] droped out precise time calculations in src/interfaces/libpq/fe-connect.c
On Sun, Oct 13, 2002 at 10:59:40PM -0700, Joe Conway wrote: Well, if we were specifying the timeout in microseconds instead of seconds, it would make sense to have better resolution. But when you can only specify the timeout in seconds, the internal time comparison doesn't need to be any more accurate than seconds (IMHO anyway). Actually we have the state machine in connectDBComplete() and the timeout is set for machine as the whole. Therefore if 1 second timeout is seted for the connectDBComplete() the timeout of particualr iteration of loop can be less then 1 second. -- Regards Denis ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: Changing Column Order (Was Re: [HACKERS] MySQL vs PostgreSQL.)
On Sat, 2002-10-12 at 11:37, Gavin Sherry wrote: I cannot think of any reason why changing column order should be implemented in Postgres. Seems like a waste of time/more code bloat for something which is strictly asthetic. Regardless, I do have collegues/clients who ask when such a feature will be implemented. Why is this useful? Has column ordering any effect on the physical tuple disposition? I've heard discussions about keeping fixed-size fields at the beginning of the tuple and similar. Sorry for the lame question. :-) -- Alessio F. Bragadini[EMAIL PROTECTED] APL Financial Services http://village.albourne.com Nicosia, Cyprus phone: +357-22-755750 It is more complicated than you think -- The Eighth Networking Truth from RFC 1925 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Denis A Ustimenko [EMAIL PROTECTED] writes: On Sun, Oct 13, 2002 at 10:59:40PM -0700, Joe Conway wrote: Well, if we were specifying the timeout in microseconds instead of seconds, it would make sense to have better resolution. But when you can only specify the timeout in seconds, the internal time comparison doesn't need to be any more accurate than seconds (IMHO anyway). Actually we have the state machine in connectDBComplete() and the timeout is set for machine as the whole. Therefore if 1 second timeout is seted for the connectDBComplete() the timeout of particualr iteration of loop can be less then 1 second. However, the code's been restructured so that we don't need to keep track of the exact time spent in any one iteration. The error is only on the overall delay. I agree with Joe that it's not worth the effort needed (in the Win32 case) to make the timeout accurate to 1 sec. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Let's get 7.3 done
Bruce Momjian [EMAIL PROTECTED] writes: Return last command of INSTEAD rule for tuple count/oid/tag for rules, SPI If we are going to fix it, this week is the time. If not, it stays on TODO. If we've agreed on the behavior, I'll try to take care of making it happen. Note that will mean an initdb for 7.3b3. Add/remove GRANT EXECUTE to all /contrib functions? Who volunteered to clean all this up a while back? I think that now that we changed the default permissions for functions, this is a dead issue. There's no need to put explicit GRANTs into the contrib files. OTOH, taking out the ones that were added already is a waste of cycles too. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Joe Conway wrote: Bruce Momjian wrote: It could be argued that our seconds are not as exact as they could be with subsecond timing. Not sure it is worth it, but I can see the point. Well, if we were specifying the timeout in microseconds instead of seconds, it would make sense to have better resolution. But when you can only specify the timeout in seconds, the internal time comparison doesn't need to be any more accurate than seconds (IMHO anyway). are doing something with microseconds when we are not. Also, should we switch to a simple time() call, rather than gettimeofday()? Already done -- that's what Denis is unhappy about. OK, I see that, but now, we are stuffing everything into a timeval struct. Does that make sense? Shouldn't we just use time_t? I realize we need the timeval struct for select() in pqWaitTimed, but we are making a copy of the timeval we pass in anyway. Seems it would be easier just making it a time_t. -- 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
Re: Changing Column Order (Was Re: [HACKERS] MySQL vs PostgreSQL.)
Alessio Bragadini wrote: On Sat, 2002-10-12 at 11:37, Gavin Sherry wrote: I cannot think of any reason why changing column order should be implemented in Postgres. Seems like a waste of time/more code bloat for something which is strictly asthetic. Regardless, I do have collegues/clients who ask when such a feature will be implemented. Why is this useful? Has column ordering any effect on the physical tuple disposition? I've heard discussions about keeping fixed-size fields at the beginning of the tuple and similar. Sorry for the lame question. :-) Yes, column ordering matches physical column ordering in the file, and yes, there is a small penalty for accessing any columns after the first variable-length column (pg_type.typlen 0). CHAR() used to be a fixed length column, but with TOAST (large offline storage) it became variable length too. I don't think there is much of a performance hit, though. -- 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: Changing Column Order (Was Re: [HACKERS] MySQL vs PostgreSQL.)
On Mon, Oct 14, 2002 at 11:04:07AM -0400, Bruce Momjian wrote: Alessio Bragadini wrote: On Sat, 2002-10-12 at 11:37, Gavin Sherry wrote: I cannot think of any reason why changing column order should be implemented in Postgres. Seems like a waste of time/more code bloat for something which is strictly asthetic. Has column ordering any effect on the physical tuple disposition? I've heard discussions about keeping fixed-size fields at the beginning of the tuple and similar. Yes, column ordering matches physical column ordering in the file, and yes, there is a small penalty for accessing any columns after the first variable-length column (pg_type.typlen 0). And note that if column ordering was to be implemented through the use of attlognum or something similar, the physical ordering would not be affected. The only way to physically reoder the columns would be to completely rebuild the table. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Aprende a avergonzarte mas ante ti que ante los demas (Democrito) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Bruce Momjian [EMAIL PROTECTED] writes:
Already done -- that's what Denis is unhappy about.
OK, I see that, but now, we are stuffing everything into a timeval
struct. Does that make sense? Shouldn't we just use time_t?
Yeah, the code could be simplified now. I'm also still not happy about
the question of whether it's safe to assume tv_sec is signed. I think
the running state should be just finish_time, and then inside the
loop when we are about to wait, we could do
current_time = time(NULL);
if (current_time = finish_time)
{
// failure exit
}
remains.tv_sec = finish_time - current_time;
remains.tv_usec = 0;
// pass remains to select...
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Already done -- that's what Denis is unhappy about.
OK, I see that, but now, we are stuffing everything into a timeval
struct. Does that make sense? Shouldn't we just use time_t?
Yeah, the code could be simplified now. I'm also still not happy about
the question of whether it's safe to assume tv_sec is signed. I think
the running state should be just finish_time, and then inside the
loop when we are about to wait, we could do
current_time = time(NULL);
if (current_time = finish_time)
{
// failure exit
}
remains.tv_sec = finish_time - current_time;
remains.tv_usec = 0;
// pass remains to select...
That whole remains structure should be a time_t variable, and then we
_know_ we can't assume it is signed. The use of timeval should
happen only in pqWaitTimed because it has to use select().
--
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] Anyone want to assist with the translation of the Advocacy site?
Hello ! I'd like to translate the advocacy site to Romanian, as long as nobody else has already offered himself/herself to do it. Just tell me, please, what should i do. Adrian Maier ([EMAIL PROTECTED]) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Final(?) consensus on PQcmdStatus and rules
I'm about to go off and implement this, so just to make sure we are all on the same page, here's what I think we agreed to: In the presence of rewrite rules, the command status returned by a rewritable query will behave thusly: 1. If the original query is executed (ie, there is no unconditional INSTEAD rule), then the original query's command status is returned in all cases. Queries added by rules are ignored. 2. If the original query is suppressed by an unconditional INSTEAD rule, then return the command status of the last-executed query that is both (a) from an INSTEAD rule and (b) of the same type (SELECT, INSERT, UPDATE, DELETE) as the original query. If there is no such query, return the original query's command type and zeroes for the count and OID fields of the status. This gives us several properties that were agreed to be desirable: * Returned command type always matches original query. * Non-INSTEAD rules never affect the command status. * The user can control which query sets the command status in the INSTEAD case, by ordering the rules properly. * Reasonably compatible with the pre-7.2 behavior, taking into account that the old behavior was not predictable if you had more than one rule anyway. Note that this will force an initdb for 7.3beta3, since we need to add a field to Query nodes to keep track of whether they came from INSTEAD rules. So I will also apply the pg_cast additions that we noticed were missing a couple days ago. Were there any other items that we would have fixed for 7.3 but were holding off to 7.4 just because of wanting to avoid initdb? 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] Anyone want to assist with the translation of the Advocacy
Hi Adrian, Wow. That's pretty cool. :) No-one has offered to do Romanian yet, so you're very welcome to. First things first: - What is the two letter language identifier most often used for Romanian? i.e. fr = Franch, de = German, etc. ro? - What is the character set that should be used to send out Romanian pages? i.e. for English, French, German it's iso-8859-1, for Turkish it's iso-8859-9, Romanian = ? :-) Regards and best wishes, Justin Clift [EMAIL PROTECTED] wrote: Hello ! I'd like to translate the advocacy site to Romanian, as long as nobody else has already offered himself/herself to do it. Just tell me, please, what should i do. Adrian Maier ([EMAIL PROTECTED]) -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] orderRules() now a bad idea?
I just noticed that rewriteHandler.c contains a subroutine orderRules() that reorders the rules for a relation into the order non-instead rules qualified instead rules unqualified instead rules This conflicts with the feature we'd added to 7.3 to fire rules in alphabetical order. (What will presently happen is they'll be fired alphabetically in each of these categories.) I see that the logic in fireRules() assumes that rules are processed in this order, but that would be fairly easy to fix. Is there any other good reason for doing this reordering? I'd like to remove orderRules() and implement straight alphabetical ordering. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Bruce Momjian [EMAIL PROTECTED] writes: That whole remains structure should be a time_t variable, and then we _know_ we can't assume it is signed. The use of timeval should happen only in pqWaitTimed because it has to use select(). I think it's fine to use struct timeval as the parameter type for pqWaitTimed. This particular caller of pqWaitTimed has no need for sub-second wait precision, but that doesn't mean we might not want it for other purposes later. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pgsql 7.2.3 crash
Yeah I think that could have happened since I was running it several times and had cancelled it (ctrl-c) it a couple of those times. Could be the backend of one cancelled run hadn't finished what it was doing and if that was renabling triggers it could have walked on it. Thanks. L. On Sat, 12 Oct 2002, Tom Lane wrote: Laurette Cisneros [EMAIL PROTECTED] writes: I see triggers referenced here and it should be noted that for one of the tables the triggers were first disabled (update pg_class) and re-enabled after the inserts are done (or it takes forever). Did that happen while this backend was running? Yes. I had run this perl program about 4-5 times in a row (which includes the sequence, disable triggers, insert rows, enable triggers) and then it crashed on one of the runs. Hm. The stack trace shows that this backend crashed while executing the command insert into jobsequences select * from rev_000_jobsequences Is it possible that you disabled and re-enabled triggers on jobsequences *while this command was running* ? The gdb info makes it look like the triggers code is using a stale trigger description structure. The pointer that's being used is cached in the ResultRelInfo struct (ri_TrigDesc) during query startup. If some external operation changed the trigger state while the query is running, trouble would ensue. This looks like something we ought to fix in any case, but I'm unsure whether it explains your crash. Do you think that that's what could have happened? Hackers: we might reasonably fix this by doing a deep copy of the relcache's trigger info during initResultRelInfo(); or we could fix it by getting rid of ri_TrigDesc and re-fetching from the relcache every time. The former would imply that trigger state would remain unchanged throughout a query, the latter would try to track currently-committed trigger behavior. Either way has got pitfalls I think. The fact that there's a problem at all is because people are using direct poking of the system catalogs instead of some kind of ALTER TABLE command to disable/enable triggers; an ALTER command would presumably gain exclusive lock on the table and thereby delay until active queries finish. But that technique is out there (even in pg_dump files :-() and so we'd best try to make the system proof against it. Any thoughts on which way to go? regards, tom lane -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- It's 10 o'clock... Do you know where your bus is? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] interesting side effect of autocommit = off
After turning autocommit off on my test database, my cron scripts that vacuum the database are now failing. This can be easily reproduced, turn autocommit off in your postgresql.conf, then launch psql and run a vacuum. [blind@blind databases]$ psql files Welcome to psql 7.3b2, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands \g or terminate with semicolon to execute query \q to quit files=# vacuum; ERROR: VACUUM cannot run inside a BEGIN/END block files=# It turns out that you need to commit/rollback first before you can issue the vacuum command. While I understand why this is happening (psql is issuing some selects on startup which automatically starts a transaction) it certainly isn't intuitive. Does this mean that I need to change my cron scripts to do rollback; vacuum;? thanks, --Barry ---(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] [GENERAL] Postgres-based system to run .org registry?
Yep, that's them. This is a big win from a PostgreSQL advocacy position, especially since oracle pr made an official statement against the use of PostgreSQL. Has this info hit any of the linux oriented news sites (linux-today, slashdot, etc...) If not someone from the PostgreSQL marketing dept. (wink wink) should come up with a press release. Robert Treat - Original Message - From: David De Graff [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, October 14, 2002 3:42 PM Subject: [GENERAL] Postgres-based system to run .org registry? The Internet Society (ISOC) won the bid to replace Verisign as the .org registry. They're going to subcontract to Afilias, who has been running the .info registry. See: http://www.icann.org/announcements/announcement-14oct02.htm http://www.afilias.info/about_afilias/dotorg/index_html http://www.washingtonpost.com/wp-dyn/articles/A23669-2002Oct14.html Is this the same group that recently asked for input on their proposal, which specified Postgres as the registry database? (For some reason I can't find the recent thread on their proposal on the hackers, general or admin lists.) Dave De Graff ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] Postgres-based system to run .org registry?
It's on Slashdot, but there's only one post there that mentions the use of Postgresql. On 14 Oct 2002, Robert Treat wrote: Yep, that's them. This is a big win from a PostgreSQL advocacy position, especially since oracle pr made an official statement against the use of PostgreSQL. Has this info hit any of the linux oriented news sites (linux-today, slashdot, etc...) If not someone from the PostgreSQL marketing dept. (wink wink) should come up with a press release. Robert Treat - Original Message - From: David De Graff [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, October 14, 2002 3:42 PM Subject: [GENERAL] Postgres-based system to run .org registry? The Internet Society (ISOC) won the bid to replace Verisign as the .org registry. They're going to subcontract to Afilias, who has been running the .info registry. See: http://www.icann.org/announcements/announcement-14oct02.htm http://www.afilias.info/about_afilias/dotorg/index_html http://www.washingtonpost.com/wp-dyn/articles/A23669-2002Oct14.html Is this the same group that recently asked for input on their proposal, which specified Postgres as the registry database? (For some reason I can't find the recent thread on their proposal on the hackers, general or admin lists.) Dave De Graff ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(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] [GENERAL] Postgres-based system to run .org registry?
On Monday 14 October 2002 04:08 pm, Robert Treat wrote: Yep, that's them. This is a big win from a PostgreSQL advocacy position, especially since oracle pr made an official statement against the use of PostgreSQL. Has this info hit any of the linux oriented news sites (linux-today, slashdot, etc...) If not someone from the PostgreSQL marketing dept. (wink wink) should come up with a press release. I have submitted a story to LinuxToday. We'll see how that goes. Anyone want to take on Slashdot? :-) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pgsql 7.2.3 crash
Laurette Cisneros [EMAIL PROTECTED] writes: Yeah I think that could have happened since I was running it several times and had cancelled it (ctrl-c) it a couple of those times. Could be the backend of one cancelled run hadn't finished what it was doing and if that was renabling triggers it could have walked on it. Sounds like we've got the explanation, then. I've just committed fixes into 7.3 to prevent this scenario in future. The patch is probably too large to risk back-patching into 7.2.* though. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pgsql 7.2.3 crash
Great. I am working my way toward 7.3 anyway... Thanks! L. On Mon, 14 Oct 2002, Tom Lane wrote: Laurette Cisneros [EMAIL PROTECTED] writes: Yeah I think that could have happened since I was running it several times and had cancelled it (ctrl-c) it a couple of those times. Could be the backend of one cancelled run hadn't finished what it was doing and if that was renabling triggers it could have walked on it. Sounds like we've got the explanation, then. I've just committed fixes into 7.3 to prevent this scenario in future. The patch is probably too large to risk back-patching into 7.2.* though. regards, tom lane -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- It's 10 o'clock... Do you know where your bus is? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Turkish version of the PostgreSQL Advocacy and Marketing site is ready
Hi everyone, The Turkish translation of the PostgreSQL Advocacy and Marketing site, done by Devrim GUNDUZ [EMAIL PROTECTED] is now complete and ready for public use: http://advocacy.postgresql.org/?lang=tr Pretty cool stuff. Thanks Devrim. :-) Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
That whole remains structure should be a time_t variable, and then we
_know_ we can't assume it is signed. The use of timeval should
happen only in pqWaitTimed because it has to use select().
I think it's fine to use struct timeval as the parameter type for
pqWaitTimed. This particular caller of pqWaitTimed has no need for
sub-second wait precision, but that doesn't mean we might not want it
for other purposes later.
That was a question: whether pqWaitTimed() was something exported by
libpq and therefore something that has an API that shouldn't change. I
see it in libpq-int.h, which I think means it isn't exported, but yes,
there could be later cases where we need subsecond stuff.
I have applied the following patch to get us a little closer to sanity.
--
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
Index: src/interfaces/libpq/fe-connect.c
===
RCS file: /cvsroot/pgsql-server/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.208
diff -c -c -r1.208 fe-connect.c
*** src/interfaces/libpq/fe-connect.c 11 Oct 2002 04:41:59 - 1.208
--- src/interfaces/libpq/fe-connect.c 14 Oct 2002 17:10:19 -
***
*** 1071,1085
conn-status = CONNECTION_BAD;
return 0;
}
! remains.tv_usec = 0;
rp = remains;
/* calculate the finish time based on start + timeout */
finish_time = time((time_t *) NULL) + remains.tv_sec;
}
! while (rp == NULL || remains.tv_sec 0 ||
! (remains.tv_sec == 0 remains.tv_usec 0))
{
/*
* Wait, if necessary. Note that the initial state (just after
--- 1071,1084
conn-status = CONNECTION_BAD;
return 0;
}
! remains.tv_usec = 0;/* We don't use subsecond timing */
rp = remains;
/* calculate the finish time based on start + timeout */
finish_time = time((time_t *) NULL) + remains.tv_sec;
}
! while (rp == NULL || remains.tv_sec 0)
{
/*
* Wait, if necessary. Note that the initial state (just after
***
*** 1133,1139
}
remains.tv_sec = finish_time - current_time;
- remains.tv_usec = 0;
}
}
conn-status = CONNECTION_BAD;
--- 1132,1137
Index: src/interfaces/libpq/fe-misc.c
===
RCS file: /cvsroot/pgsql-server/src/interfaces/libpq/fe-misc.c,v
retrieving revision 1.80
diff -c -c -r1.80 fe-misc.c
*** src/interfaces/libpq/fe-misc.c 3 Oct 2002 17:09:42 - 1.80
--- src/interfaces/libpq/fe-misc.c 14 Oct 2002 17:10:22 -
***
*** 783,796
}
int
! pqWaitTimed(int forRead, int forWrite, PGconn *conn, const struct timeval * timeout)
{
fd_set input_mask;
fd_set output_mask;
fd_set except_mask;
struct timeval tmp_timeout;
- struct timeval *ptmp_timeout = NULL;
if (conn-sock 0)
{
--- 783,795
}
int
! pqWaitTimed(int forRead, int forWrite, PGconn *conn, const struct timeval *timeout)
{
fd_set input_mask;
fd_set output_mask;
fd_set except_mask;
struct timeval tmp_timeout;
if (conn-sock 0)
{
***
*** 823,836
if (NULL != timeout)
{
/*
!* select may modify timeout argument on some platforms use
!* copy
*/
tmp_timeout = *timeout;
- ptmp_timeout = tmp_timeout;
}
if (select(conn-sock + 1, input_mask, output_mask,
! except_mask, ptmp_timeout) 0)
{
if (SOCK_ERRNO == EINTR)
goto retry5;
--- 822,834
if (NULL != timeout)
{
/*
!* select() may modify timeout argument on some platforms
so
!* use copy
*/
tmp_timeout = *timeout;
}
if (select(conn-sock + 1, input_mask, output_mask,
! except_mask, tmp_timeout)
Re: [HACKERS] Bug in PL/pgSQL GET DIAGNOSTICS?
Michael Paesold [EMAIL PROTECTED] writes: In a PL/pgSQL function I want to insert into a table and get the OID back. That usually works with GET DIAGNOSTICS last_oid = RESULT_OID; right after the insert statement. But if the table that I insert to has a rule (or perhaps a trigger?) that updates another table, the RESULT_OID after the insert will be 0 (zero). As of CVS tip, this example produces the results I believe you want: regression=# SELECT pltestfunc(10); NOTICE: RESULT_OID: 282229 NOTICE: RESULT_OID: 282230 NOTICE: RESULT_OID: 282231 NOTICE: RESULT_OID: 282232 NOTICE: RESULT_OID: 282233 NOTICE: RESULT_OID: 282234 NOTICE: RESULT_OID: 282235 NOTICE: RESULT_OID: 282236 NOTICE: RESULT_OID: 282237 NOTICE: RESULT_OID: 282238 pltestfunc t (1 row) regression=# SELECT * FROM pltest; id | t +-- 1 | test 2 | test 3 | test 4 | test 5 | test 6 | test 7 | test 8 | test 9 | test 10 | test (10 rows) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Oops, overoptimized a little. ptmp_timeout is needed in case no time is passed; ptmp_timeout restored. --- pgman wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: That whole remains structure should be a time_t variable, and then we _know_ we can't assume it is signed. The use of timeval should happen only in pqWaitTimed because it has to use select(). I think it's fine to use struct timeval as the parameter type for pqWaitTimed. This particular caller of pqWaitTimed has no need for sub-second wait precision, but that doesn't mean we might not want it for other purposes later. That was a question: whether pqWaitTimed() was something exported by libpq and therefore something that has an API that shouldn't change. I see it in libpq-int.h, which I think means it isn't exported, but yes, there could be later cases where we need subsecond stuff. I have applied the following patch to get us a little closer to sanity. -- 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 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] droped out precise time calculations in src/interfaces/libpq/fe-connect.c
I have applied the following comment patch. The current code resets the
timer when select() is interruped. On OS's that modify timeout to show
the remaining time, we should be using that value instead of resetting
the timer to its original value on select retry.
---
pgman wrote:
Oops, overoptimized a little. ptmp_timeout is needed in case no time is
passed; ptmp_timeout restored.
---
pgman wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
That whole remains structure should be a time_t variable, and then we
_know_ we can't assume it is signed. The use of timeval should
happen only in pqWaitTimed because it has to use select().
I think it's fine to use struct timeval as the parameter type for
pqWaitTimed. This particular caller of pqWaitTimed has no need for
sub-second wait precision, but that doesn't mean we might not want it
for other purposes later.
That was a question: whether pqWaitTimed() was something exported by
libpq and therefore something that has an API that shouldn't change. I
see it in libpq-int.h, which I think means it isn't exported, but yes,
there could be later cases where we need subsecond stuff.
I have applied the following patch to get us a little closer to sanity.
--
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
--
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
Index: src/interfaces/libpq/fe-misc.c
===
RCS file: /cvsroot/pgsql-server/src/interfaces/libpq/fe-misc.c,v
retrieving revision 1.82
diff -c -c -r1.82 fe-misc.c
*** src/interfaces/libpq/fe-misc.c 14 Oct 2002 17:33:08 - 1.82
--- src/interfaces/libpq/fe-misc.c 14 Oct 2002 18:08:14 -
***
*** 824,830
{
/*
* select() may modify timeout argument on some platforms
so
!* use copy
*/
tmp_timeout = *timeout;
ptmp_timeout = tmp_timeout;
--- 824,835
{
/*
* select() may modify timeout argument on some platforms
so
!* use copy.
!* XXX Do we really want to do that? If select() returns
!* the number of seconds remaining, we are resetting
!* the timeout to its original value. This will yeild
!* incorrect timings when select() is interrupted.
!* bjm 2002-10-14
*/
tmp_timeout = *timeout;
ptmp_timeout = tmp_timeout;
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Triggers and Schema's.
On Sat, 12 Oct 2002, Tom Lane wrote: Steven Singer [EMAIL PROTECTED] writes: get_namespace_name(RelationGetNamespace(tg_relation)) Is this sufficiently useful to justify adding an SPI_getrelnamespace() function? I'm not very clear on the uses for SPI_getrelname(). Most of the examples we have in contrib/ are using it for error messages, Thanks that function does the job. I have no problem using that function(or other backend functions) from triggers to do the job. If the idea behind SPI is that functions are only supposed to access backend functions through SPI and not call the backend directly then it probably should be added at some point for completeness sake but I suspect other functions would fall into this category as well. -- Steven Singer [EMAIL PROTECTED] Aircraft Performance SystemsPhone: 519-747-1170 ext 282 Navtech Systems Support Inc.AFTN: CYYZXNSX SITA: YYZNSCR Waterloo, Ontario ARINC: YKFNSCR ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Bruce Momjian [EMAIL PROTECTED] writes: /* * select() may modify timeout argument on some platforms so ! *use copy. ! *XXX Do we really want to do that? If select() returns ! *the number of seconds remaining, we are resetting ! *the timeout to its original value. This will yeild ! *incorrect timings when select() is interrupted. ! *bjm 2002-10-14 */ tmp_timeout = *timeout; ptmp_timeout = tmp_timeout; Actually, now that I look at this, the API for PQwaitTimed is wrong after all. The right way to implement this is for the caller to pass in finish_time (or some indication that no timeout is wanted). Evaluation of the time left to wait should happen inside this retry loop. That way, you get the right behavior (plus or minus one second, anyway) independently of whether the platform's select() reduces its timeout argument or not. 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
[HACKERS] Postgres-based system to run .org registry?
The Internet Society (ISOC) won the bid to replace Verisign as the .org registry. They're going to subcontract to Afilias, who has been running the .info registry. See: http://www.icann.org/announcements/announcement-14oct02.htm http://www.afilias.info/about_afilias/dotorg/index_html http://www.washingtonpost.com/wp-dyn/articles/A23669-2002Oct14.html Is this the same group that recently asked for input on their proposal, which specified Postgres as the registry database? (For some reason I can't find the recent thread on their proposal on the hackers, general or admin lists.) Dave De Graff ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] Postgres-based system to run .org registry?
David De Graff [EMAIL PROTECTED] writes: The Internet Society (ISOC) won the bid to replace Verisign as the .org registry. They're going to subcontract to Afilias, who has been running the .info registry. Cool. See: http://www.icann.org/announcements/announcement-14oct02.htm http://www.afilias.info/about_afilias/dotorg/index_html http://www.washingtonpost.com/wp-dyn/articles/A23669-2002Oct14.html Is this the same group that recently asked for input on their proposal, which specified Postgres as the registry database? Yes, same bunch. Andrew Sullivan, whose name you may have seen on the lists, is the DBA for the .info registry; I suppose he will be running the .org registry now too ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: /* * select() may modify timeout argument on some platforms so ! *use copy. ! *XXX Do we really want to do that? If select() returns ! *the number of seconds remaining, we are resetting ! *the timeout to its original value. This will yeild ! *incorrect timings when select() is interrupted. ! *bjm 2002-10-14 */ tmp_timeout = *timeout; ptmp_timeout = tmp_timeout; Actually, now that I look at this, the API for PQwaitTimed is wrong after all. The right way to implement this is for the caller to pass in finish_time (or some indication that no timeout is wanted). Evaluation of the time left to wait should happen inside this retry loop. That way, you get the right behavior (plus or minus one second, anyway) independently of whether the platform's select() reduces its timeout argument or not. Yes, you are saying do the time() inside PQwaitTimed(), so we can properly get new time() values on select() retry. Yep. -- 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] droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Tom, excuse me, I forget to copy previous posting to [EMAIL PROTECTED] On Mon, Oct 14, 2002 at 09:53:27AM -0400, Tom Lane wrote: Denis A Ustimenko [EMAIL PROTECTED] writes: On Sun, Oct 13, 2002 at 10:59:40PM -0700, Joe Conway wrote: Well, if we were specifying the timeout in microseconds instead of seconds, it would make sense to have better resolution. But when you can only specify the timeout in seconds, the internal time comparison doesn't need to be any more accurate than seconds (IMHO anyway). Actually we have the state machine in connectDBComplete() and the timeout is set for machine as the whole. Therefore if 1 second timeout is seted for the connectDBComplete() the timeout of particualr iteration of loop can be less then 1 second. However, the code's been restructured so that we don't need to keep track of the exact time spent in any one iteration. The error is only on the overall delay. I agree with Joe that it's not worth the effort needed (in the Win32 case) to make the timeout accurate to 1 sec. Beware of almost 1 second posiible error. For example: connect_timeout == 1, we start at 0.99 then finish_time == 1. If CPU is quite busy we will do only one iteration. I don't know is it enough to make connection? True timeout in this case == 0.01 -- Regards Denis ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] Postgres-based system to run .org registry?
Yep, that's them. This is a big win from a PostgreSQL advocacy position, especially since oracle pr made an official statement against the use of PostgreSQL. Has this info hit any of the linux oriented news sites (linux-today, slashdot, etc...) If not someone from the PostgreSQL marketing dept. (wink wink) should come up with a press release. Robert Treat Don't worry about Oracle, they don't need real customers. Their database market consists of a healthy balance of real and fictitious people. See http://slashdot.org/articles/02/04/17/179252.shtml?tid=98 Regards, Jeff Davis ---(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] orderRules() now a bad idea?
Tom Lane wrote: I just noticed that rewriteHandler.c contains a subroutine orderRules() that reorders the rules for a relation into the order non-instead rules qualified instead rules unqualified instead rules This conflicts with the feature we'd added to 7.3 to fire rules in alphabetical order. (What will presently happen is they'll be fired alphabetically in each of these categories.) I see that the logic in fireRules() assumes that rules are processed in this order, but that would be fairly easy to fix. Is there any other good reason for doing this reordering? I'd like to remove orderRules() and implement straight alphabetical ordering. Unless Jan has an objection, I think alpha is best, because it matches trigger rule odering. That original rule ordering isn't something anyone is going to figure out on their own. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] interesting side effect of autocommit = off
Barry Lind wrote: After turning autocommit off on my test database, my cron scripts that vacuum the database are now failing. This can be easily reproduced, turn autocommit off in your postgresql.conf, then launch psql and run a vacuum. [blind@blind databases]$ psql files Welcome to psql 7.3b2, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands \g or terminate with semicolon to execute query \q to quit files=# vacuum; ERROR: VACUUM cannot run inside a BEGIN/END block files=# It turns out that you need to commit/rollback first before you can issue the vacuum command. While I understand why this is happening (psql is issuing some selects on startup which automatically starts a transaction) it certainly isn't intuitive. Does this mean that I need to change my cron scripts to do rollback; vacuum;? OK, I can reproduce it here, but the issue is only reproducable if you use autocommit off in postgresql.conf. If you run it interactively as your first command, it is OK. I am sure the problem is that psql doing a query on startup: $ sql -E test * QUERY ** SELECT usesuper FROM pg_catalog.pg_user WHERE usename = 'postgres' ** Fortunately, we have an open item for 7.3 for this exact case: Fix client apps for autocommit = off and psql is one of them. I was just asking what we need to do to get this addressed. I think the fix will be in within the next few days. -- 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 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] [GENERAL] Postgres-based system to run .org registry?
Robert Treat wrote: Yep, that's them. This is a big win from a PostgreSQL advocacy position, especially since oracle pr made an official statement against the use of PostgreSQL. Has this info hit any of the linux oriented news sites (linux-today, slashdot, etc...) If not someone from the PostgreSQL marketing dept. (wink wink) should come up with a press release. Yes, this is a huge win, and something for our advocacy site, and for the main PostgreSQL page too. Vince? -- 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] Let's get 7.3 done
At 12:49 AM 14/10/2002 -0400, Bruce Momjian wrote: Fix pg_dump to handle 64-bit off_t offsets for custom format I'll try to get back to this in the next day or so... Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /() __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] interesting side effect of autocommit = off
Bruce Momjian [EMAIL PROTECTED] writes: I am sure the problem is that psql doing a query on startup: Yeah, and libpq does one too in some cases :-(. Both of these need to be fixed before 7.3 if possible. Whether we fix these or not, it'd be a good idea to document that turning autocommit off in postgresql.conf is not yet well-supported. I doubt that all client-side code will be happy with that for awhile yet ... 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] interesting side effect of autocommit = off
Tom Lane wrote: Yeah, and libpq does one too in some cases :-(. Both of these need to be fixed before 7.3 if possible. Whether we fix these or not, it'd be a good idea to document that turning autocommit off in postgresql.conf is not yet well-supported. I doubt that all client-side code will be happy with that for awhile yet ... Yup -- here's another example. I was playing around with autocommit off in postgresql.conf to see the effect on dblink. Just now I tried to use pg_dumpall in preparation for an initdb, and got this: $ pg_dumpall cur.2002.10.14.dmp pg_dump: WARNING: BEGIN: already a transaction in progress pg_dump: could not set transaction isolation level to serializable: ERROR: SET TRANSACTION ISOLATION LEVEL must be called before any query pg_dumpall: pg_dump failed on dblink_test_master, exiting Joe ---(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] droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Denis A Ustimenko wrote: Tom, excuse me, I forget to copy previous posting to [EMAIL PROTECTED] On Mon, Oct 14, 2002 at 09:53:27AM -0400, Tom Lane wrote: Denis A Ustimenko [EMAIL PROTECTED] writes: On Sun, Oct 13, 2002 at 10:59:40PM -0700, Joe Conway wrote: Well, if we were specifying the timeout in microseconds instead of seconds, it would make sense to have better resolution. But when you can only specify the timeout in seconds, the internal time comparison doesn't need to be any more accurate than seconds (IMHO anyway). Actually we have the state machine in connectDBComplete() and the timeout is set for machine as the whole. Therefore if 1 second timeout is seted for the connectDBComplete() the timeout of particualr iteration of loop can be less then 1 second. However, the code's been restructured so that we don't need to keep track of the exact time spent in any one iteration. The error is only on the overall delay. I agree with Joe that it's not worth the effort needed (in the Win32 case) to make the timeout accurate to 1 sec. Beware of almost 1 second posiible error. For example: connect_timeout == 1, we start at 0.99 then finish_time == 1. If CPU is quite busy we will do only one iteration. I don't know is it enough to make connection? True timeout in this case == 0.01 Good question. What is going to happen is that select() is going to be passed tv_sec = 1, and it is going to sleep for one second. Now, if select is interrupted, another time() call is going to be made. If the second ticked just before we run time(), we are going to think one second has elapsed and return, so in the non-interrupt case, we are going to be fine, but with select() interrupted, we are going to have this problem. Now, if we used gettimeofday(), we would be fine, but we don't have that on Win32 and the ported version of that looks pretty complicated. Maybe we will go with what we have and see if anyone complains. One idea I am looking at is to pass a time_t into pqWaitTimeout, and do that clock checking in there, and maybe I can do a gettimeofday() for non-Win32 and a time() on Win32. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Bruce Momjian [EMAIL PROTECTED] writes: Denis A Ustimenko wrote: Beware of almost 1 second posiible error. For example: connect_timeout == 1, we start at 0.99 then finish_time == 1. If CPU is quite busy we will do only one iteration. I don't know is it enough to make connection? True timeout in this case == 0.01 Good question. What is going to happen is that select() is going to be passed tv_sec = 1, and it is going to sleep for one second. Now, if select is interrupted, another time() call is going to be made. There is a very simple answer to this, which I think I suggested to Joe originally, but it's not in the code now: the initial calculation of finish_time = now() + timeout must add one. This ensures that any roundoff error is in the conservative direction of timing out later, rather than sooner. 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] droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Denis A Ustimenko wrote: Beware of almost 1 second posiible error. For example: connect_timeout == 1, we start at 0.99 then finish_time == 1. If CPU is quite busy we will do only one iteration. I don't know is it enough to make connection? True timeout in this case == 0.01 Good question. What is going to happen is that select() is going to be passed tv_sec = 1, and it is going to sleep for one second. Now, if select is interrupted, another time() call is going to be made. There is a very simple answer to this, which I think I suggested to Joe originally, but it's not in the code now: the initial calculation of finish_time = now() + timeout must add one. This ensures that any roundoff error is in the conservative direction of timing out later, rather than sooner. Yes, I saw that and will try to add it back into the code. -- 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 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
