Re: [PATCHES] contrib dbf2sql.pl
Manuel Baena García wrote: - It solve problems with numeric columns. http://archives.postgresql.org/pgsql-novice/2005-01/msg00246.php http://archives.postgresql.org/pgsql-general/2005-01/msg01382.php - The output is in SQL. Uh, can't you just fix the existing version rather than make a new program? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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/docs/faq
Re: [PATCHES] Faster install-sh in C
On Mon, Mar 07, 2005 at 07:50:23PM +0100, Peter Eisentraut wrote: Alvaro Herrera wrote: Well, apparently everyone says the system install is not portable and the discussion stops there. Well, who actually says that? I know that I was the one who actually coded up the current avoid-system-install-at-all-cost behavior, but only because we were too annoyed at the time to do more research. Now, as long as someone's spending time on it, it may be worth investigating what is wrong and provide an explanation for the benefit of the entire autotools-using community. Well, the problem with this approach is that while I did have time to write the C replacement, I didn't (and still don't) have access to a lot of systems in order to check what the differences between the install programs are. Also, keep in my that this C install program has the extra feature of being able to install multiple files on one invocation, per suggestion from Tom Lane. This allows us to save the nested for-loop in src/include/Makefile. GNU install (available on my system) also has this capability, but would we be able to use the trick if we had to cater for the lowest common denominator found on other, non-GNU-enabled systems? -- Alvaro Herrera ([EMAIL PROTECTED]) Llegará una época en la que una investigación diligente y prolongada sacará a la luz cosas que hoy están ocultas (Séneca, siglo I) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Faster install-sh in C
Alvaro Herrera [EMAIL PROTECTED] writes: Also, keep in my that this C install program has the extra feature of being able to install multiple files on one invocation, per suggestion from Tom Lane. This allows us to save the nested for-loop in src/include/Makefile. GNU install (available on my system) also has this capability, but would we be able to use the trick if we had to cater for the lowest common denominator found on other, non-GNU-enabled systems? We would definitely not ... and my suspicion is that that is the largest single component of the available speedup. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Faster install-sh in C
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Also, keep in my that this C install program has the extra feature of being able to install multiple files on one invocation, per suggestion from Tom Lane. This allows us to save the nested for-loop in src/include/Makefile. GNU install (available on my system) also has this capability, but would we be able to use the trick if we had to cater for the lowest common denominator found on other, non-GNU-enabled systems? We would definitely not ... and my suspicion is that that is the largest single component of the available speedup. OK, what is 'install' doing for us that 'cp' and 'chmod' would not already do? The following patch reduces the 'gmake install' in /src/include from 8 seconds to 0.8 seconds. Oh, and for testing I use a sourceforge shell farm account, and a HP testdrive shell acount that gives me access to almost every operating system. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Index: src/include/Makefile === RCS file: /cvsroot/pgsql/src/include/Makefile,v retrieving revision 1.19 diff -c -c -r1.19 Makefile *** src/include/Makefile6 Jan 2005 21:00:24 - 1.19 --- src/include/Makefile23 Mar 2005 20:22:56 - *** *** 41,49 $(INSTALL_DATA) $$file $(DESTDIR)$(includedir_server)/`basename $$file` || exit; \ done for dir in $(SUBDIRS); do \ ! for file in $(srcdir)/$$dir/*.h; do \ ! $(INSTALL_DATA) $$file $(DESTDIR)$(includedir_server)/$$dir/`basename $$file` || exit; \ ! done \ done installdirs: --- 41,48 $(INSTALL_DATA) $$file $(DESTDIR)$(includedir_server)/`basename $$file` || exit; \ done for dir in $(SUBDIRS); do \ ! cp $(srcdir)/$$dir/*.h $(DESTDIR)$(includedir_server)/$$dir/ || exit; \ ! chmod 644 $(DESTDIR)$(includedir_server)/$$dir/*.h || exit; \ done installdirs: ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Faster install-sh in C
Bruce Momjian pgman@candle.pha.pa.us writes: OK, what is 'install' doing for us that 'cp' and 'chmod' would not already do? Quite a lot of things, such as coping with busy target files --- not too important for headers, but very important for executables and shlibs. We might be able to get away with this for just the headers, though, and that's certainly the bulk of the install work now. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] contrib dbf2sql.pl
Manuel Baena García wrote: ok, It's more difficult to fix the existing version. I don't want to do a new library. I just use the perl module DBD-XBase rather than rewrite a library (contrib/dbase/dbf.c). Also, dbf2sql is a perl program... you can to adapt it to your needs easily. Are you saying your script has all the functionality of dbf2pg.c? It doesn't seem possible. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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] Faster install-sh in C
Alvaro Herrera wrote: Also, keep in my that this C install program has the extra feature of being able to install multiple files on one invocation, per suggestion from Tom Lane. This allows us to save the nested for-loop in src/include/Makefile. GNU install (available on my system) also has this capability, but would we be able to use the trick if we had to cater for the lowest common denominator found on other, non-GNU-enabled systems? Why not check for GNU install in configure, and only enable the optimization if it is available? -Neil ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[PATCHES] SPI_getnspname
I noticed there is an SPI API function to get the name of a specified
Relation, but no similar function to get the Relation's namespace.
Attached is a patch that implements SPI_getnspname().
I wasn't sure if I should refer to the relation's schema or its
namespace; my feeling was that SPI is sufficiently close to the
internals that we should use the internal term, which is namespace.
Barring any objections, I'll apply this later today.
-Neil
Index: doc/src/sgml/spi.sgml
===
RCS file: /var/lib/cvs/pgsql/doc/src/sgml/spi.sgml,v
retrieving revision 1.39
diff -c -r1.39 spi.sgml
*** doc/src/sgml/spi.sgml 22 Jan 2005 22:56:36 - 1.39
--- doc/src/sgml/spi.sgml 24 Mar 2005 01:52:11 -
***
*** 2153,2158
--- 2153,2212
/refsect1
/refentry
+ refentry id=spi-spi-getnspname
+ refmeta
+ refentrytitleSPI_getnspname/refentrytitle
+ /refmeta
+
+ refnamediv
+ refnameSPI_getnspname/refname
+ refpurposereturn the namespace of the specified relation/refpurpose
+ /refnamediv
+
+ indextermprimarySPI_getnspname/primary/indexterm
+
+ refsynopsisdiv
+ synopsis
+ char * SPI_getnspname(Relation parameterrel/parameter)
+ /synopsis
+ /refsynopsisdiv
+
+ refsect1
+ titleDescription/title
+
+ para
+functionSPI_getnspname/function returns a copy of the name of
+the namespace that the specified structnameRelation/structname
+belongs to. This is equivalent to the relation's schema. You should
+functionpfree/function the return value of this function when
+you are finished with it.
+ /para
+ /refsect1
+
+ refsect1
+ titleArguments/title
+
+ variablelist
+varlistentry
+ termliteralRelation parameterrel/parameter/literal/term
+ listitem
+ para
+ input relation
+ /para
+ /listitem
+/varlistentry
+ /variablelist
+ /refsect1
+
+ refsect1
+ titleReturn Value/title
+
+ para
+The name of the specified relation's namespace.
+ /para
+ /refsect1
+ /refentry
+
/sect1
sect1 id=spi-memory
Index: src/backend/executor/spi.c
===
RCS file: /var/lib/cvs/pgsql/src/backend/executor/spi.c,v
retrieving revision 1.135
diff -c -r1.135 spi.c
*** src/backend/executor/spi.c 16 Mar 2005 21:38:08 - 1.135
--- src/backend/executor/spi.c 23 Mar 2005 09:08:42 -
***
*** 760,765
--- 760,771
return pstrdup(RelationGetRelationName(rel));
}
+ char *
+ SPI_getnspname(Relation rel)
+ {
+ return get_namespace_name(RelationGetNamespace(rel));
+ }
+
void *
SPI_palloc(Size size)
{
Index: src/include/executor/spi.h
===
RCS file: /var/lib/cvs/pgsql/src/include/executor/spi.h,v
retrieving revision 1.50
diff -c -r1.50 spi.h
*** src/include/executor/spi.h 16 Nov 2004 18:10:13 - 1.50
--- src/include/executor/spi.h 23 Mar 2005 09:09:50 -
***
*** 113,118
--- 113,119
extern char *SPI_gettype(TupleDesc tupdesc, int fnumber);
extern Oid SPI_gettypeid(TupleDesc tupdesc, int fnumber);
extern char *SPI_getrelname(Relation rel);
+ extern char *SPI_getnspname(Relation rel);
extern void *SPI_palloc(Size size);
extern void *SPI_repalloc(void *pointer, Size size);
extern void SPI_pfree(void *pointer);
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [PATCHES] [pgsql-hackers-win32] [HACKERS] win32 performance - fsync question
I have applied the following patch to CVS HEAD and 8.0.X that changes the Win32 O_SYNC flag to O_DATASYNC, because this the actual behavior of the flag. This is now the default wal fsync method on Win32 because we perfer O_DATASYNC to fsync(). And second, it changes Win32 fsync to a new wal sync method called fsync_writethrough which is the old Win32 fsync behavior, which uses _commit(). --- Magnus Hagander wrote: * Win32, with fsync, write-cache disabled: no data corruption * Win32, with fsync, write-cache enabled: no data corruption * Win32, with osync, write cache disabled: no data corruption * Win32, with osync, write cache enabled: no data corruption. Once I got: 2005-02-24 12:19:54 LOG: could not open file C:/Program Files/PostgreSQL/8.0/data/pg_xlog/00010010 (log file 0, segment 16): No such file or directory but the data in the database was consistent. It disturbs me that you couldn't produce data corruption in the cases where it theoretically should occur. Seems like this is an indication that your test was insufficiently severe, or that there is something going on we don't understand. The Windows driver knows abotu the write cache, and at least fsync() pushes through the write cache even if it's there. This seems to indicate taht O_SYNC at least partiallyi does this as well. This is why there is no performance difference at all on fsync() with write cache on or off. I don't know if this is true for all IDE disks. COuld be that my disk is particularly well-behaved. This indicated to me that open_sync did not require any additional changes than our current fsync. fsync and open_sync both write through the write cache in the operating system. Only fsync=off turns this off. fsync also writes through the hardware write cache. o_sync does not. This is what causes the large slowdown with write cache enabled, *including* most battery backed write cache systems (pretty much making the write-cache a waste of money). This may be a good thing on IDE systems (for admins that don't know how to remove the little check in the box for enable write caching on the disk that MS provides, which *explicitly* warns that you may lose data if you enabled it), but it's a very bad thing for anything higher end. fsync also syncs the directory metadata. o_sync only cares about the files contents. (This is what causes the large slowdown with write cache *disabled*, becuase it requires multiple writes on multiple disk locations for each fsync). Basically, fsync hurts people who configure their box correctly, or who use things like SCSI disks. o_sync hurts people who configure their machine in an unsafe way. //Magnus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Index: doc/src/sgml/runtime.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v retrieving revision 1.310 diff -c -c -r1.310 runtime.sgml *** doc/src/sgml/runtime.sgml 19 Mar 2005 23:27:04 - 1.310 --- doc/src/sgml/runtime.sgml 24 Mar 2005 04:27:11 - *** *** 1587,1592 --- 1587,1593 values are literalfsync/ (call functionfsync()/ at each commit), literalfdatasync/ (call functionfdatasync()/ at each commit), + literalfsync_writethrough/ (call function_commit()/ at each commit on Windows), literalopen_sync/ (write WAL files with functionopen()/ option symbolO_SYNC/), and literalopen_datasync/ (write WAL files with functionopen()/ option symbolO_DSYNC/). Not all of these choices are available on all platforms. Index: src/backend/access/transam/xlog.c === RCS file: /cvsroot/pgsql/src/backend/access/transam/xlog.c,v retrieving revision 1.181 diff -c -c -r1.181 xlog.c *** src/backend/access/transam/xlog.c 12 Feb 2005 23:53:37 - 1.181 --- src/backend/access/transam/xlog.c 24 Mar 2005 04:27:15 - *** *** 63,70 #endif #endif #if defined(OPEN_SYNC_FLAG) ! #if defined(O_DSYNC) (O_DSYNC != OPEN_SYNC_FLAG) #define OPEN_DATASYNC_FLAG O_DSYNC #endif #endif --- 63,75 #endif #endif + #if defined(O_DSYNC) #if defined(OPEN_SYNC_FLAG) ! #if O_DSYNC != OPEN_SYNC_FLAG ! #define OPEN_DATASYNC_FLAG O_DSYNC ! #endif ! #else /* !defined(OPEN_SYNC_FLAG) */ ! /* Win32
Re: [PATCHES] PL/Python patch for Universal Newline Support
Here's a PL/Python patch that includes a few tests for Universal
Newline Support. gmake installcheck in src/pl/plpython is
successful in HEAD on my Solaris 9 box running Python 2.4.1c2.
I ran the tests against an unpatched 8.0.1 server and they failed
as expected.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
Index: src/pl/plpython/feature.expected
===
RCS file: /projects/cvsroot/pgsql/src/pl/plpython/feature.expected,v
retrieving revision 1.9
diff -c -r1.9 feature.expected
*** src/pl/plpython/feature.expected30 Jun 2003 18:31:42 - 1.9
--- src/pl/plpython/feature.expected24 Mar 2005 04:08:59 -
***
*** 137,139
--- 137,157
(0 rows)
+ SELECT newline_lf();
+ newline_lf
+
+ 123
+ (1 row)
+
+ SELECT newline_cr();
+ newline_cr
+
+ 123
+ (1 row)
+
+ SELECT newline_crlf();
+ newline_crlf
+ --
+ 123
+ (1 row)
+
Index: src/pl/plpython/plpython.c
===
RCS file: /projects/cvsroot/pgsql/src/pl/plpython/plpython.c,v
retrieving revision 1.58
diff -c -r1.58 plpython.c
*** src/pl/plpython/plpython.c 17 Dec 2004 02:14:48 - 1.58
--- src/pl/plpython/plpython.c 24 Mar 2005 04:09:00 -
***
*** 1206,1215
while (*sp != '\0')
{
! if (*sp == '\n')
{
! *mp++ = *sp++;
*mp++ = '\t';
}
else
*mp++ = *sp++;
--- 1206,1219
while (*sp != '\0')
{
! if (*sp == '\r' *(sp + 1) == '\n')
! sp++;
!
! if (*sp == '\n' || *sp == '\r')
{
! *mp++ = '\n';
*mp++ = '\t';
+ sp++;
}
else
*mp++ = *sp++;
Index: src/pl/plpython/plpython_function.sql
===
RCS file: /projects/cvsroot/pgsql/src/pl/plpython/plpython_function.sql,v
retrieving revision 1.6
diff -c -r1.6 plpython_function.sql
*** src/pl/plpython/plpython_function.sql 30 Jun 2003 18:31:42 -
1.6
--- src/pl/plpython/plpython_function.sql 24 Mar 2005 04:09:00 -
***
*** 306,308
--- 306,324
open(args[0],w).write(args[1])
return Wrote to file: %s % args[0]
' LANGUAGE plpythonu;
+
+ --
+ -- Universal Newline Support
+ --
+
+ CREATE OR REPLACE FUNCTION newline_lf() RETURNS integer AS
+ 'x = 100\ny = 23\nreturn x + y\n'
+ LANGUAGE plpythonu;
+
+ CREATE OR REPLACE FUNCTION newline_cr() RETURNS integer AS
+ 'x = 100\ry = 23\rreturn x + y\r'
+ LANGUAGE plpythonu;
+
+ CREATE OR REPLACE FUNCTION newline_crlf() RETURNS integer AS
+ 'x = 100\r\ny = 23\r\nreturn x + y\r\n'
+ LANGUAGE plpythonu;
Index: src/pl/plpython/plpython_test.sql
===
RCS file: /projects/cvsroot/pgsql/src/pl/plpython/plpython_test.sql,v
retrieving revision 1.2
diff -c -r1.2 plpython_test.sql
*** src/pl/plpython/plpython_test.sql 12 May 2001 17:49:32 - 1.2
--- src/pl/plpython/plpython_test.sql 24 Mar 2005 04:09:00 -
***
*** 61,63
--- 61,70
-- error in trigger
--
+ --
+ -- Check Universal Newline Support
+ --
+
+ SELECT newline_lf();
+ SELECT newline_cr();
+ SELECT newline_crlf();
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
