Re: [HACKERS] using the same connection?
Quoting Mathieu Dube [EMAIL PROTECTED]: Hi y'all, Is it a bad idea for an app to keep just a couple of connections to a database, put semaphore/mutex on them and reuse them all through the program? Of course I would check if their PQstatus isnt at CONNECTION_BAD and reconnect if they were... I need some opinions on that practice... In the Java world it's called ConnectionPooling and is standard practice, especially with Servlets/JSP/EJB's. Peter -- Peter Mount [EMAIL PROTECTED] PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/ RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/
Re: [HACKERS] a contrib function to query current locale values
On Wed, 7 Feb 2001, Hannu Krosing wrote: Hi, I've written a small function that should go into contrib for 7.1 As locale issues are quite tricky, being able to find out what locale backend thinks it is in is a good thing ;) hmm, see you PG sources -- pg_locale.c file? I mean that is not good lavish the sources with same code. If this is really needful will better add your idea into this file and use PGLC_current() instead add to sources again new setlocale() call. The current backend (unfortunately) disable change locales on the fly -- this means your function will returns always same result :-) IMHO more nice will some function 'environment()' returns *all* backend environment values (locales, debug mode ... etc) or command "SHOW LOCALE" or something like this. Karel
[HACKERS] Re: 7.1beta4 RPMs.
On 29 Jan 2001 at 02:50 (-0500), Lamar Owen wrote: | Lamar Owen wrote: | ftp://ftp.postgresql.org/pub/dev/test-rpms is the place. | | One note: for whatever reason the date on the uploaded RPM's has the | wrong year -- but the timestamp on my local copy has the correct date. | In any case, ignore the datestamp on those RPM's -- there were _not_ | built a year ago on Sat, January 29, 2000. yeah, right ;) comment on the rpms: 1) could you modify the init script, specifically the initdb command, to use the assigned $PGDATA. I have an environment where the main database must be installed to a different location than /var/lib/pgsql(/data)?. the suggested line is below. su -l postgres -c "/usr/bin/initdb -D $PGDATA" /dev/null also, the original had a little typo: ' /dev/null' otherwise, my experience with the rpms has been pretty good :) Thanks for your effort. brent -- "We want to help, but we wouldn't want to deprive you of a valuable learning experience." http://openbsd.org/mail.html
[HACKERS] POSTGRESQL API ...
Hi out there, I am looking to use POSTGRESQL as a backend database. However I am writing the TCP/IP data exchange protocol/and server, and I want to link interface support to POSTGRESQL data files. Is there a set of files that I could compile with my application to access/update the POSTGRESQL data files? -- David C. Lane, Programmer Merced College -- Phone: (209) 384-6183 Colleague: R16/HR4 Os: AIX begin:vcard n:Lane;David tel;work:(209) 384-6183 x-mozilla-html:TRUE url:www.merced.cc.ca.us org:Merced College;Information Services adr:;;;Merced ;Ca;95348; version:2.1 email;internet:[EMAIL PROTECTED] title:Programmer/Analyst fn:David C. Lane end:vcard
[HACKERS] ODBC protocol changes in 7.1 ? And to pgaccess ?
I have a problem with 7.1 beta 4
Setup :
Debian 2.3(?) (unstable)
Kernel 2.18pre23 (the stock Debian kernel)
PostgreSQL 7.1beta4 as packaged for Debian by Oliver Elphick
unixODBC 2.0.3 compiled from unixODBC.org's sources against the installed and
working PG 7.1b4.
The problem is that an ODBC connection (from StarOffice or unixODBC's
Datamanager tool) is correctly opened, but no tables show up.
This problem seems limited : the ODBC driver has some function, as proved by
an attempt to use the RODBC package of the R statistical program :
ch1-odbcConnect("Essai1","","") -- username and password masked
sqlTables(ch1)
[1] -1 -- That means "error". However :
sqlQuery(ch1,"select * from tablea;") -- send a query absed on previous knowledge
keyaval -- Result is OK.
11 Prem's
22 Deuz
33 Troiz
Warning message:-- Not unusual when reading text fields with RODBC.
a column has been truncated in: sqlGetResults(channel, errors = errors, ...)
odbcClose(ch1)
[1] 1
So my question is : what has changed in the protocol ?
And, BTW : what has happened to pgaccess ? Views doesn't show up, while psql
sees them.
--
Emmanuel Charpentier
[HACKERS] unixODBC (again)
Hi,
Having seen that the driver I distribute doesn't work against 7.1 Beta
4, and not wanting to continue the split between the two versions,
I have tried to get the driver in the beta working with unixODBC, but
I have come against a couple of problems, one a show stopper.
First let me say that I want to stop the split between the version, If
I can just point people to your distribution, thats fine by me, but it
needs to work :-). I am not trying to get you to standardise on
unixODBC, just to provide the option.
Initially I had to link my system odbc.ini to a user odbc, because the
driver looks in the home account. This would be SO much better if there
was a build option to link with libodbcini.so, not saying it should be
the default, just that the option would be great.
After this, it still didn't find the entries, I fould the problem was
the code couldn't handle spaces in the ini file, so
[dsn]
Servername=fred
works, but
[dsn]
Servername = fred
doesn't. Not a major point, but again the ini lib would fix this.
Then having sorted this out, I get a core dump, that I have traced to
CC_lookup_pg_version, the code did
CC_lookup_pg_version(ConnectionClass *self)
{
HSTMT hstmt;
StatementClass *stmt;
RETCODE result;
char *szVersion = "0.0";
static char *func = "CC_lookup_pg_version";
Then later did a
sprintf( szVersion... );
This seems to be trying to write into, what the compiler is marking as
read only storage. A quick change to
CC_lookup_pg_version(ConnectionClass *self)
{
HSTMT hstmt;
StatementClass *stmt;
RETCODE result;
char szVersion[ 3 ];
static char *func = "CC_lookup_pg_version";
strcpy( szVersion, "0.0" );
Fixes the problem, and it connects. I will continue testing, with some
apps and see how it gets on
--
Nick Gorham
Easysoft Ltd
Re: [HACKERS] a contrib function to query current locale values
Karel Zak wrote:
On Wed, 7 Feb 2001, Hannu Krosing wrote:
Hi,
I've written a small function that should go into contrib for 7.1
As locale issues are quite tricky, being able to find out what locale
backend thinks it is in is a good thing ;)
hmm, see you PG sources -- pg_locale.c file?
I mean that is not good lavish the sources with same code. If this is
really needful will better add your idea into this file and use
PGLC_current() instead add to sources again new setlocale() call.
Yes, pg_locale.c is where I want them to end up, but it is probably
considered "a feature" and not "a bugfix" so it has to wait at least
until 7.2.
OTOH, piggipacking it upon PGLC_current() seems like an overkill as most
of the code is not aboult setlocale(CONST,NULL) but for interfacing to
postgres and 'LC_XXX' -- const LC_XXX conversions.
The current backend (unfortunately) disable change locales on the fly
I think that is a well-founded restriction, we don't allow changing int4
to char(4) on the fly either ;)
BTW, does anyone know if setlocale() is an expensive function ?
I.e. would it be a huge performance hog if called before each and every
compare of each and every VARCHAR() or TEXT field that has COLLATE defined.
I'd guess it is, but if if it is not, we could use system-native locale
support for STRING COLLATE.
-- this means your function will returns always same result :-)
So does "select version();" which I still use quite often.
My concern is about knowing that "same" result - currently my ways for
finding out about the locale included things like "select
upper('');" and sorting a small specially created table - not most
intuitive.
I needed to do it when I had to find out the simplest way to start
postgres with different locale than the system default - the init
scripts in the RPM's are several levels deep so I tried setting LC_ALL
and/or friends at several levels (init.d/postgres, pg_ctl,
~postgres/.bash_profile) and was quite unhappy by not being able to
know if it worked.
IMHO more nice will some function 'environment()' returns *all* backend
environment values (locales, debug mode ... etc) or command "SHOW LOCALE"
or something like this.
I'd prefer a separate function, as it seems most portable between
different front-ends (no front-end changes needed ;).
It could have a special name, like pg_getlocale() to avoid
name-space pollution. (maybe version()-pg_version() would also
be a good move).
---
Hannu
[HACKERS] Re: [SQL] PL/PGSQL function with parameters
Tom, Jan, Michael, While I have not looked closely, I seem to recall that plpgsql handles INTO by stripping that clause out of the statement before it's passed to the SQL engine. Evidently that's not happening in the EXECUTE case. Jan, do you agree this is a bug? Is it reasonable to try to repair it for 7.1? If we do not change the behavior of EXECUTE now, I fear it will be too late --- some people will come to depend on the existing behavior. If you think that's the best way. What we're really all wanting is a wy in PL/pgSQL to pass a parameter as an object name. Doing it *without* using EXECUTE would be even better than modifying EXECUTE to accomdate SELECT ... INTO variable. If we can write queries that address tables by OID, that would give us a quick workaround ... get the OID from pg_class, then pass it to the query as variables of type OID: SELECT column1_oid, column2_oid FROM table_oid WHERE column2_oid = variable1 ORDER BY column1_oid; OF course, having PL/pgSQL do this automatically would be even better, but I suspect would require a *lot* of extra programming by Jan. And all of this should be influenced by whatever you guys are planning to do about Stored Procedures. -Josh Berkus -- __AGLIO DATABASE SOLUTIONS___ Josh Berkus Complete information technology [EMAIL PROTECTED] and data management solutions (415) 565-7293 for law firms, small businesses fax 621-2533 and non-profit organizations. San Francisco
Re: [HACKERS] a contrib function to query current locale values
Hannu Krosing [EMAIL PROTECTED] writes: BTW, does anyone know if setlocale() is an expensive function ? The variant where you're just querying the current setting should not be too expensive. I'd expect the variant where you are changing the setting to be very expensive, however; most likely, it goes out and reads/parses the locale definition files. I.e. would it be a huge performance hog if called before each and every compare of each and every VARCHAR() or TEXT field that has COLLATE defined. I do not think we will be able to get away with that in standard implementations of the locale functions. We will need to roll our own implementation that caches and reuses pre-loaded locale information for multiple locales at once. Doesn't seem like an appetizing prospect, but I think there's no other way to support per-column locales... regards, tom lane
Re: [HACKERS] Re: [GENERAL] MySQL - Postgres dump converter
On Sun, 28 Jan 2001 07:57:43 + "Oliver Elphick" [EMAIL PROTECTED] wrote: Hannu Krosing wrote: If it's all your code, then you are free to license it under any licence you desire. ... What you probably can't do is to revoke the GPL license. You can't revoke it from existing copies "out there", but you can from any copies you release from now on, even of the same code.. Thanks. I'll release it under BSD - in few days. OK, his conversion tool has been release under a BSD license. Can someone review his and Thomas's and merge them? You can download it from: http://ziet.zhitomir.ua/~fonin/code Thanks. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[HACKERS] python build/Current CVS/UnixWare
In the current CVS, the PYTHON build sets LDSHARED to ld -G, not cc -G. It passes -Wl,-h,... to the ld command, and breaks. ALL shared library builds on UnixWare should use cc -G or CC -g as appropriate. I don't see right off where this is set. Peter E, can you fix? Thanks! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
[HACKERS] Re: python build/Current CVS/UnixWare
Larry Rosenman writes: In the current CVS, the PYTHON build sets LDSHARED to ld -G, not cc -G. It passes -Wl,-h,... to the ld command, and breaks. ALL shared library builds on UnixWare should use cc -G or CC -g as appropriate. I have arranged for the -Wl,-h to be left out in the Python build. The ld vs cc thing you have to take up with the Python folks. I'm not convinced their infrastructure works too well. For example, we might have to pull the same kludge as we do for the Perl interface build on some platforms. Eventually we might be able to write our own rules for this and not use the Python build infrastructure. Not now, though. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] unixODBC (again)
Nick Gorham writes: First let me say that I want to stop the split between the version, If I can just point people to your distribution, thats fine by me, but it needs to work :-). I am not trying to get you to standardise on unixODBC, just to provide the option. This is nice, but it contradicts your earlier patches, because it would create a circular dependency: You need PostgreSQL's ODBC to get unixODBC set up, but you need [--with-]unixODBC to get PostgreSQL prepared for unixODBC. That said if there are improvements in your version, why not send patches to improve our version, rather than providing patches to link our version against your version? That doesn't make sense to me. I'm not trying to annoy you, I'm just wondering. Initially I had to link my system odbc.ini to a user odbc, because the driver looks in the home account. This would be SO much better if there was a build option to link with libodbcini.so, not saying it should be the default, just that the option would be great. Why not have us include that libodbcini.so in our distribution? Certainly, no one would get upset if we had better config/ini file parsing. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] pgAccess fails to launch on HPUX
I thought I'd tried pgAccess back in the dim past with success, but as of current sources it fails on HPUX 10.20 and Tcl 8.3.2: $ pgaccess regression Error in startup script: couldn't load file "libpgtcl.sl": no such file or directory while executing "load libpgtcl[info sharedlibextension]" (procedure "main" line 3) invoked from within "main $argc $argv" (file "/home/postgres/testversion/share/pgaccess/main.tcl" line 249) $ The problem here is that Tcl does not do dynamic path searching, even if you give it the necessary environment-variable setting: $ SHLIB_PATH="/home/postgres/testversion/lib:." wish % load libpgtcl.sl /usr/lib/dld.sl: Can't open shared library: libpgtcl.sl /usr/lib/dld.sl: No such file or directory couldn't load file "libpgtcl.sl": no such file or directory % load /home/postgres/testversion/lib/libpgtcl.sl [ works fine ] And the reason for *that* is that Tcl doesn't pass the DYNAMIC_PATH flag to shl_load(). I find that sourceforge.net already has a couple of bug reports posted on this, so perhaps the Tcl guys will get their act together and add the flag in Tcl 8.4, but in the meantime I think we have very little choice except to specify the full path to the library in pgaccess' load command. Does anyone object if I modify pgaccess so that it always specifies the full path to the library? That seems like it'd be a good idea even on OSes without this quirk, because it'd ensure getting the matching version of libpgtcl and libpq even if your SHLIB_PATH/LD_LIBRARY_PATH points to some other version. regards, tom lane
[HACKERS] Re: [INTERFACES] pgAccess fails to launch on HPUX
On Wed, Feb 07, 2001 at 01:34:58PM -0500, Tom Lane wrote: I thought I'd tried pgAccess back in the dim past with success, but as of current sources it fails on HPUX 10.20 and Tcl 8.3.2: SNIP problem with dynamic load and Tcl And the reason for *that* is that Tcl doesn't pass the DYNAMIC_PATH flag to shl_load(). I find that sourceforge.net already has a couple of bug reports posted on this, so perhaps the Tcl guys will get their act together and add the flag in Tcl 8.4, but in the meantime I think we have very little choice except to specify the full path to the library in pgaccess' load command. Yep, the Tcl team changed dynamic loading in 8.2-8.3 This bit me on NT, first. Does anyone object if I modify pgaccess so that it always specifies the full path to the library? That seems like it'd be a good idea even on OSes without this quirk, because it'd ensure getting the matching version of libpgtcl and libpq even if your SHLIB_PATH/LD_LIBRARY_PATH points to some other version. Sounds like a good idea, to me. Getting the wrong library loaded leads to non-obvious error messages, as well. Ross
[HACKERS] RE: python build/Current CVS/UnixWare
I submitted a bug to their SourceForge Bug List. Thanks! LER -Original Message- From: Peter Eisentraut [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 07, 2001 12:34 PM To: Larry Rosenman Cc: PostgreSQL Hackers List Subject: Re: python build/Current CVS/UnixWare Larry Rosenman writes: In the current CVS, the PYTHON build sets LDSHARED to ld -G, not cc -G. It passes -Wl,-h,... to the ld command, and breaks. ALL shared library builds on UnixWare should use cc -G or CC -g as appropriate. I have arranged for the -Wl,-h to be left out in the Python build. The ld vs cc thing you have to take up with the Python folks. I'm not convinced their infrastructure works too well. For example, we might have to pull the same kludge as we do for the Perl interface build on some platforms. Eventually we might be able to write our own rules for this and not use the Python build infrastructure. Not now, though. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] pgAccess fails to launch on HPUX
Tom Lane writes: Does anyone object if I modify pgaccess so that it always specifies the full path to the library? If I had known that this was possible I would have done it myself already. ;-) This is a good idea in general because in a default installation pgaccess won't find libpgtcl on any system because it doesn't have the benefit of the -rpath/-R business. Please review/remove the note at the end of the pgaccess ref page if you fix this to your satisfaction. That seems like it'd be a good idea even on OSes without this quirk, because it'd ensure getting the matching version of libpgtcl and libpq even if your SHLIB_PATH/LD_LIBRARY_PATH points to some other version. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] Sluggish inserts/updates ?
I've got a system in which a row is being created by one process, a notify is sent, and another process finds and then deletes the row. This whole interchange seems to be taking about a second, which seems oddly slow. As far as I know, I have the fsync-on-anything turned off (*). I'm mainly wondering if I should index/not index the key of the table, and if I should blame the hardware or Postgres? The hard drive on the RD server is pretty slow, although the CPU is pretty dang fast. I could also blame the notification system but that shouldn't be a problem, right? * Is there a good way to find out if this option is on/off? -- Adam Haberlach|A cat spends her life conflicted between a [EMAIL PROTECTED] |deep, passionate, and profound desire for http://www.newsnipple.com |fish and an equally deep, passionate, and '88 EX500'00 ^ |profound desire to avoid getting wet.
Re: [HACKERS] pgAccess fails to launch on HPUX
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: Does anyone object if I modify pgaccess so that it always specifies the full path to the library? If I had known that this was possible I would have done it myself already. ;-) This is a good idea in general because in a default installation pgaccess won't find libpgtcl on any system because it doesn't have the benefit of the -rpath/-R business. Right, even with a cooperative Tcl+kernel, you need to set LD_LIBRARY_PATH to make pgaccess work. Perhaps this will fix that. AFAICT, specifying a full path in the Tcl 'load' command is legal on all systems. However, we still have to rely on the dynamic linker to do the right thing with the indirect dependency on libpq.so, so there may be systems that still need LD_LIBRARY_PATH to find libpq.so. Please review/remove the note at the end of the pgaccess ref page if you fix this to your satisfaction. Thanks for the pointer, I probably wouldn't have noticed that. But given the above consideration, I'm not sure I want to remove the note yet. BTW, I'm also thinking about fixing pgaccess so that it honors the --with-pgport configure setting and PGPORT environment variable, rather than having the default port number 5432 hard-wired in. regards, tom lane
Re: [HACKERS] Include files for SPI are not installed
Tom Lane wrote: client-devel and server-devel are the right division IMHO. SPI is a subset of server-side development, but not all server-side code needs SPI. Consider user-written functions and datatypes. These guys do not Ok, I can do that. Obsoletes:devel here we come! My thought was that we'd remove spi.h from the minimal install, along with anything else that's not useful for client-side programming. Thus the standard install footprint would get smaller. I haven't looked to see exactly what the list of client-side headers should be, but if people like this idea I will do the legwork to make the list. Count me as liking it. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] a contrib function to query current locale values
Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
BTW, does anyone know if setlocale() is an expensive function ?
The variant where you're just querying the current setting should not be
too expensive. I'd expect the variant where you are changing the
setting to be very expensive, however; most likely, it goes out and
reads/parses the locale definition files.
I.e. would it be a huge performance hog if called before each and every
compare of each and every VARCHAR() or TEXT field that has COLLATE defined.
I do not think we will be able to get away with that in standard
implementations of the locale functions. We will need to roll our own
implementation that caches and reuses pre-loaded locale information for
multiple locales at once.
Doesn't seem like an appetizing prospect, but I think there's no other
way to support per-column locales...
regards, tom lane
There seems to be a library released by IBM that we could use, see at:
http://oss.software.ibm.com/developerworks/opensource/icu/project/
could someone review its license :
http://oss.software.ibm.com/developer/opensource/license10.html
for compatibility with postgres.
At cursory reading it seems to have the same flaws that GPL :
---88---8---8---8
When the Program is made available in source code form:
a) it must be made available under this Agreement; and
b) a copy of this Agreement must be included with each copy of
the Program.
---88---8---8---8
i.e. forcing its own license.
OTOH it
1) allows distribution in object-code form under other licenses
2) is in fact a library not a "Program" ;)
3) it claims commercial distribution to be ok.
---88---8---8---8
4. COMMERCIAL DISTRIBUTION
Commercial distributors of software may accept certain
responsibilities with
respect to end users, business partners and the like. While this
license is
intended to facilitate the commercial use of the Program, the
Contributor
who includes the Program in a commercial product offering should do so
in a
manner which does not create potential liability for other
Contributors.
Therefore, if a Contributor includes the Program in a commercial
product
offering, such Contributor ("Commercial Contributor") hereby agrees to
defend
and indemnify every other Contributor ("Indemnified Contributor")
against any
losses, damages and costs (collectively "Losses") arising from claims,
lawsuits
and other legal actions brought by a third party against the
Indemnified
Contributor to the extent caused by the acts or omissions of such
Commercial
Contributor in connection with its distribution of the Program in a
commercial
product offering. The obligations in this section do not apply to any
claims or
Losses relating to any actual or alleged intellectual property
infringement.
In order to qualify, an Indemnified Contributor must: a) promptly
notify the
Commercial Contributor in writing of such claim, and b) allow the
Commercial
Contributor to control, and cooperate with the Commercial Contributor
in, the
defense and any related settlement negotiations. The Indemnified
Contributor
may participate in any such claim at its own expense.
For example, a Contributor might include the Program in a commercial
product
offering, Product X. That Contributor is then a Commercial
Contributor. If
that Commercial Contributor then makes performance claims, or offers
warranties
related to Product X, those performance claims and warranties are such
Commercial Contributor's responsibility alone. Under this section, the
Commercial Contributor would have to defend claims against the other
Contributors related to those performance claims and warranties, and
if a
court requires any other Contributor to pay any damages as a result,
the
Commercial Contributor must pay those damages.
---88---8---8---8
Hannu
[HACKERS] Utility program to read parameters of the current database
I had a need to read such things as the backend locale and the catalog
version number from the current database, and couldn't find any existing
program to do that.
The attached utility produces this output:
linda:~$ pg_controldata
Log file id: 0
Log file segment: 5
Last modified:Wed Feb 7 19:35:47 2001
Database block size: 8192
Blocks per segment of large relation: 131072
Catalog version number: 200101061
LC_COLLATE: en_GB
LC_CTYPE: en_GB
Log archive directory:
/* pg_controldata
*
* reads the data from $PGDATA/global/pg_control
*
* copyright (c) Oliver Elphick [EMAIL PROTECTED], 2001;
* licence: BSD
*
*/
#include stdio.h
#include stdlib.h
#include unistd.h
#include time.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
typedef unsigned int uint32;
#include "config.h"
#include "access/xlogdefs.h"
/*
* #include "access/xlog.h"
* #include "c.h"
*/
/* The following definitions are extracted from access/xlog.h and its
* recursive includes. There is too much initialisation needed if
* they are included direct. Perhaps someone more knowledgeable can
* fix that.
*/
typedef struct crc64
{
uint32 crc1;
uint32 crc2;
} crc64;
#define LOCALE_NAME_BUFLEN 128
typedef enum DBState
{
DB_STARTUP = 0,
DB_SHUTDOWNED,
DB_SHUTDOWNING,
DB_IN_RECOVERY,
DB_IN_PRODUCTION
} DBState;
typedef struct ControlFileData
{
crc64crc;
uint32 logId; /* current log file id */
uint32 logSeg;/* current log file segment (1-based) */
struct
XLogRecPtr checkPoint;/* last check point record ptr */
time_t time; /* time stamp of last modification */
DBState state; /* see enum above */
/*
* this data is used to make sure that configuration of this DB is
* compatible with the backend executable
*/
uint32 blcksz;/* block size for this DB */
uint32 relseg_size; /* blocks per segment of large relation */
uint32 catalog_version_no; /* internal version number */
/* active locales --- "C" if compiled without USE_LOCALE: */
char lc_collate[LOCALE_NAME_BUFLEN];
char lc_ctype[LOCALE_NAME_BUFLEN];
/*
* important directory locations
*/
char archdir[MAXPGPATH]; /* where to move offline log files */
} ControlFileData;
int main() {
ControlFileData ControlFile;
int fd;
char ControlFilePath[MAXPGPATH];
char *DataDir;
char tmdt[32];
DataDir = getenv("PGDATA");
if ( DataDir == NULL ) {
fprintf(stderr,"PGDATA is not defined\n");
exit(1);
}
snprintf(ControlFilePath, MAXPGPATH, "%s/global/pg_control", DataDir);
if ((fd = open(ControlFilePath, O_RDONLY)) == -1) {
perror("Failed to open $PGDATA/global/pg_control for reading");
exit(2);
}
read(fd, ControlFile, sizeof(ControlFileData));
strftime(tmdt, 32, "%c", localtime((ControlFile.time)));
printf("Log file id: %u\n"
"Log file segment: %u\n"
"Last modified:%s\n"
"Database block size: %u\n"
"Blocks per segment of large relation: %u\n"
"Catalog version number: %u\n"
"LC_COLLATE: %s\n"
"LC_CTYPE: %s\n"
"Log archive directory:%s\n",
ControlFile.logId,
ControlFile.logSeg,
tmdt,
ControlFile.blcksz,
ControlFile.relseg_size,
ControlFile.catalog_version_no,
ControlFile.lc_collate,
ControlFile.lc_ctype,
ControlFile.archdir);
return (0);
}
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
"But the LORD is in his holy temple; let all the earth
keep silence before him." Habakkuk 2:20
[HACKERS] Re: [INTERFACES] pgAccess fails to launch on HPUX
Constantin Teodorescu [EMAIL PROTECTED] writes: Yes. The full path to libpgtcl might be specified directly in pgaccess. I have committed pgaccess changes to do this. But libpq library need to be found automatically because it isn't in a "load" explicit command. At least on HPUX 10, this seems to work anyway, presumably because the correct search path is embedded into libpgtcl.sl. I imagine that not all platforms have 'rpath' info embedded into shlibs, so there may be other platforms where you still need to set LD_LIBRARY_PATH to find libpq.so. Thought: would it be out of line for pgaccess.sh to set LD_LIBRARY_PATH explicitly to cover this possibility? regards, tom lane
Re: [HACKERS] pg_ctl changes
Peter Eisentraut [EMAIL PROTECTED] writes: I've implemented the following changes in pg_ctl: Sounds good to me. * Add -l option to name log file. If the option is omitted, then the postmaster log goes to stdout, so you can use 'pg_ctl ... log' and still get pg_ctl's stderr on the terminal. Let's see if I've got this straight --- the postmaster's stdout and stderr go to the -l file (by default pg_ctl's stdout), while pg_ctl's own stderr is kept separate for failure notices? That seems like it will work ... in particular one could imagine doing pg_ctl start | log_splitter_process to handle log rotation stuff. regards, tom lane
Re: [HACKERS] pg_ctl changes
Peter Eisentraut wrote: I've implemented the following changes in pg_ctl: [snip] This should make pg_ctl a lot more suitable for startup scripts and overall. If this is okay then I'll also try to merge the contrib/linux and contrib/init.d scripts and reflect these changes there. Sounds good to me. It appears that you haven't checked in your changes to CVS as of a few minutes ago, but I like the looks of what you've posted. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
[HACKERS] pg_dump: oldie but goldie
Philip, the last element of the chain has caused a big problem for me changing from 7.0.2 to 7.1beta4: dumping the database out and putting back. As you might not know, at my place getting the data from the database is not a simple pg_dump, but the data come through complex filter programs (awk scripts and others). And loading the data back is also contains several scripts transforming the modified dump. So I am in a terrible need to have the same output in 7.1beta4 as in 7.0.2. I used pg_dump with -acnD and -acnd switches in 7.0.2. The old binary of pg_dump could not be used due to the changed database internals... :-( Is there any (maybe undocumented) switches satisfying my needs? TIA, Zoltan -- Kov\'acs, Zolt\'an [EMAIL PROTECTED] http://www.math.u-szeged.hu/~kovzol ftp://pc10.radnoti-szeged.sulinet.hu/home/kovacsz
Re: [HACKERS] unixODBC (again)
Nick Gorham wrote:
Then having sorted this out, I get a core dump, that I have traced to
CC_lookup_pg_version, the code did
CC_lookup_pg_version(ConnectionClass *self)
{
HSTMT hstmt;
StatementClass *stmt;
RETCODE result;
char *szVersion = "0.0";
static char *func = "CC_lookup_pg_version";
Then later did a
sprintf( szVersion... );
This seems to be trying to write into, what the compiler is marking as
read only storage. A quick change to
You are right, it seems a misuse of char *.
CC_lookup_pg_version(ConnectionClass *self)
{
HSTMT hstmt;
StatementClass *stmt;
RETCODE result;
char szVersion[ 3 ];
static char *func = "CC_lookup_pg_version";
strcpy( szVersion, "0.0" );
szVersion[3] seems too short.
I would increase the length and commit it soon.
Regards,
Hiroshi Inoue
Re: [HACKERS] preproc.y error
Vince Vielhaber [EMAIL PROTECTED] writes: In today's (2/7/2k1) snapshot from hub, I'm getting this: gcc -pipe -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -I./../include -DMAJOR_VERSION=2 -DMINOR_VERSION=8 -DPATCHLEVEL=0 -DINCLUDE_PATH=\"/usr/local/pgsql/include\" -c -o preproc.o preproc.c preproc.y:3957: syntax error at null character Works fine here, and there's nothing visibly wrong with line 3957 and neighbors in my copy. Try removing preproc.c and letting the system rebuild it. regards, tom lane
Re: [HACKERS] preproc.y error
On Wed, 7 Feb 2001, Tom Lane wrote: Vince Vielhaber [EMAIL PROTECTED] writes: In today's (2/7/2k1) snapshot from hub, I'm getting this: gcc -pipe -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -I./../include -DMAJOR_VERSION=2 -DMINOR_VERSION=8 -DPATCHLEVEL=0 -DINCLUDE_PATH=\"/usr/local/pgsql/include\" -c -o preproc.o preproc.c preproc.y:3957: syntax error at null character Works fine here, and there's nothing visibly wrong with line 3957 and neighbors in my copy. Try removing preproc.c and letting the system rebuild it. Now I get: byacc -d preproc.y byacc: f - maximum table size exceeded gmake[4]: *** [preproc.c] Error 2 However it failed building a kernel, I may have some bad ram. I'm supposed to have 256M coming any day - actually I thought it'd be here by now. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com ==
Re: [HACKERS] preproc.y error
Vince Vielhaber [EMAIL PROTECTED] writes: Now I get: byacc -d preproc.y byacc: f - maximum table size exceeded gmake[4]: *** [preproc.c] Error 2 Better install bison if you want to work with CVS sources ... the lack of bison probably explains why it's failing for you on this system when it's OK on other FreeBSD boxes. I wonder if we ought not accept byacc as a suitable yacc in configure? Peter, what do you think? regards, tom lane
Re: [HACKERS] preproc.y error
BTW, I pulled down the current snapshot, and there doesn't seem to be anything wrong with preproc.c in it. So the lack of bison on your machine wasn't the issue anyway; it should've compiled the preproc.c from the snapshot without complaint. It does sound like there may be some outright flakiness in your new machine :-( regards, tom lane
Re: [HACKERS] preproc.y error
* Tom Lane [EMAIL PROTECTED] [010207 17:24] wrote: Vince Vielhaber [EMAIL PROTECTED] writes: Now I get: byacc -d preproc.y byacc: f - maximum table size exceeded gmake[4]: *** [preproc.c] Error 2 Better install bison if you want to work with CVS sources ... the lack of bison probably explains why it's failing for you on this system when it's OK on other FreeBSD boxes. I wonder if we ought not accept byacc as a suitable yacc in configure? Peter, what do you think? I think I reported this broken a couple of months ago, but it was too late to add the check to configure for 7.0. byacc doesn't work, you need bison (or maybe some special flags to byacc). -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."
Re: [HACKERS] preproc.y error
On Wed, 7 Feb 2001, Tom Lane wrote: BTW, I pulled down the current snapshot, and there doesn't seem to be anything wrong with preproc.c in it. So the lack of bison on your machine wasn't the issue anyway; it should've compiled the preproc.c from the snapshot without complaint. It does sound like there may be some outright flakiness in your new machine :-( Hopefully the new ram will show tomorrow. I need to build a kernel and know enough to not bother with one built on bad ram. Thanks for the double check. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com ==
Re: [HACKERS] Re: [PATCHES] A Sparc/Linux patch (for 7.1), and aLinux rc.d/init.d script....
On Tue, 6 Feb 2001, Bruce Momjian wrote:
DAEMON=/home/postgres/bin/pg_ctl
Ooops That is my mistake... Should have been
/usr/local/pgsql/bin/pg_ctl. I have /usr/local/pgsql/ symlinked to /home
(where there is more, faster disk space). I can submit a patch, or can
some one just fix it?
Change made.
Actually I found a few more places where I used /home/postgres
instead of /usr/local/pgsql. To make things clear (and for reasons
below) I have attached a new version of the file.
su - postgres sh -c "$DAEMON stop /dev/null"
Hmm... What is wrong here, besides the ''? The '' can be
replaced with '21 ' if that is more standard.
Change made.
Turns out that it has to be ' {dest} 21' for it to work, at
least with bash. So, to reduce confusion on fixes to this file, as I
stated above, a new version is attached. It is tested to work and I don't
see any thing more that is non-standard. Though if you still see problems,
feel free to point them out. :) Thanks and TTYL.
---
| "For to me to live is Christ, and to die is gain."|
|--- Philippians 1:21 (KJV) |
---
| Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
---
#! /bin/sh
#
# PostgreSQLStart, stop, and get status on the PostgreSQL RDMBS.
# This script is Linux distribution independent
# (or at least should be :).
#
# By Ryan Kirkpatrick [EMAIL PROTECTED].
#
# If you find any problems with this script, or have suggestions
# please send them to me.
# Arguements for pg_ctl and then for the postmaster. Change as needed.
ARGS="-w -D /usr/local/pgsql/data"
PM_ARGS="-i -F"
# Changes should not be needed beyond this point.
# The path that is to be used for the script.
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# What to use to start up the postmster, and a few names.
DAEMON=/usr/local/pgsql/bin/pg_ctl
NAME=postmaster
FILE=postgresql
DESC="PostgreSQL RDBMS"
# Who to run pg_ctl as, should be postgres.
USER="postgres:postgres"
# Where to keep a log file.
LOG="/usr/local/pgsql/server.log"
# Only start if we can find pg_ctl.
test -f $DAEMON || exit 0
set -e
# Parse command line parameters.
case "$1" in
start)
# Start the postmaster using pg_ctl and given options.
echo -n "Starting $DESC: "
su - postgres sh -c "$DAEMON start $ARGS -o \"$PM_ARGS\" $LOG 21"
echo "$NAME."
;;
stop)
# Stop the postmaster using pg_ctl.
echo -n "Stopping $DESC: "
su - postgres sh -c "$DAEMON stop /dev/null 21"
echo "$NAME."
;;
restart)
# Restart the postmaster by calling ourselves.
/etc/init.d/$FILE stop
sleep 5
/etc/init.d/$FILE start
;;
status)
# Print the status of the postmaster.
su - postgres $DAEMON status
;;
*)
# Print help.
N=/etc/init.d/$FILE
echo "Usage: $N {start|stop|restart|status}" 2
exit 1
;;
esac
exit 0
Re: [HACKERS] Re: [PATCHES] A Sparc/Linux patch (for 7.1), and a Linuxrc.d/init.d script....
Updated.
On Tue, 6 Feb 2001, Bruce Momjian wrote:
DAEMON=/home/postgres/bin/pg_ctl
Ooops That is my mistake... Should have been
/usr/local/pgsql/bin/pg_ctl. I have /usr/local/pgsql/ symlinked to /home
(where there is more, faster disk space). I can submit a patch, or can
some one just fix it?
Change made.
Actually I found a few more places where I used /home/postgres
instead of /usr/local/pgsql. To make things clear (and for reasons
below) I have attached a new version of the file.
su - postgres sh -c "$DAEMON stop /dev/null"
Hmm... What is wrong here, besides the ''? The '' can be
replaced with '21 ' if that is more standard.
Change made.
Turns out that it has to be ' {dest} 21' for it to work, at
least with bash. So, to reduce confusion on fixes to this file, as I
stated above, a new version is attached. It is tested to work and I don't
see any thing more that is non-standard. Though if you still see problems,
feel free to point them out. :) Thanks and TTYL.
---
| "For to me to live is Christ, and to die is gain."|
|--- Philippians 1:21 (KJV) |
---
| Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
---
Content-Description:
[ Attachment, skipping... ]
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] PL/pgsql EXECUTE 'SELECT INTO ...'
On Wed, Feb 07, 2001 at 10:15:02PM -0500, Tom Lane wrote: I have looked a little bit at what it'd take to make SELECT INTO inside an EXECUTE work the same as it does in plain plpgsql ... If we do nothing now, and then implement this feature in 7.2, we will have a backwards compatibility problem: EXECUTE 'SELECT INTO ...' will completely change in meaning. I am inclined to keep our options open by forbidding EXECUTE 'SELECT INTO ...' for now. ... if [not] I think we'll regret it later. I agree, disable it. But put a backpatch into contrib along with a reference to this last e-mail. Anybody who cares enough can apply the patch, and will be prepared for the incompatibility. Nathan Myers [EMAIL PROTECTED]
Re: [HACKERS] Re: [PATCHES] A Sparc/Linux patch (for 7.1), and a Linuxrc.d/init.d script....
Applied. Thanks.
On Tue, 6 Feb 2001, Bruce Momjian wrote:
DAEMON=/home/postgres/bin/pg_ctl
Ooops That is my mistake... Should have been
/usr/local/pgsql/bin/pg_ctl. I have /usr/local/pgsql/ symlinked to /home
(where there is more, faster disk space). I can submit a patch, or can
some one just fix it?
Change made.
Actually I found a few more places where I used /home/postgres
instead of /usr/local/pgsql. To make things clear (and for reasons
below) I have attached a new version of the file.
su - postgres sh -c "$DAEMON stop /dev/null"
Hmm... What is wrong here, besides the ''? The '' can be
replaced with '21 ' if that is more standard.
Change made.
Turns out that it has to be ' {dest} 21' for it to work, at
least with bash. So, to reduce confusion on fixes to this file, as I
stated above, a new version is attached. It is tested to work and I don't
see any thing more that is non-standard. Though if you still see problems,
feel free to point them out. :) Thanks and TTYL.
---
| "For to me to live is Christ, and to die is gain."|
|--- Philippians 1:21 (KJV) |
---
| Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
---
Content-Description:
[ Attachment, skipping... ]
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
