[HACKERS] mac typo prob?
I just cut and pasted someone's mac address: patrimoine=# update ethernet set mac='00-00-39-AB-92-FO' where id=623; UPDATE 1 patrimoine=# select mac from ethernet where id=623; mac --- 00:00:39:ab:92:0f (1 row) Note the typo O instead of 0. I can see how that happened - should it be notifyed against? (pre-25 Sept code, 7.3b1) Cheers, Patrick ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] experiences with autocommit functionality in 7.3
Barry Lind [EMAIL PROTECTED] writes: Below is the current behavior (based on a fresh pull from cvs this morning): Current State ActionEnd State ACon and NITset ACon ACon and NIT set ACoff ACoff and IT* Bruce was supposed to fix this. We agreed that a SET command would never initiate a transaction block on its own. Looks like it's not there yet --- but IMHO the behavior should be ACon and NITset ACon ACon and NIT set ACoff ACoff and NIT ACon and IT set ACon ACon and IT set ACoff ACoff and IT* ACon and IT*set ACon ACon and IT* set ACoff ACoff and IT ACoff and NIT set ACon ACon and NIT set ACoff ACoff and NIT ACoff and ITset ACon ACon and IT* set ACoff ACoff and IT ACoff and IT* set ACon ACon and IT set ACoff ACoff and IT* Will that resolve your concern? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] mac typo prob?
Patrick Welche [EMAIL PROTECTED] writes: I just cut and pasted someone's mac address: patrimoine=# update ethernet set mac='00-00-39-AB-92-FO' where id=623; UPDATE 1 patrimoine=# select mac from ethernet where id=623; mac --- 00:00:39:ab:92:0f (1 row) Note the typo O instead of 0. I can see how that happened - should it be notifyed against? No, it should be an error IMHO. macaddr_in() is failing to check for trailing junk, which is a standard problem for sscanf-based parsing... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] experiences with autocommit functionality in 7.3
I said: Bruce was supposed to fix this. We agreed that a SET command would never initiate a transaction block on its own. Looks like it's not there yet --- Now it is. Give it another try ... 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] pgsql 7.2.3 crash
Gavin Sherry wrote: On Sat, 12 Oct 2002, Joe Conway wrote: Tom Lane wrote: 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? I'd say: 1. go with the former I agree. 2. we definitely should also have an ALTER command to allow disable/enable of triggers I thought this was worked on for 7.3? I remember speaking to someone (?) at OSCON because I had been working on 'ENABLE TRIGGER trigname' and is compliment on the plane. Much of the work seemed to have been in CVS already. It is in TODO: * Allow triggers to be disabled [trigger] From the TODO.detail archives, it seems it got stuck on an implementation issue: http://candle.pha.pa.us/mhonarc/todo.detail/trigger/msg1.html The patch didn't prevent deferred contraint triggers from being fired. -- 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] droped out precise time calculations in src/interfaces/libpq/fe-connect.c
- Forwarded message from Bruce Momjian [EMAIL PROTECTED] - I don't know. Would you ask hackers list, and perhaps CC the author of that patch. --- Denis A Ustimenko wrote: Bruce, why have all precise time calculations been droped out in 1.206? If there is no gettimeofday in win32? - End forwarded message - -- 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: [HACKERS] experiences with autocommit functionality in 7.3
Tom Lane wrote: Barry Lind [EMAIL PROTECTED] writes: Below is the current behavior (based on a fresh pull from cvs this morning): Current State ActionEnd State ACon and NITset ACon ACon and NIT set ACoff ACoff and IT* Bruce was supposed to fix this. We agreed that a SET command would never initiate a transaction block on its own. Looks like it's not there yet --- but IMHO the behavior should be Well, I thought I did it, and it did work on my limited number of test cases. Seems you got it fully working. -- 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] 7.3b2 ?bug? bitfromint4 is not working
Is it worth an initdb for 7.3b3 to fix this? I think we were already considering forcing one for the command-tag issues, otherwise I'd probably vote no. Comments? Do we need an initdb to fix command tags? I thought that was just a change in the Query structure. --- Tom Lane wrote: Neophytos Demetriou [EMAIL PROTECTED] writes: I must be missing something obvious here but it seems that bitfromint4 is not working under 7.3b2. I can still see bitfromint4 in the source code, utils/adt/varbit.c, but it is no longer working. Any ideas why? It's still there: regression=# select bit(42); bit -- 00101010 (1 row) However, it's not listed in pg_cast :-( regression=# select cast(42 as bit); ERROR: Cannot cast type integer to bit Looking at the CVS logs, this seems to be caused by overlapping changes. On 4-Aug Thomas renamed bittoint4 and bitfromint4 to match the more usual naming conventions for cast functions, viz int4(bit) and bit(int4), and he also added int8(bit) and bit(int8). This was after Peter had trolled the catalogs for cast functions and created the initial contents of pg_cast.h (on 18-Jul). Upshot: we have here four functions that ought to be in pg_cast and are not. Is it worth an initdb for 7.3b3 to fix this? I think we were already considering forcing one for the command-tag issues, otherwise I'd probably vote no. Comments? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- 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: [HACKERS] droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Denis A Ustimenko wrote: Bruce, why have all precise time calculations been droped out in 1.206? If there is no gettimeofday in win32? gettimeofday was not portable to win32 (at least not that I could find) and hence broke the win32 build of the clients. 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] \copy needs work (was Re: Changing Column Order)
Tom Lane wrote: Bruno Wolff III [EMAIL PROTECTED] writes: On Sat, Oct 12, 2002 at 12:43:37 +0300, Antti Haapala [EMAIL PROTECTED] wrote: What about copy? AFAIK, copy doesn't allow column names being specified, so it's not purely aesthetic... The SQL COPY command does (at least in 7.3). The \copy psql command doesn't seem to allow this though. That's an oversight; \copy should have been fixed for 7.3. Do we want to look at this as a bug (okay to fix for 7.3) or a new feature (wait for 7.4)? I see something that I think is a must-fix omission in the same code: it should allow a schema-qualified table name. So I'm inclined to fix both problems now. I don't think we can say \copy missing columns is a bug; we never had it in previous release. Seems like a missing feature. The COPY schema names seems valid. -- 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] \copy and identifier quoting
Tom Lane wrote: Isn't this a bug? regression=# create table FOO (f1 int); CREATE TABLE regression=# \copy FOO from stdin ERROR: Relation FOO does not exist \copy: ERROR: Relation FOO does not exist regression=# This happens because \copy takes the given table name and slaps double quotes around it, so the backend gets COPY FOO ... rather than COPY FOO ... It seems to me that psql's \copy should interpret the table name the same way that a regular SQL command would: honor double quotes, downcase in the absence of quotes. Comments, objections? Yes, that makes perfect sense. -- 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] experiences with autocommit functionality in 7.3
Bruce Momjian [EMAIL PROTECTED] writes: Well, I thought I did it, and it did work on my limited number of test cases. Seems you got it fully working. Actually, it failed for me (and evidently for Barry) on exactly the test case you posted along with the patch. You said test= set autocommit = off; SET test= commit; WARNING: COMMIT: no transaction in progress COMMIT but in fact I saw the COMMIT succeeding without complaint. I was meaning to ask you just what code you'd tested, because this morning's CVS tip did *not* behave as above. 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] \copy needs work (was Re: Changing Column Order)
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Do we want to look at this as a bug (okay to fix for 7.3) or a new feature (wait for 7.4)? I don't think we can say \copy missing columns is a bug; we never had it in previous release. Seems like a missing feature. The COPY schema names seems valid. Well, we never had schema names in previous releases either. So I'm not sure that I see a bright line between these items. The real issue is that psql's \copy has failed to track the capabilities of backend COPY. I think we should just fix it. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Disabling triggers (was Re: [HACKERS] pgsql 7.2.3 crash)
Gavin Sherry [EMAIL PROTECTED] writes: On Sat, 12 Oct 2002, Joe Conway wrote: Tom Lane wrote: 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. Any thoughts on which way to go? I'd say: 1. go with the former I agree. That's my leaning too, after further reflection. Will make it so. 2. we definitely should also have an ALTER command to allow disable/enable of triggers I thought this was worked on for 7.3? Unless I missed it, it's not in current sources. I was wondering whether an ALTER TABLE command is really the right way to approach this. If we had an ALTER-type command, presumably the implication is that its effects would be global to all backends. But the uses that I've seen for suspending trigger invocations would be happier with a local, temporary setting that only affects the current backend. Any thoughts about that? 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: Disabling triggers (was Re: [HACKERS] pgsql 7.2.3 crash)
On Mon, 14 Oct 2002, Tom Lane wrote: I was wondering whether an ALTER TABLE command is really the right way to approach this. If we had an ALTER-type command, presumably the implication is that its effects would be global to all backends. But the uses that I've seen for suspending trigger invocations would be happier with a local, temporary setting that only affects the current backend. Any thoughts about that? I may be missing something here, but the only circumstance where i could see such being useful would be a load of a database ... other then that, how would overriding triggers be considered a good thing? ---(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] 7.3b2 ?bug? bitfromint4 is not working
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Do we need an initdb to fix command tags? I thought that was just a change in the Query structure. A change in Query struct breaks stored rules. Looks like initdb material to me ... Oh, I forgot about stored rules. Yep, that would cause it. Not sure if fixing rule return is a valid initdb reason, but with the 'bit' type problem, seems it would be worth while. I am going to post in a few minutes about a push to get all those open items wrapped up. I think we are drifting. -- 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
On Sun, Oct 13, 2002 at 09:02:55PM -0700, Joe Conway wrote: Denis A Ustimenko wrote: Bruce, why have all precise time calculations been droped out in 1.206? If there is no gettimeofday in win32? gettimeofday was not portable to win32 (at least not that I could find) and hence broke the win32 build of the clients. GetSystemTimeAsFileTime should help. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/getsystemtimeasfiletime.asp -- Regards Denis ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] \copy needs work (was Re: Changing Column Order)
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Do we want to look at this as a bug (okay to fix for 7.3) or a new feature (wait for 7.4)? I don't think we can say \copy missing columns is a bug; we never had it in previous release. Seems like a missing feature. The COPY schema names seems valid. Well, we never had schema names in previous releases either. So I'm not sure that I see a bright line between these items. The real issue is that psql's \copy has failed to track the capabilities of backend COPY. I think we should just fix it. OK, I added it to the open items list. -- 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: Disabling triggers (was Re: [HACKERS] pgsql 7.2.3 crash)
Tom Lane wrote: I was wondering whether an ALTER TABLE command is really the right way to approach this. If we had an ALTER-type command, presumably the implication is that its effects would be global to all backends. But the uses that I've seen for suspending trigger invocations would be happier with a local, temporary setting that only affects the current backend. Any thoughts about that? I think SET would be the proper place, but I don't see how to make it table-specific. -- 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] experiences with autocommit functionality in 7.3
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Well, I thought I did it, and it did work on my limited number of test cases. Seems you got it fully working. Actually, it failed for me (and evidently for Barry) on exactly the test case you posted along with the patch. You said test= set autocommit = off; SET test= commit; WARNING: COMMIT: no transaction in progress COMMIT but in fact I saw the COMMIT succeeding without complaint. I was meaning to ask you just what code you'd tested, because this morning's CVS tip did *not* behave as above. I am stumped myself as well. I still have the CVS of my old code, and it fails just as you saw, but I know I tested it and copied that into the email via cut/paste so my only guess is that I tweaked something after I ran the test and if broke something else. If you got it all working now, I won't research further. -- 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: Disabling triggers (was Re: [HACKERS] pgsql 7.2.3 crash)
Tom Lane wrote: I was wondering whether an ALTER TABLE command is really the right way to approach this. If we had an ALTER-type command, presumably the implication is that its effects would be global to all backends. But the uses that I've seen for suspending trigger invocations would be happier with a local, temporary setting that only affects the current backend. Any thoughts about that? Hmmm. Well the most common uses I've run across for disabling triggers in the Oracle Apps world are: 1) bulk loading of data 2) temporarily turning off workflow procedures The first case would benefit from being able to disable the trigger locally, without affecting other backends. Of course, I don't know how common it is to bulk load data while others are hitting the same table. The second case is usually something like an insert into the employee table fires off an email to IT to create a login and security to make a badge. Commonly we turn off workflows (by disabling their related triggers) in our development and test databases so someone doesn't disable the CEO's login when we fire him as part of our testing! I think in this scenario it is better to be able to disable the trigger globally ;-) 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: Disabling triggers (was Re: [HACKERS] pgsql 7.2.3 crash)
Marc G. Fournier [EMAIL PROTECTED] writes: On Mon, 14 Oct 2002, Tom Lane wrote: I was wondering whether an ALTER TABLE command is really the right way to approach this. If we had an ALTER-type command, presumably the implication is that its effects would be global to all backends. But the uses that I've seen for suspending trigger invocations would be happier with a local, temporary setting that only affects the current backend. Any thoughts about that? I may be missing something here, but the only circumstance where i could see such being useful would be a load of a database ... other then that, how would overriding triggers be considered a good thing? Well, exactly: it seems like something you'd want to constrain as tightly as possible. So some kind of local, SET-like operation seems safer to me than a global, ALTER-TABLE-like operation. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Let's get 7.3 done
OK, I would like to shoot for 7.3 final in the next few weeks. Can we get some of these items completed so we can make that happen and move on to 7.4? Remeber, PITR and Win32 are waiting! Let me comment on these: --- P O S T G R E S Q L 7 . 3 O P E NI T E M S Current at ftp://momjian.postgresql.org/pub/postgresql/open_items. Required Changes --- Schema handling - ready? interfaces? client apps? What specifically still needs to be done here? Drop column handling - ready for all clients, apps? Same. Get bison upgrade on postgresql.org for ecpg only (Marc) OK, bison 1.50 is officially released. I am using it here and it passes the regression tests. Marc, would you download that on to postgresql.org and then Michael can get ecpg fully working, and we can get this item removed from the list. Fix vacuum btree bug (Tom) OK, Tom, I know you were looking for a better fix than locking down the index pages to fix this. Perhaps you should throw out the question one more time, and if no one has a better idea, let's code the fix and document the problem in the code so maybe it can get improved at some later date. Fix client apps for autocommit = off OK, exactly what needs to be done here. If we add 'SET autocommit = off' to the top of the apps, is that all we need to do? For apps that connect to the database multiple times, do we have to do it multiple times? Fix pg_dump to handle 64-bit off_t offsets for custom format Where are we on this? Optional Changes None of these have to be done before final. Fix BeOS, QNX4 ports I am removing this one. No one is volunteering. 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. Add schema dump option to pg_dump Same. Add/remove GRANT EXECUTE to all /contrib functions? Who volunteered to clean all this up a while back? Missing casts for bit operations Requires initdb, as does INSTEAD fix. \copy doesn't handle column names COPY doesn't handle schemas COPY quotes all table names Again, all optional. On Going Security audit Haven't heard anything on this for a while. Removed. Documentation Changes - Move documation to gborg for moved projects This needs to be done. What plan to we have for those gborg docs to deal with SGML? This is the week folks --- let's get these done or moved to TODO. -- 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] droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Denis A Ustimenko wrote:
On Sun, Oct 13, 2002 at 09:02:55PM -0700, Joe Conway wrote:
Denis A Ustimenko wrote:
Bruce, why have all precise time calculations been droped out in 1.206?
If there is no
gettimeofday in win32?
gettimeofday was not portable to win32 (at least not that I could find) and
hence broke the win32 build of the clients.
GetSystemTimeAsFileTime should help.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/getsystemtimeasfiletime.asp
It's not clear to me how we could get this into something we can deal
with like gettimeofday.
I looked at the Apache APR project, and they have a routine that returns
the microseconds since 1970 for Unix:
/* NB NB NB NB This returns GMT!! */
APR_DECLARE(apr_time_t) apr_time_now(void)
{
struct timeval tv;
gettimeofday(tv, NULL);
return tv.tv_sec * APR_USEC_PER_SEC + tv.tv_usec;
}
and for Win32:
APR_DECLARE(apr_time_t) apr_time_now(void)
{
LONGLONG aprtime = 0;
FILETIME time;
#ifndef _WIN32_WCE
GetSystemTimeAsFileTime(time);
#else
SYSTEMTIME st;
GetSystemTime(st);
SystemTimeToFileTime(st, time);
#endif
FileTimeToAprTime(aprtime, time);
return aprtime;
}
and FileTimeToAprTime() is:
/* Number of micro-seconds between the beginning of the Windows epoch
* (Jan. 1, 1601) and the Unix epoch (Jan. 1, 1970)
*/
#define APR_DELTA_EPOCH_IN_USEC APR_TIME_C(116444736);
__inline void FileTimeToAprTime(apr_time_t *result, FILETIME *input)
{
/* Convert FILETIME one 64 bit number so we can work with it. */
*result = input-dwHighDateTime;
*result = (*result) 32;
*result |= input-dwLowDateTime;
*result /= 10;/* Convert from 100 nano-sec periods to micro-seconds. */
*result -= APR_DELTA_EPOCH_IN_USEC; /* Convert from Windows epoch to Unix
epoch */
return;
}
So, this is what needs to be dealt with to get it working.
--
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
Bruce Momjian wrote:
So, this is what needs to be dealt with to get it working.
More to the point, why is sub-second precision needed in this function?
Connection timeout is given to us in whole seconds (1.205 code, i.e. prior to
the patch in question):
remains.tv_sec = atoi(conn-connect_timeout);
if (!remains.tv_sec)
{
conn-status = CONNECTION_BAD;
return 0;
}
remains.tv_usec = 0;
rp = remains;
So there is no way to bail out prior to one second. Once you accept that the
timeout is = 1 second, and in whole second increments, why does it need
sub-second resolution?
Joe
---(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
Joe Conway wrote:
Bruce Momjian wrote:
So, this is what needs to be dealt with to get it working.
More to the point, why is sub-second precision needed in this function?
Connection timeout is given to us in whole seconds (1.205 code, i.e. prior to
the patch in question):
remains.tv_sec = atoi(conn-connect_timeout);
if (!remains.tv_sec)
{
conn-status = CONNECTION_BAD;
return 0;
}
remains.tv_usec = 0;
rp = remains;
So there is no way to bail out prior to one second. Once you accept that the
timeout is = 1 second, and in whole second increments, why does it need
sub-second resolution?
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. I would like to remove the tv_usec test because it suggests we
are doing something with microseconds when we are not. Also, should we
switch to a simple time() call, rather than gettimeofday()?
--
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] Peer to peer replication of Postgresql databases
On Fri, Oct 11, 2002 at 08:30:55AM -0500, Greg Copeland wrote: I'd be curious to hear in a little more detail what constitutes not good for postgres on a mosix cluster. It seems that almost all the postgres processes remain in the `home' node. Please notice that I am not underestimating Mosix in any way. We have tested many programs from our parallel processing project with extreme success on our mosix cluster. Anuradha -- Debian GNU/Linux (kernel 2.4.18-xfs-1.1) Ginger snap. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Peer to peer replication of Postgresql databases
On Fri, Oct 11, 2002 at 07:10:26PM +0530, Shridhar Daithankar wrote: On 11 Oct 2002 at 8:30, Greg Copeland wrote: I'd be curious to hear in a little more detail what constitutes not good for postgres on a mosix cluster. Well, I guess in kind of replication we are talking here, the performance will be enhanced only if separate instances of psotgresql runs on separate machine. Now if mosix kernel applies some AI and puts all of them on same machine, it isn't going to be any good for the purpose replication is deployed. Exactly. First, since we know what is going on, it is not necessary for the OS to decide what's going on. Secondly, database replication is not looked after at all, unless we do some crude tricks on the filesystem. Still it won't be efficient. I guess that's what she meant.. ^^^ Correction: that's what _HE_ meant... ;) Anuradha -- Debian GNU/Linux (kernel 2.4.18-xfs-1.1) All other things being equal, a bald man cannot be elected President of the United States. -- Vic Gold ---(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] Peer to peer replication of Postgresql databases
On 14 Oct 2002 at 11:55, Anuradha Ratnaweera wrote: On Fri, Oct 11, 2002 at 07:10:26PM +0530, Shridhar Daithankar wrote: On 11 Oct 2002 at 8:30, Greg Copeland wrote: I'd be curious to hear in a little more detail what constitutes not good for postgres on a mosix cluster. Well, I guess in kind of replication we are talking here, the performance will be enhanced only if separate instances of psotgresql runs on separate machine. Now if mosix kernel applies some AI and puts all of them on same machine, it isn't going to be any good for the purpose replication is deployed. Exactly. First, since we know what is going on, it is not necessary for the OS to decide what's going on. Secondly, database replication is not looked after at all, unless we do some crude tricks on the filesystem. Still it won't be efficient. IMO any one layer of clustering should be enough. If you use mosix, you shouldn't need clustering in postgresql. If postgresql clustering is applied any heterogenous machines like freebsd/linux should do. (OK same architecture at least. No suns and PCs..) Let's keep aside mosix for the time being. Application level clustering is what postgresql needs. What next? which one should we work on? Postgres-R/Usogres/ER-server? I guess that's what she meant.. ^^^ Correction: that's what _HE_ meant... ;) Argh... Extremely sorry, in India, special nouns ending with 'a' are usually feminine.. Like Radha.. Sorry again..:-) Bye Shridhar -- Weiner's Law of Libraries: There are no answers, only cross references. ---(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] Peer to peer replication of Postgresql databases
On Fri, Oct 11, 2002 at 12:07:00PM -0400, Neil Conway wrote: [ pgsql-patches removed from Cc: list ] Anuradha Ratnaweera [EMAIL PROTECTED] writes: I am trying to add some replication features to postgres (yes, I have already looked at ongoing work), in a peer to peer manner. Did you look at the research behind Postgres-R, and the pgreplication stuff? Am looking at the research papers related to it now. - When a frontend process sends a read query, each backend process does that from its own data area. Surely that's not correct -- a SELECT can be handled by *any one* node, not each and every one, right? Yes. Sorry about my careless wording. Unless anything is kind of locked, each node has a copy of the database, so each one can handle SELECTs individually. The actual situation will be far from this simple, because there will be database writes going on and generating consistent SELECTs would need careful handling of concurency issues. - There are two types of write queries. Postmasters use seperate communication channels for each. One is the sequencial channel which carries writes whose order is important, and the non-sequencial channel carries write queries whose order is not important. How do you distinguish between these? Nope. We assume that all the communication should go through the sequencial channel unless indicated by the client. In that case, we will have to find a way to indicate this from the client's side. This doesn't sound very elegant, may be we can figure out a better way. Anuradha -- Debian GNU/Linux (kernel 2.4.18-xfs-1.1) Being against torture ought to be sort of a bipartisan thing. -- Karl Lehenbauer ---(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 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. Joe ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Transactions through dblink_exec()
Masaru Sugawara wrote:
I'm hoping that dblink_exec() returns something like warning if those who intend
to do transactions make a declaration of blink_exec('dbname=some', 'begin') by mistake.
for example
WARNING :You should declare dblink_exec('dbname=some', 'BEGIN; some queries;
COMMIT/ROLLBACK/END;') or use dblink_exec('BEGIN/COMMIT/ROLLBACK/END')
around dblink_exec('some queries')s. If not, your transactions won't work.
{...snip...]
-- case 3. --
SELECT dblink_exec('dbname=regression_slave', 'BEGIN');
SELECT dblink_exec('dbname=regression_slave',
'INSERT INTO foo VALUES(12,''m'',''{a12,b12,c12}'');');
SELECT dblink_exec('dbname=regression_slave', 'ROLLBACK'); -- failure !
Hmmm. No surprise this din't work. Each time you specify the connect string, a
connection is opened, the statement executed, and then the connection is
closed -- i.e. each of the invocations of dblink_exec above stands alone. Are
you suggesting a warning only on something like:
SELECT dblink_exec('dbname=regression_slave', 'BEGIN');
? Seems like maybe a warning in the documentation would be enough. Any other
opinions out there?
What occurs to me though, is that this is one of those clients affected by
the autocommit setting situations. (...goes off and tries it out...) Sure
enough. If you have autocommit set to off, you can do:
SELECT dblink_exec('dbname=regression_slave',
'INSERT INTO foo VALUES(12,''m'',''{a12,b12,c12}'');');
all day and never get it to succeed.
Given the above, should dblink_exec(CONNSTR, SQL) always wrap SQL in an
explicit transaction? Any thoughts on this?
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
[HACKERS] experiences with autocommit functionality in 7.3
I was spending some time investigating how to fix the jdbc driver to deal with the autocommit functionality in 7.3. I am trying to come up with a way of using 'set autocommit = on/off' as a way of implementing the jdbc symantics for autocommit. The current code just inserts a 'begin' after every commit or rollback when autocommit is turned off in jdbc. I can continue to use the old way and just issue a 'set autocommit = on' at connection initialization, but I wanted to investigate if using 'set autocommit = off' would be a better implementation. The problem I am having is finding a way to turn autocommit on or off without generating warning messages, or without having the change accidentally rolled back later. Below is the current behavior (based on a fresh pull from cvs this morning): Key: ACon = autocommit on ACoff = autocommit off NIT = not in transaction IT = in transaction IT* = in transaction where a rollback will change autocommit state Current State ActionEnd State ACon and NITset ACon ACon and NIT set ACoff ACoff and IT* ACon and IT set ACon ACon and IT set ACoff ACoff and IT* ACon and IT*set ACon ACon and IT* set ACoff ACoff and IT ACoff and NIT set ACon ACon and NIT set ACoff ACoff and IT ACoff and ITset ACon ACon and IT* set ACoff ACoff and IT ACoff and IT* set ACon ACon and IT set ACoff ACoff and IT* There are two conclusions I have drawn from this: 1) Without the ability for the client to know the current transaction state it isn't feasible to use set autocommit = on/off in the client. There will either end up being spurious warning messages about transaction already in process or no transaction in process, or situations where a subsequent rollback can undo the change. So I will stay with the current functionality in the jdbc driver until the FE/BE protocol provides access to the transaction status. 2) In one place the current functionality doesn't make sense (at least to me). ACon and NITset ACoff ACoff and IT* If I am running in autocommit mode and I issue a command I expect that command to be committed. But that is not the case here. I would have expected the result to be: ACoff and NIT thanks, --Barry ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Transactions through dblink_exec()
On Sat, 12 Oct 2002 23:37:18 -0700
Joe Conway [EMAIL PROTECTED] wrote:
Masaru Sugawara wrote:
I'm hoping that dblink_exec() returns something like warning if those
who intend to do transactions make a declaration of
blink_exec('dbname=some', 'begin') by mistake.
for example
WARNING :You should declare dblink_exec('dbname=some', 'BEGIN; some queries;
COMMIT/ROLLBACK/END;') or use dblink_exec('BEGIN/COMMIT/ROLLBACK/END')
around dblink_exec('some queries')s. If not, your transactions won't work.
{...snip...]
-- case 3. --
SELECT dblink_exec('dbname=regression_slave', 'BEGIN');
SELECT dblink_exec('dbname=regression_slave',
'INSERT INTO foo VALUES(12,''m'',''{a12,b12,c12}'');');
SELECT dblink_exec('dbname=regression_slave', 'ROLLBACK'); -- failure !
Hmmm. No surprise this din't work. Each time you specify the connect string, a
connection is opened, the statement executed, and then the connection is
closed -- i.e. each of the invocations of dblink_exec above stands alone. Are
you suggesting a warning only on something like:
SELECT dblink_exec('dbname=regression_slave', 'BEGIN');
Yes.
? Seems like maybe a warning in the documentation would be enough.
Yes, certainly. I came to think a warning in the doc is better than in the
command line because that is not a bug.
Any other opinions out there?
What occurs to me though, is that this is one of those clients affected by
the autocommit setting situations. (...goes off and tries it out...) Sure
enough. If you have autocommit set to off, you can do:
SELECT dblink_exec('dbname=regression_slave',
'INSERT INTO foo VALUES(12,''m'',''{a12,b12,c12}'');');
all day and never get it to succeed.
I didn't think of a situation of autocommit = off. As for me in some
transactions like the following, I haven't deeply worried about behaviors of
dblink_exec(CONNSTR, 'BEGIN') because I would like to use dblink_connect() .
However, I'm not sure whether the following is perfectly safe against every
accident or not .
BEGIN;
SELECT dblink_connect('dbname=regression_slave');
SELECT dblink_exec('BEGIN');
SELECT dblink_exec('INSERT INTO foo VALUES(12, ''m'', ''{a12,b12,c12}'');');
INSERT INTO foo VALUES(12, 'm', '{a12,b12,c12}');
SELECT dblink_exec('END');
SELECT dblink_disconnect();
END;
or
CREATE OR REPLACE FUNCTION fn_mirror() RETURNS text AS '
DECLARE
ret text;
BEGIN
PERFORM dblink_connect(''dbname=regression_slave'');
PERFORM dblink_exec(''BEGIN'');
-- PERFORM dblink_exec(
-- ''INSERT INTO foo VALUES(12, m, {a12,b12,c12});'');
SELECT INTO ret * FROM dblink_exec(
''INSERT INTO foo VALUES(12, m, {a12,b12,c12});'');
RAISE NOTICE ''slave : %'', ret;
INSERT INTO foo VALUES(12, ''m'', ''{a12,b12,c12}'');
PERFORM dblink_exec(''END'');
PERFORM dblink_disconnect();
RETURN ''OK'';
END;
' LANGUAGE 'plpgsql';
SELECT fn_mirror();
Given the above, should dblink_exec(CONNSTR, SQL) always wrap SQL in an
explicit transaction? Any thoughts on this?
Joe
Regards,
Masaru Sugawara
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Transactions through dblink_exec()
Mike Mascari wrote: How can dblink() possibly be used safely for non-readonly transactions without a full implementation of a two-phase commit protocol? What happens when the remote server issues the COMMIT and then the local server crashes? It can't be used safely if you're trying to ensure a distributed transaction either fails or commits. At least I can't think of a way without two-phase commits implemented. But depending on your scenario, just being sure that the remote transaction fails or succeeds as a unit may be all you care about. 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] Transactions through dblink_exec()
Masaru Sugawara wrote:
Hi, all
While trying dblink_exec(), one of dblink()'s functions, I noticed there was an
odd situation: case 1 and case 2 worked well, but case 3 didn't(see below).
I hadn't been aware of it so that I only executed BEGIN and END in
dblink_exec() at first . This time, however, I noticed it by executing ROLLBACK.
I'm hoping that dblink_exec() returns something like warning if those who intend
to do transactions make a declaration of blink_exec('dbname=some', 'begin') by mistake.
for example
WARNING :You should declare dblink_exec('dbname=some', 'BEGIN; some queries;
COMMIT/ROLLBACK/END;') or use dblink_exec('BEGIN/COMMIT/ROLLBACK/END')
around dblink_exec('some queries')s. If not, your transactions won't work.
How can dblink() possibly be used safely for non-readonly
transactions without a full implementation of a two-phase commit
protocol? What happens when the remote server issues the COMMIT
and then the local server crashes?
Mike Mascari
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
