Re: [PATCHES] client side syntax error position (v3)
I have applied this patch, Thanks! after some considerable whacking around to make it ready to cope with multicolumn Kanji characters. It does not actually cope yet, since the necessary knowledge is not available from the character encoding logic. But replacing the two places that say scroffset += 1;/* XXX fix me when we have screen width info */ with calls to a get-the-screen-width-of-this-character subroutine should do the job. I also looked into it, and it is also a little bit more complex, as the extract width must be though from the terminal perspective. Thus the truncation part must take into account the terminal lengths. I think it would require an additionnal array to store character to terminal column mapping that would be used when truncating. I'll do that as soon as the needed routines are there for terminal lengths, and submit a new patch. I have temporarily fixed the problem shown in Fabien's original regression tests: CREATE FUNCTION test1 (int) RETURNS int LANGUAGE sql AS 'not even SQL'; ERROR: syntax error at or near not at character 1 + LINE 1: CREATE FUNCTION test1 (int) RETURNS int LANGUAGE sql + ^ [...] but I don't currently see how we can account for the string literal's starting position and possible internal quotes, backslashes, etc etc. Yep. A solution would be to generate the extract from the backend, where the information is really available, but this has been ruled out by previous discussions... -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] default psql to localhost on platforms without unix domain sockets
Bruce Momjian wrote: Andrew Dunstan wrote: Also, what is the default connection mode of psql? It should probably be equivalent to -h localhost, shouldn't it? Now that is something I had not thought of. Seems we can assume a Win32 psql can never use unix domain sockets, so defaulting that to localhost is a good solution too. The trivial patch below does this (I think). I still don't have an available Windows box for testing, so someone who does please verify. thanks andrew Index: src/bin/psql/startup.c === RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/startup.c,v retrieving revision 1.85 diff -c -r1.85 startup.c *** src/bin/psql/startup.c 19 Feb 2004 19:40:09 - 1.85 --- src/bin/psql/startup.c 15 Mar 2004 10:37:50 - *** *** 153,158 --- 153,162 pset.getPassword = false; #endif + #ifndef HAVE_UNIX_SOCKETS + options.host = localhost; + #endif + parse_psql_options(argc, argv, options); if (!pset.popt.topt.fieldSep) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] client side syntax error position (v3)
scroffset += 1;/* XXX fix me when we have screen width info */ with calls to a get-the-screen-width-of-this-character subroutine should do the job. I have committed changes adding PQdsplen() which should do the job above. Quick test with EUC-JP indicates that it is working, but still need testing for many other encodings. Also, currently for UTF-8 and MULE_INTERNAL it returns always 1, which is not correct of course. I will look into this within a week..(i have a dealine for a magazine article and have no time to do next 3 days) -- Tatsuo Ishii I also looked into it, and it is also a little bit more complex, as the extract width must be though from the terminal perspective. Thus the truncation part must take into account the terminal lengths. I think it would require an additionnal array to store character to terminal column mapping that would be used when truncating. I'll do that as soon as the needed routines are there for terminal lengths, and submit a new patch. Well, I finally noticed that you did all that already;-) So I won't have anything to do. Good;-) I should think and check before writing... Also you improved/simplified the code for the better. I've seen the gettext stuff and buffer data. I was wondering how the localisation magic could work, it is quite simpler this way. Also you changed the palloc/pfree stuff to pg_malloc/free. I'll have to check pg memory management... Thanks again, have a nice day, -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] costly foreign key ri checks (4)
Fabien COELHO [EMAIL PROTECTED] writes: I'll keep that in mind. However, from other projects I've worked on, I found that large regression tests are not wasted. Maybe two level of tests wouldn't be bad, as when you're about to release a new version, it's better to pass large tests, but when installing some light checks are enough just to check that all functionnalities are there. I think I already saw something like that somewhere in the sources? There is a provision for big tests in the regression test infrastructure. The only additional test at present is a rerun of the numeric test with greater precision choices; which personally I think is quite useless. But we could imagine using the mechanism for other stuff. 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])
[PATCHES] hint infrastructure setup (v1)
Dear patchers, Please find attached my first patch which sets an initial hint infrastructure into the sql parser. At the time it is pretty simple as I'm not yet convinced yet that I'll need a hint stack or something like that to cope with recursions, despite initial implementations I've already tried. The patch adds a current_hint variable in the parser which is to be updated by syntax rules as needed. If the variable is not NULL on a syntax error, the hint is displayed with the HINT tag already included in the error reporting functions, otherwise nothing happens. Also a new file about hints is added to the validation, but is not added to the default regression tests. The current status is that an initial hint is provided, and then no hints are available thanks to added stop-hint rules. My intent is to submit later new small incremental patches on this infrastructure so as to provide hints in various cases, typically for every sql commands such as CREATE USER, DROP TABLE and so on. My motivation not to submit a full patch is that: (1) It is a lot of work not likely to be finished quickly. As I work on that, it is pretty sure that the gram.y file will have been updated and thus there will be conflicts. (2) It would basically result in a drop-in replacement for gram.y, and that would be harder to pass through the review process. On the other hand, small patches would be much easier to be argued over and checked and then accepted or rejected. I think this is the only safe path to include such changes. Thus I wish this patch could be applied to current cvs head. I'm ready to update it if required for some stylistic or whatever reason. However, I really need to have such a patch so as to be able to go on. It modifies a lot of lines in a very simple way, but other patches should be much more narrow after this one, that's the idea... I don't think it harms the parser code, as it validates for me. Thanks in advance, -- Fabien Coelho - [EMAIL PROTECTED] hints_0.patch.gz Description: Binary data ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] ANALYZE patch for review
Hi Tom, Having been working with the PostGIS team to implement a custom analyze routine for R-Tree selectivity, we have a question regarding the new vacuum_delay_point() which is present in analyze.c. Is it the responsibility of the programmers to remember to do a vacuum_delay_point() before calling the fetch_func(), or would it be better to move the vacuum_delay_point() into std_fetch_func()? It would seem to make more sense that the throttling is done by PostgreSQL rather than requiring programmers to have to remember to include the extra function call before calling the fetch_func() themselves. Many thanks, Mark. --- Mark Cave-Ayland Webbased Ltd. Tamar Science Park Derriford Plymouth PL6 8BX England Tel: +44 (0)1752 764445 Fax: +44 (0)1752 764446 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] remove log_timestamp, log_pid and log_source_port GUC
Patch applied. Thanks. --- Andrew Dunstan wrote: Bruce Momjian wrote: Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: Please don't. Declare them obsolete for 7.5 and remove them in a later release. Nah, just remove them. We've removed, added and changed so many config options and no-one's ever complained... I agree with Chris; this would be taking compatibility concerns a bit far. None of these variables are likely to be touched except through postgresql.conf (I don't think we even allow them to be SET interactively). And you can never simply take your old .conf file and plop it down into a new release. And the other reason to remove them is that if you don't, you will get all sorts of confusion about people asking, Which one should I use for pid logging? Looks like both work. OK, Here's the patch. Also makes some minor improvements in the docco for log_line_prefix. cheers andrew Index: doc/src/sgml/runtime.sgml === RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v retrieving revision 1.248 diff -c -r1.248 runtime.sgml *** doc/src/sgml/runtime.sgml 9 Mar 2004 23:15:47 - 1.248 --- doc/src/sgml/runtime.sgml 10 Mar 2004 16:07:46 - *** *** 1993,1999 para Causes the duration of every completed statement to be logged. To use this option, it is recommended that you also enable ! varnamelog_statement/ and varnamelog_pid/ so that you can link the statement to the duration using the process ID. The default is off. Only superusers can turn off this option if it is enabled by the administrator. --- 1993,2000 para Causes the duration of every completed statement to be logged. To use this option, it is recommended that you also enable ! varnamelog_statement/ and if not using applicationsyslog/ ! log the PID using varnamelog_line_prefix/ so that you can link the statement to the duration using the process ID. The default is off. Only superusers can turn off this option if it is enabled by the administrator. *** *** 2014,2019 --- 2015,2022 processes without controlling sessions. applicationSyslog/ produces its own timestamp and process ID information, so you probably do not want to use those escapes if you are using applicationsyslog/. + This option can only be set at server start or in the + filenamepostgresql.conf/filename configuration file. informaltable tgroup cols=3 thead *** *** 2058,2064 row entryliteral%c/literal/entry entrySession ID. A unique identifier for each session. ! It is 2 4-byte hexadecimal numbers separated by a dot. The numbers are the Session Start Time and the Process ID, so this can also be used as a space saving way of printing these items./entry entryYes/entry --- 2061,2068 row entryliteral%c/literal/entry entrySession ID. A unique identifier for each session. ! It is 2 4-byte hexadecimal numbers (without leading zeros) ! separated by a dot. The numbers are the Session Start Time and the Process ID, so this can also be used as a space saving way of printing these items./entry entryYes/entry *** *** 2093,2111 /listitem /varlistentry - varlistentry - termvarnamelog_pid/varname (typeboolean/type)/term - listitem -para - Prefixes each message in the server log file with the process ID of - the server process. This is useful to sort out which messages - pertain to which connection. The default is off. This parameter - does not affect messages logged via applicationsyslog/, which - always contain the process ID. -/para - /listitem - /varlistentry - varlistentry id=guc-log-statement xreflabel=log_statement termvarnamelog_statement/varname (typeboolean/type)/term listitem --- 2097,2102 *** *** 2120,2135 /listitem /varlistentry - varlistentry id=guc-log-timestamp xreflabel=log_timestamp - termvarnamelog_timestamp/varname (typeboolean/type)/term - listitem -para - Prefixes each server log message with a time stamp. The default - is off. -/para - /listitem - /varlistentry - varlistentry id=guc-log-hostname xreflabel=log_hostname termvarnamelog_hostname/varname
Re: [PATCHES] [pgsql-hackers-win32] initdb problen
Patch applied. Thanks. --- Andrew Dunstan wrote: I believe that the attached patch may solve this setlocale() problem, but I do not have a Windows box handy on which to test it. Can somebody who does please try and let us know the results? thanks andrew Andrew Dunstan wrote: the answer is very probably here: http://archives.postgresql.org/pgsql-hackers-win32/2003-10/msg00024.php I thought Bruce said he had this covered, but it hasn't been fixed. I will prepare a patch in the next day or so if someone else doesn't beat me to it. cheers andrew Korea PostgreSQL Users' Group wrote: it works still problem. setlocale() function is not equivalent between unix and win32 plz check. multibyte text is not sorted. - Original Message - From: Claudio Natoli [EMAIL PROTECTED] To: 'Korea PostgreSQL Users' Group' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, March 12, 2004 5:04 PM Subject: RE: [pgsql-hackers-win32] initdb problen What if you instead try: initdb --locale=C Looks like --no-locale is not equivalent to --locale=C, at least under win32. Cheers, Claudio ---(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 ---(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 Index: src/backend/main/main.c === RCS file: /projects/cvsroot/pgsql-server/src/backend/main/main.c,v retrieving revision 1.75 diff -c -r1.75 main.c *** src/backend/main/main.c 5 Mar 2004 01:11:04 - 1.75 --- src/backend/main/main.c 12 Mar 2004 16:27:13 - *** *** 74,79 --- 74,83 #endif /* NOPRINTADE */ #endif /* __alpha */ + #ifdef WIN32 + char *env_locale; + #endif + #if defined(NOFIXADE) || defined(NOPRINTADE) #if defined(ultrix4) *** *** 143,150 --- 147,176 * set later during GUC option processing, but we set it here to allow * startup error messages to be localized. */ + + #ifdef WIN32 + /* + * Windows uses codepages rather than the environment, so we work around + * that by querying the environment explicitly first for LC_COLLATE + * and LC_CTYPE. We have to do this because initdb passes those values + * in the environment. If there is nothing there we fall back on the + * codepage. + */ + + if ((env_locale = getenv(LC_COLLATE)) != NULL) + setlocale(LC_COLLATE,env_locale); + else + setlocale(LC_COLLATE, ); + + if ((env_locale = getenv(LC_CTYPE)) != NULL) + setlocale(LC_CTYPE,env_locale); + else + setlocale(LC_CTYPE, ); + #else setlocale(LC_COLLATE, ); setlocale(LC_CTYPE, ); + #endif + #ifdef LC_MESSAGES setlocale(LC_MESSAGES, ); #endif ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- 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: [PATCHES] misc patches (minor)
Patch applied. Thanks. --- Claudio Natoli wrote: For application to HEAD. Minor cleanup. * postmaster.c: cleanup pmdaemonize under win32; missed failure message in CreateOptsFile * s_lock.c: minor comment fix * findbe.c: variables not used under win32 moved within #ifndef WIN32 case --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a href=http://www.memetrics.com/emailpolicy.html;http://www.memetrics.com/em ailpolicy.html/a [ Attachment, skipping... ] ---(end of broadcast)--- TIP 8: explain analyze is your friend -- 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 8: explain analyze is your friend
Re: [PATCHES] ECPG - Remove need for AT connection when using threads
The cvs add of test_thread_implicit.pgc seems to have been missed,
i've attached this again.
Additionally I include a small patch to remove mutex locking when a
DEFAULT/NULL connection is being retrieved. This is consistent with
libpq.
Thanks, L.
Michael Meskes writes:
On Sun, Mar 14, 2004 at 09:11:27AM -0500, Bruce Momjian wrote:
I just applied this patch and the last one.
I assume you mean you applied:
Update tests memory leak fix
and
ECPG - Remove need for AT connection when using threads
Yes. Sorry, should have said so.
Michael
/*
* Thread test program
* by Lee Kindness.
*/
/* #define ECPGDEBUG */
#include pthread.h
#include stdlib.h
void *test_thread(void *arg);
EXEC SQL BEGIN DECLARE SECTION;
char *l_dbname;
EXEC SQL END DECLARE SECTION;
int nthreads = 2;
int iterations = 10;
int main(int argc, char *argv[])
{
#ifdef ECPGDEBUG
char debugfilename[] = thread_test_implicit.log;
FILE *debugfile;
#endif
pthread_t *threads;
int n;
EXEC SQL BEGIN DECLARE SECTION;
int l_rows;
EXEC SQL END DECLARE SECTION;
/* parse command line arguments */
if( (argc 2) || (argc 4) )
{
fprintf(stderr, Usage: %s dbname [threads] [iterations_per_thread]\n, argv[0]);
return( 1 );
}
l_dbname = argv[1];
if( argc = 3 )
nthreads = atoi(argv[2]);
if( argc == 4 )
iterations = atoi(argv[3]);
/* open ECPG debug log? */
#ifdef ECPGDEBUG
debugfile = fopen(debugfilename, w);
if( debugfile != NULL )
ECPGdebug(1, debugfile);
else
fprintf(stderr, Cannot open ECPG debug log: %s\n, debugfilename);
#endif
/* setup test_thread table */
EXEC SQL CONNECT TO:l_dbname;
EXEC SQL DROP TABLE test_thread; /* DROP might fail */
EXEC SQL COMMIT;
EXEC SQL CREATE TABLE
test_thread(tstampTIMESTAMP NOT NULL DEFAULT CAST(timeofday() AS TIMESTAMP),
threadTEXT NOT NULL,
iteration INTEGER NOT NULL,
PRIMARY KEY(thread, iteration));
EXEC SQL COMMIT;
EXEC SQL DISCONNECT;
/* create, and start, threads */
threads = calloc(nthreads, sizeof(pthread_t));
if( threads == NULL )
{
fprintf(stderr, Cannot alloc memory\n);
return( 1 );
}
for( n = 0; n nthreads; n++ )
{
pthread_create(threads[n], NULL, test_thread, (void *)n + 1);
}
/* wait for thread completion */
for( n = 0; n nthreads; n++ )
{
pthread_join(threads[n], NULL);
}
free(threads);
/* and check results */
EXEC SQL CONNECT TO :l_dbname;
EXEC SQL SELECT COUNT(*) INTO :l_rows FROM test_thread;
EXEC SQL COMMIT;
EXEC SQL DISCONNECT;
if( l_rows == (nthreads * iterations) )
printf(\nSuccess.\n);
else
printf(\nERROR: Failure - expecting %d rows, got %d.\n, nthreads * iterations,
l_rows);
/* close ECPG debug log? */
#ifdef ECPGDEBUG
if( debugfile != NULL )
{
ECPGdebug(0, debugfile);
fclose(debugfile);
}
#endif
return( 0 );
}
void *test_thread(void *arg)
{
long threadnum = (long)arg;
EXEC SQL BEGIN DECLARE SECTION;
int l_i;
char l_connection[128];
EXEC SQL END DECLARE SECTION;
/* build up connection name, and connect to database */
snprintf(l_connection, sizeof(l_connection), thread_%03ld, threadnum);
EXEC SQL WHENEVER sqlerror sqlprint;
EXEC SQL CONNECT TO :l_dbname AS :l_connection;
if( sqlca.sqlcode != 0 )
{
printf(%s: ERROR: cannot connect to database!\n, l_connection);
return( NULL );
}
EXEC SQL BEGIN;
/* insert into test_thread table */
for( l_i = 1; l_i = iterations; l_i++ )
{
printf(%s: inserting %d\n, l_connection, l_i);
EXEC SQL INSERT INTO test_thread(thread, iteration) VALUES(:l_connection, :l_i);
if( sqlca.sqlcode == 0 )
printf(%s: insert done\n, l_connection);
else
printf(%s: ERROR: insert failed!\n, l_connection);
}
/* all done */
EXEC SQL COMMIT;
EXEC SQL DISCONNECT :l_connection;
printf(%s: done!\n, l_connection);
return( NULL );
}
Index: src/interfaces/ecpg/ecpglib/connect.c
===
RCS file: /projects/cvsroot/pgsql-server/src/interfaces/ecpg/ecpglib/connect.c,v
retrieving revision 1.20
diff -c -r1.20 connect.c
*** src/interfaces/ecpg/ecpglib/connect.c 14 Mar 2004 12:16:29 - 1.20
--- src/interfaces/ecpg/ecpglib/connect.c 15 Mar 2004 16:17:36 -
***
*** 62,79
{
struct connection *ret = NULL;
#ifdef ENABLE_THREAD_SAFETY
! pthread_mutex_lock(connections_mutex);
#endif
! ret = ecpg_get_connection_nr(connection_name);
#ifdef ENABLE_THREAD_SAFETY
! pthread_mutex_unlock(connections_mutex);
#endif
return (ret);
-
}
static void
--- 62,89
{
struct connection *ret = NULL;
+ if ((connection_name == NULL) || (strcmp(connection_name, CURRENT) == 0))
+ {
#ifdef
Re: [PATCHES] ECPG - Remove need for AT connection when using threads
Patch applied. File added. Thanks.
---
Lee Kindness wrote:
Content-Description: message body text
The cvs add of test_thread_implicit.pgc seems to have been missed,
i've attached this again.
Additionally I include a small patch to remove mutex locking when a
DEFAULT/NULL connection is being retrieved. This is consistent with
libpq.
Thanks, L.
Michael Meskes writes:
On Sun, Mar 14, 2004 at 09:11:27AM -0500, Bruce Momjian wrote:
I just applied this patch and the last one.
I assume you mean you applied:
Update tests memory leak fix
and
ECPG - Remove need for AT connection when using threads
Yes. Sorry, should have said so.
Michael
/*
*Thread test program
*by Lee Kindness.
*/
/* #define ECPGDEBUG */
#include pthread.h
#include stdlib.h
void *test_thread(void *arg);
EXEC SQL BEGIN DECLARE SECTION;
char *l_dbname;
EXEC SQL END DECLARE SECTION;
int nthreads = 2;
int iterations = 10;
int main(int argc, char *argv[])
{
#ifdef ECPGDEBUG
char debugfilename[] = thread_test_implicit.log;
FILE *debugfile;
#endif
pthread_t *threads;
int n;
EXEC SQL BEGIN DECLARE SECTION;
int l_rows;
EXEC SQL END DECLARE SECTION;
/* parse command line arguments */
if( (argc 2) || (argc 4) )
{
fprintf(stderr, Usage: %s dbname [threads] [iterations_per_thread]\n,
argv[0]);
return( 1 );
}
l_dbname = argv[1];
if( argc = 3 )
nthreads = atoi(argv[2]);
if( argc == 4 )
iterations = atoi(argv[3]);
/* open ECPG debug log? */
#ifdef ECPGDEBUG
debugfile = fopen(debugfilename, w);
if( debugfile != NULL )
ECPGdebug(1, debugfile);
else
fprintf(stderr, Cannot open ECPG debug log: %s\n, debugfilename);
#endif
/* setup test_thread table */
EXEC SQL CONNECT TO:l_dbname;
EXEC SQL DROP TABLE test_thread; /* DROP might fail */
EXEC SQL COMMIT;
EXEC SQL CREATE TABLE
test_thread(tstampTIMESTAMP NOT NULL DEFAULT CAST(timeofday() AS TIMESTAMP),
threadTEXT NOT NULL,
iteration INTEGER NOT NULL,
PRIMARY KEY(thread, iteration));
EXEC SQL COMMIT;
EXEC SQL DISCONNECT;
/* create, and start, threads */
threads = calloc(nthreads, sizeof(pthread_t));
if( threads == NULL )
{
fprintf(stderr, Cannot alloc memory\n);
return( 1 );
}
for( n = 0; n nthreads; n++ )
{
pthread_create(threads[n], NULL, test_thread, (void *)n + 1);
}
/* wait for thread completion */
for( n = 0; n nthreads; n++ )
{
pthread_join(threads[n], NULL);
}
free(threads);
/* and check results */
EXEC SQL CONNECT TO :l_dbname;
EXEC SQL SELECT COUNT(*) INTO :l_rows FROM test_thread;
EXEC SQL COMMIT;
EXEC SQL DISCONNECT;
if( l_rows == (nthreads * iterations) )
printf(\nSuccess.\n);
else
printf(\nERROR: Failure - expecting %d rows, got %d.\n, nthreads * iterations,
l_rows);
/* close ECPG debug log? */
#ifdef ECPGDEBUG
if( debugfile != NULL )
{
ECPGdebug(0, debugfile);
fclose(debugfile);
}
#endif
return( 0 );
}
void *test_thread(void *arg)
{
long threadnum = (long)arg;
EXEC SQL BEGIN DECLARE SECTION;
int l_i;
char l_connection[128];
EXEC SQL END DECLARE SECTION;
/* build up connection name, and connect to database */
snprintf(l_connection, sizeof(l_connection), thread_%03ld, threadnum);
EXEC SQL WHENEVER sqlerror sqlprint;
EXEC SQL CONNECT TO :l_dbname AS :l_connection;
if( sqlca.sqlcode != 0 )
{
printf(%s: ERROR: cannot connect to database!\n, l_connection);
return( NULL );
}
EXEC SQL BEGIN;
/* insert into test_thread table */
for( l_i = 1; l_i = iterations; l_i++ )
{
printf(%s: inserting %d\n, l_connection, l_i);
EXEC SQL INSERT INTO test_thread(thread, iteration) VALUES(:l_connection,
:l_i);
if( sqlca.sqlcode == 0 )
printf(%s: insert done\n, l_connection);
else
printf(%s: ERROR: insert failed!\n, l_connection);
}
/* all done */
EXEC SQL COMMIT;
EXEC SQL DISCONNECT :l_connection;
printf(%s: done!\n, l_connection);
return( NULL );
}
Index: src/interfaces/ecpg/ecpglib/connect.c
===
RCS file: /projects/cvsroot/pgsql-server/src/interfaces/ecpg/ecpglib/connect.c,v
retrieving revision 1.20
diff -c -r1.20 connect.c
*** src/interfaces/ecpg/ecpglib/connect.c 14 Mar 2004 12:16:29 - 1.20
--- src/interfaces/ecpg/ecpglib/connect.c 15 Mar 2004 16:17:36 -
***
*** 62,79
{
struct connection *ret = NULL;
#ifdef ENABLE_THREAD_SAFETY
! pthread_mutex_lock(connections_mutex);
#endif
! ret =
Re: [PATCHES] ECPG - Remove need for AT connection when using threads
On Sun, Mar 07, 2004 at 09:43:31PM -, Lee Kindness wrote: Attached diff improves the handling of connections in ecpg when threading is used. The current connection is now the last connection made/set for the I just applied this patch and the last one. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] ECPG - Remove need for AT connection when using threads
On Sun, Mar 14, 2004 at 09:11:27AM -0500, Bruce Momjian wrote: I just applied this patch and the last one. I assume you mean you applied: Update tests memory leak fix and ECPG - Remove need for AT connection when using threads Yes. Sorry, should have said so. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 8: explain analyze is your friend
[PATCHES] Update french translation of the 7.4 branch
Hi, Here are some updates of the french .po files. ## pg_dump-fr.po 391 messages traduits. ## pg_resetxlog-fr.po 57 messages traduits. ## pgscripts-fr.po 112 messages traduits. ## psql-fr.po 455 messages traduits. pg_resetxlog, pg_dump and pgscripts .po files are new ones. They need to be apply with the 7.4 branch. Thanks. -- Guillaume. !-- http://abs.ptithibou.org/ http://pgsql.ptithibou.org/ -- pg_dump-fr.po.bz2 Description: application/bzip pg_resetxlog-fr.po.bz2 Description: application/bzip pgscripts-fr.po.bz2 Description: application/bzip psql-fr.po.bz2 Description: application/bzip ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] [pgsql-hackers-win32] win32 open patch for held unlink
Claudio, how does this handle renames if the file is open by someone else? Does this remove the need to loop over the rename? To be honest, I don't know that it does. [Will report back later.] Two points though: a) This could doesn't alleviate the needs for dirmod.c, as far as I'm aware. That seems to be there for a different reason, namely that there appears to be some timing issue between creating a file and issuing an unlink/rename. b) Do we have a case where rename's can block because of the file being held open by another process? I haven't tripped over this yet... Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a href=http://www.memetrics.com/emailpolicy.html;http://www.memetrics.com/em ailpolicy.html/a ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [pgsql-hackers-win32] win32 open patch for held unlink
a) This could doesn't alleviate the needs for dirmod.c, as This CODE doesn't alleviate the NEED for... Sheesh, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a href=http://www.memetrics.com/emailpolicy.html;http://www.memetrics.com/em ailpolicy.html/a ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [pgsql-hackers-win32] win32 open patch for held unlink
Agreed, we still need dirmod.c in case someone has opened it using a non-unix mode. Ok. Wanted to make sure I was on the same page. My only question was whether this new mode makes rename possible on a target file opened by another backend. Looks good. Wrote a pair of 2 liner driver programs to test. Renaming fails when the file is open()'d, but proceeds correctly when win32_open()'d. Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a href=http://www.memetrics.com/emailpolicy.html;http://www.memetrics.com/em ailpolicy.html/a ---(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
[PATCHES] Removal of win32-specific rename code
Claudio found that his new delete fix for Win32 also works for rename on
files open by other processes, so I have applied the following patch to
remove the special rename() handling on Win32. What it used to do was
to rename a file to a *.new, release locks, then do the rename to the
main file. WIth Claudio's fix, this isn't necessary.
--
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/backend/commands/user.c
===
RCS file: /cvsroot/pgsql-server/src/backend/commands/user.c,v
retrieving revision 1.138
diff -c -c -r1.138 user.c
*** src/backend/commands/user.c 25 Feb 2004 19:41:22 - 1.138
--- src/backend/commands/user.c 16 Mar 2004 04:51:18 -
***
*** 140,149
bufsize = strlen(filename) + 12;
tempname = (char *) palloc(bufsize);
snprintf(tempname, bufsize, %s.%d, filename, MyProcPid);
- #if defined(WIN32) || defined(__CYGWIN__)
- filename = repalloc(filename, strlen(filename) + 1 + strlen(.new));
- strcat(filename, .new);
- #endif
oumask = umask((mode_t) 077);
fp = AllocateFile(tempname, w);
--- 140,145
***
*** 291,300
bufsize = strlen(filename) + 12;
tempname = (char *) palloc(bufsize);
snprintf(tempname, bufsize, %s.%d, filename, MyProcPid);
- #if defined(WIN32) || defined(__CYGWIN__)
- filename = repalloc(filename, strlen(filename) + 1 + strlen(.new));
- strcat(filename, .new);
- #endif
oumask = umask((mode_t) 077);
fp = AllocateFile(tempname, w);
--- 287,292
***
*** 466,483
user_file_update_needed = false;
write_user_file(urel);
heap_close(urel, NoLock);
- #if defined(WIN32) || defined(__CYGWIN__)
- {
- /* Rename active file while not holding an exclusive lock */
- char *filename = user_getfilename(), *filename_new;
-
- filename_new = palloc(strlen(filename) + 1 + strlen(.new));
- sprintf(filename_new, %s.new, filename);
- rename(filename_new, filename);
- pfree(filename);
- pfree(filename_new);
- }
- #endif
}
if (group_file_update_needed)
--- 458,463
***
*** 485,502
group_file_update_needed = false;
write_group_file(grel);
heap_close(grel, NoLock);
- #if defined(WIN32) || defined(__CYGWIN__)
- {
- /* Rename active file while not holding an exclusive lock */
- char *filename = group_getfilename(), *filename_new;
-
- filename_new = palloc(strlen(filename) + 1 + strlen(.new));
- sprintf(filename_new, %s.new, filename);
- rename(filename_new, filename);
- pfree(filename);
- pfree(filename_new);
- }
- #endif
}
/*
--- 465,470
Index: src/backend/utils/cache/relcache.c
===
RCS file: /cvsroot/pgsql-server/src/backend/utils/cache/relcache.c,v
retrieving revision 1.199
diff -c -c -r1.199 relcache.c
*** src/backend/utils/cache/relcache.c 14 Mar 2004 23:41:27 - 1.199
--- src/backend/utils/cache/relcache.c 16 Mar 2004 04:51:25 -
***
*** 3278,3297
* OK, rename the temp file to its final name, deleting any
* previously-existing init file.
*/
- #if defined(WIN32) || defined(__CYGWIN__)
rename(tempfilename, finalfilename);
LWLockRelease(RelCacheInitLock);
- #else
- {
- charfinalfilename_new[MAXPGPATH];
-
- snprintf(finalfilename_new, sizeof(finalfilename_new),
%s.new, finalfilename);
- rename(tempfilename, finalfilename_new);
- LWLockRelease(RelCacheInitLock);
- /* Rename to active file after lock is released */
- rename(finalfilename_new, finalfilename);
- }
- #endif
}
else
{
--- 3278,3285
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [PATCHES] Removal of win32-specific rename code
main file. WIth Claudio's fix, this isn't necessary. Bruce, are you sure this is true? The fix is only for files than are open()'d, not fopen()'d (as per AllocateFile). Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a href=http://www.memetrics.com/emailpolicy.html;http://www.memetrics.com/em ailpolicy.html/a ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
