[HACKERS] Re: [ODBC] ODBC 6.4 protocol
Dave Page wrote: -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED]] I have backed out the changes to ODBC that removed compatibility with 6.4 servers, so the 7.1 ODBC code still supports the older servers. I have changed the dialog box from "6.4+" to "7.X,6.4+" to make it less confusing for users. Is that ODBC protocol dialog box needed? Can the client auto-detect the server version? I would assume not because the driver needs to make the connection and execute SELECT version() to figure out the server version (which is what happens with the current driver during the ODBC connection initialisation), version() first appeared in 6.4. Regards, Hiroshi Inoue
[HACKERS] AW: Recovery of PGSQL after system crash failing!!!
It removes the need to disable fsync to get best performance! -F performance is still better, only the difference is not so big as before. Since there is a fundamental recovery problem if the WAL file disappears, then perhaps we should have a workaround which can ignore the requirement for that file on startup? Or maybe we do already? Vadim?? This was discussed, but iirc not yet implemented. Also, could the "-F" option be disabled now that WAL is enabled? Or is there still some reason to encourage/allow folks to use it? I use it, since I restore after a system crash (which never happens). I think all that is probably missing in -F mode is probably 2-3 fsyncs during checkpoint. One for the xlog, and one for pg_control (maybe also pg_log). All other fsyncs are only to not buffer transactions. Andreas
[HACKERS] Re: Recovery of PGSQL after system crash failing!!!
It removes the need to disable fsync to get best performance! -F performance is still better, only the difference is not so big as before. Well, when "checkpoint seek in logs" will be implemented difference will be the same - lost consistency. Since there is a fundamental recovery problem if the WAL file disappears, then perhaps we should have a workaround which can ignore the requirement for that file on startup? Or maybe we do already? Vadim?? This was discussed, but iirc not yet implemented. Yes yes. Also, could the "-F" option be disabled now that WAL is enabled? Or is there still some reason to encourage/allow folks to use it? I've used it when testing btree runtime recovery to increase concurrence. I use it, since I restore after a system crash (which never happens). I think all that is probably missing in -F mode is probably 2-3 fsyncs during checkpoint. One for the xlog, and one for pg_control (maybe also pg_log). All other fsyncs are only to not buffer transactions. Probably we could just force fsync during checkpoint, for the moment. Thanks to all for help! Vadim
Re: [HACKERS] locale support
Tatsuo, what is LC_ALL (or the other locale envvars) set to when you run the program? The man page for setlocale() on my machine documents that the main() starts in C or POSIX locale mode by default. The call to setlocale(LC_ALL, "") reads the envvars and sets the locale accordingly. Maybe RedHat's 6.2J isn't setting up the locale properly to begin with? See what /etc/sysconfig/i18n contains -- if it is empty or doesn't exist, then locale is simply not set up. But you specfically mention the particular locale It's "ja_JP.eucJP". Definitely that locale exists, so I guess the contents is broken... Ok, what combinations _do_ work? We _know_ C or POSIX works -- but which ones don't work, on RH 6.1? While I want to make sure that a broken locale data set isn't used, I also want to make sure that a good locale set isn't thrown out, either. Forcing to LC_COLLATE=C is overkill, IMHO. And building without locale support doesn't work, I guess most single byte locales work. However I seriously doubt that locales for multibyte language would work. either, because, at least on RH 6.1, strncmp() is buggered to use the locale's collation. Really? I see PostgreSQL installations without the locale support work just fine on RH 6.1J. The real solution is for the vendors to fix their broken locales. Of course. -- Tatsuo Ishii
[HACKERS] RE: [ODBC] ODBC 6.4 protocol
-Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED]] Sent: 14 February 2001 06:20 To: PostgreSQL-development Cc: PostgreSQL odbc list Subject: [ODBC] ODBC 6.4 protocol I have backed out the changes to ODBC that removed compatibility with 6.4 servers, so the 7.1 ODBC code still supports the older servers. I have changed the dialog box from "6.4+" to "7.X,6.4+" to make it less confusing for users. Is that ODBC protocol dialog box needed? Can the client auto-detect the server version? I would assume not because the driver needs to make the connection and execute SELECT version() to figure out the server version (which is what happens with the current driver during the ODBC connection initialisation), unless there is a way to figure it out from the server's response when the tcp/ip connection is initiated. I'm not familiar with the protocol used though so I can't comment on that... Regards, Dave.
[HACKERS] Open 7.1 items
As you can see from the current open items list, there isn't much left to do for the 7.1 release. I am going to suggest we remove the LAZY VACUUM option at this point. I know Tom Lane posted an item about the join visibility issue, so hopefully this can be resolved soon. Not sure what to do about the "Stuck spinlocks" but we may have to leave that for 7.2 or see what problem reports we get from the current code. The documentation list is pretty much done. It would be nice to have some more items completed, but I haven't see any comments about them. So, where are we in the release cycle? Are we ready to start looking at dates to issue release candidates for testing? Thomas Lockhart needs the docs frozen for a while so he can package them. --- P O S T G R E S Q L 7 . 1 O P E NI T E M S Current at ftp://candle.pha.pa.us/pub/postgresql/open_items. Source Code Changes --- LAZY VACUUM (Vadim) visibility of joined columns in JOIN clauses Stuck btree spinlocks Documentation Changes - JDBC improvements (Peter, Travis Bauer, Christopher Cain, William Webber, Gunnar) ODBC cleanups/improvements (Nick Gorham, Stephan Szabo, Zoltan Kovacs, Michael Fork) New PL/pgSQL GET DIAGNOSTICS statement for SPI value access (Jan) Improve PL/PgSQL documentation (?) Store tables as files named by OID (Vadim) New /contrib/rserv replication toolkit (Vadim) New /contrib/oid2name to map numeric files to table names New pg_class.relkind value for views (Mark Hollomon) -- 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] Open 7.1 items
Bruce Momjian writes: New PL/pgSQL GET DIAGNOSTICS statement for SPI value access (Jan) If someone can show me an example of how it operates I can write up something. Improve PL/PgSQL documentation (?) I agree with the "(?)"... Certainly a bit late to start an "improvement" project. Store tables as files named by OID (Vadim) This has never been documented to the contrary AFAIK. There's an empty "Storage" chapter, which would be a good place to put this --- eventually. New /contrib/rserv replication toolkit (Vadim) New /contrib/oid2name to map numeric files to table names These both have their appropriate READMEs. New pg_class.relkind value for views (Mark Hollomon) Documented. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Re: Recovery of PGSQL after system crash failing!!!
Tom Lane writes: Thomas Lockhart [EMAIL PROTECTED] writes: Also, could the "-F" option be disabled now that WAL is enabled? Or is there still some reason to encourage/allow folks to use it? I was the one who put it back in after Vadim turned it off ;-) ... and I'll object to any attempt to remove the option. The description should be updated though: http://www.postgresql.org/devel-corner/docs/postgres/runtime-config.htm#RUNTIME-CONFIG-GENERAL I guess a lot of people have heard the rumour "PG 7.1 offers no-fsync performance with fsync turned on" and extrapolated "Imagine what it can do if I turn off fsync anyway." -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] possible to create CVS branch for proposed patch?
Jason Tishler and I are planning to create a patch to allow PostgreSQL to run directly as an NT service. I've submitted a similar patch which may well be incorporated into the next release of Cygipc, and we've got a plan for doing the same for PostgreSQL: see http://ontosys.com/phiki/PostgresqlNtServiceDesign I've vetted that plan past this group and have incorporated feedback. Getting to my question: Is it possible to create a CVS branch of the HEAD (tip) of the PostgreSQL CVS for us to use in this work? Having such a branch would allow Jason and I to coordinate our work easily, and it also gives the pgsql-hackers community an easy way to view (and review) our work. Once/if the work is stable and approved, we/someone could then use CVS tools to merge that branch back onto the main line and cease any further work on that branch. -- Fred Yankowski [EMAIL PROTECTED] tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
Re: [HACKERS] Re: Recovery of PGSQL after system crash failing!!!
Tom Lane writes: Thomas Lockhart [EMAIL PROTECTED] writes: Also, could the "-F" option be disabled now that WAL is enabled? Or is there still some reason to encourage/allow folks to use it? I was the one who put it back in after Vadim turned it off ;-) ... and I'll object to any attempt to remove the option. The description should be updated though: http://www.postgresql.org/devel-corner/docs/postgres/runtime-config.htm#RUNTIME-CONFIG-GENERAL I guess a lot of people have heard the rumour "PG 7.1 offers no-fsync performance with fsync turned on" and extrapolated "Imagine what it can do if I turn off fsync anyway." That is a very subtle point, and one I can imagine many people incorrectly assuming. -- 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] Open 7.1 items
Bruce Momjian writes: New PL/pgSQL GET DIAGNOSTICS statement for SPI value access (Jan) If someone can show me an example of how it operates I can write up something. I found: Quoting a recent message by Jan Wieck [EMAIL PROTECTED]: :Do a : :GET DIAGNOSTICS SELECT PROCESSED INTO int4_variable; : :directly after an INSERT, UPDATE or DELETE statement and you'll know :how many rows have been hit. : :Also you can get the OID of an inserted row with : :GET DIAGNOSTICS SELECT RESULT INTO int4_variable; Looking at plpgsql/src/gram.y, it only supports PROCESSED (rows returned/affected) and RESULT (OID). The grammar indicates that only SELECT is allowed in GET DIAGNOSTICS SELECT. Jan says it works for INSERT/UPDATE/DELETE too, but I guess you still use GET DIAGNOSTICS SELECT. Improve PL/PgSQL documentation (?) I agree with the "(?)"... Certainly a bit late to start an "improvement" project. I heard someone was working on that and was not sure how far they were. As I remember, docs can pretty much be done anytime before doc freeze. Probably will not happen in 7.1. Item removed. Store tables as files named by OID (Vadim) This has never been documented to the contrary AFAIK. There's an empty "Storage" chapter, which would be a good place to put this --- eventually. OK, Removed. New /contrib/rserv replication toolkit (Vadim) New /contrib/oid2name to map numeric files to table names These both have their appropriate READMEs. Yes, I kept rserv in there in case we wanted to more prominently mention it in the HISTORY file and give an overview. Guess not. Seems like a pretty cool thing to keep hidden in /contrib. The /rserv README doesn't adequately describe its usefulness. All removed. New pg_class.relkind value for views (Mark Hollomon) Documented. Removed. -- 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] possible to create CVS branch for proposed patch?
Fred Yankowski [EMAIL PROTECTED] writes: Getting to my question: Is it possible to create a CVS branch of the HEAD (tip) of the PostgreSQL CVS for us to use in this work? It seems unlikely that this work is large enough to justify a branch. Why don't you just work together and submit a patch when you are done? We have talked about using branches for projects of the scale of the planned querytree redesign, which would (a) hit most of the backend, and (b) break everything until it's done, so other developers couldn't get anything done meanwhile if it's done on the tip. An NT-service wrapper should not have either of those properties, seems to me. regards, tom lane
Re: [HACKERS] possible to create CVS branch for proposed patch?
Fred Yankowski writes: Jason Tishler and I are planning to create a patch to allow PostgreSQL to run directly as an NT service. I've submitted a similar patch which may well be incorporated into the next release of Cygipc, and we've got a plan for doing the same for PostgreSQL: see http://ontosys.com/phiki/PostgresqlNtServiceDesign I've vetted that plan past this group and have incorporated feedback. Seems like something that should be done in a separate wrapper program. Littering the backend with vast sections of platform-specific code that provides optional functional is probably not going to fly, if I can assess this group correctly. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] possible to create CVS branch for proposed patch?
On Wed, Feb 14, 2001 at 07:43:25PM +0100, Peter Eisentraut wrote: Seems like something that should be done in a separate wrapper program. Littering the backend with vast sections of platform-specific code that provides optional functional is probably not going to fly, if I can assess this group correctly. Our plan puts most of the work in a new NT/Cygwin-only version of backend/main.c. If we can use the existing signal() scheme to shut down PG, then we might not have to touch _anything_ else. What do you see in our plan that implies "vast sections of platform-specific code" "littering the backend"? If such changes are necessary, I want to know before we embark on this work. As far as this being "optional functional[ity]", I contend that PostgreSQL has no place as a ready-for-business tool on NT without this (or similar) work so that PG runs cleanly as a service, starting up and shutting down properly. -- Fred Yankowski [EMAIL PROTECTED] tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
Re: [HACKERS] possible to create CVS branch for proposed patch?
On Wed, Feb 14, 2001 at 07:43:25PM +0100, Peter Eisentraut wrote: Seems like something that should be done in a separate wrapper program. Littering the backend with vast sections of platform-specific code that provides optional functional is probably not going to fly, if I can assess this group correctly. Our plan puts most of the work in a new NT/Cygwin-only version of backend/main.c. If we can use the existing signal() scheme to shut down PG, then we might not have to touch _anything_ else. What do you see in our plan that implies "vast sections of platform-specific code" "littering the backend"? If such changes are necessary, I want to know before we embark on this work. As far as this being "optional functional[ity]", I contend that PostgreSQL has no place as a ready-for-business tool on NT without this (or similar) work so that PG runs cleanly as a service, starting up and shutting down properly. Agreed. We just want to minimize the affect on other areas of the code. We have been pretty good at keeping platform-specific stuff isolated. -- 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] Re: Open 7.1 items
...join visibility issue... I'm not sure if the "table shape for natural joins issue" has been formalized, but afaik it isn't covered in the scoping patch. Tom? - Thomas
Re: [HACKERS] Open 7.1 items
Bruce Momjian writes: Bruce Momjian writes: New PL/pgSQL GET DIAGNOSTICS statement for SPI value access (Jan) If someone can show me an example of how it operates I can write up something. I found: Quoting a recent message by Jan Wieck [EMAIL PROTECTED]: :Do a : :GET DIAGNOSTICS SELECT PROCESSED INTO int4_variable; : :directly after an INSERT, UPDATE or DELETE statement and you'll know :how many rows have been hit. : :Also you can get the OID of an inserted row with : :GET DIAGNOSTICS SELECT RESULT INTO int4_variable; Looking at plpgsql/src/gram.y, it only supports PROCESSED (rows returned/affected) and RESULT (OID). The grammar indicates that only SELECT is allowed in GET DIAGNOSTICS SELECT. Jan says it works for INSERT/UPDATE/DELETE too, but I guess you still use GET DIAGNOSTICS SELECT. May I suggest that this is the wrong syntax? It should be GET DIAGNOSTICS variable = ROW_COUNT; See SQL99 part 2, clause 19.1. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] Re: Open 7.1 items
Thomas Lockhart [EMAIL PROTECTED] writes: ...join visibility issue... I'm not sure if the "table shape for natural joins issue" has been formalized, but afaik it isn't covered in the scoping patch. Tom? Far as I know, we were OK on that before. test=# create table a(f1 int, f2 int); CREATE test=# create table b(f1 int, f3 int); CREATE test=# select * from a natural join b; f1 | f2 | f3 ++ (0 rows) test=# select * from a join b using(f1); f1 | f2 | f3 ++ (0 rows) test=# select * from a join b on (a.f1=b.f1); f1 | f2 | f1 | f3 +++ (0 rows) This is per spec, no? regards, tom lane
Re: [HACKERS] Open 7.1 items
Bruce Momjian wrote: P O S T G R E S Q L 7 . 1 O P E NI T E M S Current at ftp://candle.pha.pa.us/pub/postgresql/open_items. Any possibility of putting my getlocale into contrib ? I agree that it should in fact be in the pg_locale.c but that would be a feature and we don't add new features this late. OTOH it is helpful if users (specially those that use rpm's or other packaged binaries) have an easy way to find out what locale they happen to run in (as it often it just happens ;) -- Hannu
[HACKERS] Shouldn't non-MULTIBYTE backend refuse to start in MB database?
We now have defenses against running a non-LOCALE-enabled backend in a database that was created in non-C locale. Shouldn't we likewise prevent a non-MULTIBYTE-enabled backend from running in a database with a multibyte encoding that's not SQL_ASCII? Or am I missing a reason why that is safe? I propose the following addition to ReverifyMyDatabase in postinit.c: #ifdef MULTIBYTE SetDatabaseEncoding(dbform-encoding); + #else + if (dbform-encoding != SQL_ASCII) + elog(FATAL, "some suitable error message"); #endif Comments? regards, tom lane
Re: [HACKERS] Open 7.1 items
Bruce Momjian wrote: P O S T G R E S Q L 7 . 1 O P E NI T E M S Current at ftp://candle.pha.pa.us/pub/postgresql/open_items. Any possibility of putting my getlocale into contrib ? I agree that it should in fact be in the pg_locale.c but that would be a feature and we don't add new features this late. OTOH it is helpful if users (specially those that use rpm's or other packaged binaries) have an easy way to find out what locale they happen to run in (as it often it just happens ;) Actually, I have something from Oliver Elphick called pg_controldata: $ 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: This looks quite valuable. Do people want this in /contrib? How does this compare to your utility? -- 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] Open 7.1 items
Bruce Momjian wrote: Bruce Momjian wrote: P O S T G R E S Q L 7 . 1 O P E NI T E M S Current at ftp://candle.pha.pa.us/pub/postgresql/open_items. Any possibility of putting my getlocale into contrib ? I agree that it should in fact be in the pg_locale.c but that would be a feature and we don't add new features this late. OTOH it is helpful if users (specially those that use rpm's or other packaged binaries) have an easy way to find out what locale they happen to run in (as it often it just happens ;) Actually, I have something from Oliver Elphick called pg_controldata: Could you send it to me so that I can find out how he gets the LC_COLLATE and LC_CTYPE from backend (assuming it tells backend locale not cients) ? $ 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: This looks quite valuable. Do people want this in /contrib? How does this compare to your utility? Mine is an external C funtion, so it can easily be used from any client. And I intend to propose it into pg_locale.c ealy in 7.2 development. --- Hannu
Re: [HACKERS] Shouldn't non-MULTIBYTE backend refuse to start in MBdatabase?
Tom Lane writes: We now have defenses against running a non-LOCALE-enabled backend in a database that was created in non-C locale. Shouldn't we likewise prevent a non-MULTIBYTE-enabled backend from running in a database with a multibyte encoding that's not SQL_ASCII? Or am I missing a reason why that is safe? Not all multibyte encodings are actually "multi"-byte, e.g., LATIN2. In that case the main benefit is the on-the-fly recoding between the client and the server. If a non-MB server encounters that database it should still work. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Open 7.1 items
Actually, I have something from Oliver Elphick called pg_controldata:
Could you send it to me so that I can find out how he gets the
LC_COLLATE
and LC_CTYPE from backend (assuming it tells backend locale not cients)
?
$ 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:
This looks quite valuable. Do people want this in /contrib? How does
this compare to your utility?
Mine is an external C funtion, so it can easily be used from any client.
And I intend to propose it into pg_locale.c ealy in 7.2 development.
His is an external C program also. The C source is attached.
--
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
/* 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);
}
Re: [HACKERS] Shouldn't non-MULTIBYTE backend refuse to start in MB database?
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: We now have defenses against running a non-LOCALE-enabled backend in a database that was created in non-C locale. Shouldn't we likewise prevent a non-MULTIBYTE-enabled backend from running in a database with a multibyte encoding that's not SQL_ASCII? Or am I missing a reason why that is safe? Not all multibyte encodings are actually "multi"-byte, e.g., LATIN2. In that case the main benefit is the on-the-fly recoding between the client and the server. If a non-MB server encounters that database it should still work. Are these encodings all guaranteed to have the same collation order as SQL_ASCII? If not, we have the same index corruption issues as for LOCALE. regards, tom lane
[HACKERS] Re: Open 7.1 items
Far as I know, we were OK on that before. We weren't last time I tested (there was a thread on this a while ago), but... This is per spec, no? ... it sure is. Looks great! - Thomas
Re: [HACKERS] Shouldn't non-MULTIBYTE backend refuse to start inMB database?
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: We now have defenses against running a non-LOCALE-enabled backend in a database that was created in non-C locale. Shouldn't we likewise prevent a non-MULTIBYTE-enabled backend from running in a database with a multibyte encoding that's not SQL_ASCII? Or am I missing a reason why that is safe? Not all multibyte encodings are actually "multi"-byte, e.g., LATIN2. In that case the main benefit is the on-the-fly recoding between the client and the server. If a non-MB server encounters that database it should still work. Are these encodings all guaranteed to have the same collation order as SQL_ASCII? Yes no. If not, we have the same index corruption issues as for LOCALE. If the backend is configued with LOCALE enabled and the database is not configured with LOCALE, we will have a problem. But this will happen with/without MUTIBYTE anyway. Mutibyte support does nothing with LOCALE support. -- Tatsuo Ishii
Re: [HACKERS] Shouldn't non-MULTIBYTE backend refuse to start inMB database?
We now have defenses against running a non-LOCALE-enabled backend in a database that was created in non-C locale. Shouldn't we likewise prevent a non-MULTIBYTE-enabled backend from running in a database with a multibyte encoding that's not SQL_ASCII? Or am I missing a reason why that is safe? I propose the following addition to ReverifyMyDatabase in postinit.c: #ifdef MULTIBYTE SetDatabaseEncoding(dbform-encoding); + #else + if (dbform-encoding != SQL_ASCII) + elog(FATAL, "some suitable error message"); #endif Comments? Running a non-MULTIBYTE-enabled backend on a database with a multibyte encoding other than SQL_ASCII should be safe as long as: 1) read only access 2) the encodings are actually single byte encodings If mutibyte encoding database is updated by a non-MULTIBYTE-enabled backend, there might be a chance that data could corrupted since the backend does not handle mutibyte strings correctly. So I think you suggestion is a improvement. -- Tatsuo Ishii
Re: [HACKERS] Shouldn't non-MULTIBYTE backend refuse to start in MB database?
Tatsuo Ishii [EMAIL PROTECTED] writes: Are these encodings all guaranteed to have the same collation order as SQL_ASCII? Yes no. Um, I'm confused ... If not, we have the same index corruption issues as for LOCALE. If the backend is configued with LOCALE enabled and the database is not configured with LOCALE, we will have a problem. But this will happen with/without MUTIBYTE anyway. Mutibyte support does nothing with LOCALE support. Can a backend configured with MULTIBYTE and running in non-SQL_ASCII encoding ever sort strings in non-character-code ordering, even if it is in C locale? I should think that such behavior is highly likely for multibyte character sets. If it can, then we mustn't allow a non-MULTIBYTE backend to run in such a database, I think. regards, tom lane
[HACKERS] untrusted Pl/tcl?
Hi, I heard something like "untrusted PL/tcl". Does anybody know what the status of that is? -- Tatsuo Ishii
Re: [HACKERS] Open 7.1 items
As you can see from the current open items list, there isn't much left to do for the 7.1 release. I am going to suggest we remove the LAZY VACUUM option at this point. I know Tom Lane posted an item about the Well, leaving for vacation tomorrow I have to agree -:( LAZY patch will be available in a few days after 7.1 release. Vadim
Re: [HACKERS] RE: [ADMIN] SOS !!: Porstgress forgot all ! Help !
O, your system reached max transaction ID -:( That's two reports now of people who have managed to wrap around the XID counter. It doesn't seem that hard to do in a heavily used database. Does anyone want to take more seriously the stopgap solution I proposed for this problem (pghackers archives around 3-Nov-00)? I believe you shot it down that time, but I don't think that ignoring the problem for another release cycle is a better answer. Actually, I believed that you've done this temp solution till I've found that it's not true couple weeks ago. If you'll do this please don't forget about reusing ID of *committed* transactions and crashes - this should be handled somehow on recovery. Vadim
[HACKERS] Leaving for vacation
from Feb 15 till Mar 6... I'll not be able to read mail lists, so in the event of needs please use [EMAIL PROTECTED] address. Regards! Vadim
Re: [HACKERS] Open 7.1 items
[ Charset ISO-8859-1 unsupported, converting... ] As you can see from the current open items list, there isn't much left to do for the 7.1 release. I am going to suggest we remove the LAZY VACUUM option at this point. I know Tom Lane posted an item about the Well, leaving for vacation tomorrow I have to agree -:( LAZY patch will be available in a few days after 7.1 release. Seems we should keep it as an option outside the tree for a while. Remember, pgindent will be done before final. Is that OK? -- 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
