Re: [HACKERS] Solaris getopt_long and PostgreSQL
Dne 17.03.09 19:48, Chuck McDevitt napsal(a): Any obviously, we don't just use ours for platforms with no or broken getopt_long, since we are talking Solaris (which has a bug in getopt, but getopt_long works fine) Just for clarification: It is not bug in Solaris. It is Solaris' getopt extension for long arg processing from days when getopt_long did not exist (hmm it seems that it is still not in POSIX :( ). By my opinion PostgreSQL does not work correctly here, because it uses construction which is marked as a implementation depended in POSIX standard. See: http://www.opengroup.org/onlinepubs/009695399/functions/getopt.html http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap12.html#tag_12_02 Zdenek - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] log : bad file dscriptor????
Gurjeet Singh wrote: On Windows, the write to log file is done by a thread (whose main function is pipeThread() ), and since it works completely independent of the SysLoggerMain() ( which is responsible for calling logfile_rotate() periodically, which in turn changes the global variable syslogFile) this is causing a race condition due to an error in the way we are using the related critical section. Thanks, committed. I hope this helps with Ati's problems. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Path separator
On Wed, Mar 18, 2009 at 9:24 AM, Magnus Hagander mag...@hagander.net wrote: I've seen a couple of reports that the new SSL error messages on windows look strange with paths the wrong way. For example: root certificate file C:\Documents and Settings\SNIP\Application Data/postgresql/root.crt does not exist. The issue being the mix of forward and backwards slashes. Attached patch should fix this. Is this worth doing? Comments? Yes. I've seen a couple of complaints as well, and both thought the error was actually the mixed slashes causing the problem, and *not* the missing root.crt. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] gettext, plural form and translation
Hi, all. gnu gettext have support for correct plural form translation (http://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html), but postgresql does not use it. why not ? maybe it have some problem in some supported OS ? if not, can it implemented ? maybe someone already doing this ? ps: i try to translate psql message (1 row)/(3 rows) but can't do this correctly without plural form support. need some work with source for implement it and xgettext params used for extract messages for http://babel.postgresql.org/ Thanks for comments ! -- Sergey Burladyan - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Path separator
I've seen a couple of reports that the new SSL error messages on windows
look strange with paths the wrong way. For example:
root certificate file C:\Documents and Settings\SNIP\Application
Data/postgresql/root.crt does not exist.
The issue being the mix of forward and backwards slashes. Attached patch
should fix this.
Is this worth doing? Comments?
//Magnus
diff --git a/src/include/port.h b/src/include/port.h
index 0557dd2..951f5ac 100644
--- a/src/include/port.h
+++ b/src/include/port.h
@@ -100,6 +100,12 @@ extern BOOL AddUserToDacl(HANDLE hProcess);
#define DEVTTY /dev/tty
#endif
+#if defined(WIN32) || defined(__CYGWIN__)
+#define PATH_SEPARATOR \\
+#else
+#define PATH_SEPARATOR /
+#endif
+
/*
* Win32 needs double quotes at the beginning and end of system()
* strings. If not, it gets confused with multiple quoted strings.
diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c
index 0833603..9f46c99 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -3964,7 +3964,7 @@ pqGetHomeDirectory(char *buf, int bufsize)
ZeroMemory(tmppath, sizeof(tmppath));
if (SHGetFolderPath(NULL, CSIDL_APPDATA, NULL, 0, tmppath) != S_OK)
return false;
- snprintf(buf, bufsize, %s/postgresql, tmppath);
+ snprintf(buf, bufsize, %s\\postgresql, tmppath);
return true;
#endif
}
diff --git a/src/interfaces/libpq/fe-secure.c b/src/interfaces/libpq/fe-secure.c
index 7c229c3..1b14f90 100644
--- a/src/interfaces/libpq/fe-secure.c
+++ b/src/interfaces/libpq/fe-secure.c
@@ -578,7 +578,7 @@ client_cert_cb(SSL *ssl, X509 **x509, EVP_PKEY **pkey)
if (conn-sslcert)
strncpy(fnbuf, conn-sslcert, sizeof(fnbuf));
else
- snprintf(fnbuf, sizeof(fnbuf), %s/%s, homedir, USER_CERT_FILE);
+ snprintf(fnbuf, sizeof(fnbuf), %s PATH_SEPARATOR %s, homedir, USER_CERT_FILE);
/*
* OpenSSL = 0.9.8 lacks error stack handling, which means it's likely to
@@ -693,7 +693,7 @@ client_cert_cb(SSL *ssl, X509 **x509, EVP_PKEY **pkey)
else
{
/* No PGSSLKEY specified, load default file */
- snprintf(fnbuf, sizeof(fnbuf), %s/%s, homedir, USER_KEY_FILE);
+ snprintf(fnbuf, sizeof(fnbuf), %s PATH_SEPARATOR %s, homedir, USER_KEY_FILE);
}
if (fnbuf[0] != '\0')
@@ -998,7 +998,7 @@ initialize_SSL(PGconn *conn)
if (conn-sslrootcert)
strncpy(fnbuf, conn-sslrootcert, sizeof(fnbuf));
else
- snprintf(fnbuf, sizeof(fnbuf), %s/%s, homedir, ROOT_CERT_FILE);
+ snprintf(fnbuf, sizeof(fnbuf), %s PATH_SEPARATOR %s, homedir, ROOT_CERT_FILE);
if (stat(fnbuf, buf) == 0)
{
@@ -1020,7 +1020,7 @@ initialize_SSL(PGconn *conn)
if (conn-sslcrl)
strncpy(fnbuf, conn-sslcrl, sizeof(fnbuf));
else
-snprintf(fnbuf, sizeof(fnbuf), %s/%s, homedir, ROOT_CRL_FILE);
+snprintf(fnbuf, sizeof(fnbuf), %s PATH_SEPARATOR %s, homedir, ROOT_CRL_FILE);
/* setting the flags to check against the complete CRL chain */
if (X509_STORE_load_locations(cvstore, fnbuf, NULL) == 1)
-
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] DDL+SQL in PL/pgSQL EXECUTE
Is it a bug or by design? I could not find what behaviour is correct for
these statements in PL/pgSQL:
This function just executes a string.
CREATE OR REPLACE FUNCTION _EXEC(query VARCHAR)
RETURNS VOID AS $$
BEGIN
EXECUTE query;
END;
$$ LANGUAGE 'plpgsql';
1. Works ok.
BEGIN WORK;
SELECT _EXEC('CREATE TABLE T(ID INTEGER); CREATE INDEX T_IDX ON T(ID)');
ROLLBACK;
2. Works ok.
BEGIN WORK;
SELECT _EXEC('CREATE TABLE T(ID INTEGER); ALTER TABLE T ADD COLUMN ID2
INTEGER; CREATE INDEX T_IDX2 ON T(ID2)');
ROLLBACK;
3. ERROR: relation t does not exist
SELECT _EXEC('CREATE TABLE T(ID INTEGER); INSERT INTO T(ID) VALUES (1)');
4. Inserts NULL value into ID column instead of default 10.
BEGIN WORK;
CREATE TABLE T(ID INTEGER);
SELECT _EXEC('ALTER TABLE T ALTER COLUMN ID SET DEFAULT(10); INSERT INTO
T DEFAULT VALUES');
SELECT * FROM T;
-
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] cs_CZ vs regression tests, part N
It's still broken: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gothic_mothdt=2009-03-17%2021:06:01 I remain of the opinion that supporting the regression tests in a locale that works like this is more trouble than it's worth. regards, tom lane - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] DDL+SQL in PL/pgSQL EXECUTE
Vlad Arkhipov arhi...@dc.baikal.ru writes:
3. ERROR: relation t does not exist
SELECT _EXEC('CREATE TABLE T(ID INTEGER); INSERT INTO T(ID) VALUES (1)');
4. Inserts NULL value into ID column instead of default 10.
BEGIN WORK;
CREATE TABLE T(ID INTEGER);
SELECT _EXEC('ALTER TABLE T ALTER COLUMN ID SET DEFAULT(10); INSERT INTO
T DEFAULT VALUES');
Commands submitted in a single string are typically parsed and planned
before they are executed (though the behavior probably depends on
context and which PG version you're talking about). My advice is
don't do that.
If we were to do anything about it, it'd probably be to ban
multi-statement EXECUTE on security grounds ...
regards, tom lane
-
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gettext, plural form and translation
Sergey Burladyan escribió: Hi, all. gnu gettext have support for correct plural form translation (http://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html), but postgresql does not use it. why not ? maybe it have some problem in some supported OS ? if not, can it implemented ? maybe someone already doing this ? ps: i try to translate psql message (1 row)/(3 rows) but can't do this correctly without plural form support. You don't need plural forms in this example. We have three separate messages, one for (No rows), another one for the singular (1 row) and a third one for the plural (N rows). We avoid mixing plurals and singulars. Is this still a problem for you somewhere? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gettext, plural form and translation
Alvaro Herrera escribió: Sergey Burladyan escribió: Hi, all. gnu gettext have support for correct plural form translation (http://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html), but postgresql does not use it. why not ? You don't need plural forms in this example. We have three separate messages, one for (No rows), another one for the singular (1 row) and a third one for the plural (N rows). After reading the cited page it is clear that we need to improve our use of gettext. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] could not bind IPv4 socket
Hi all, I installed postgresql 8.3.5 with these commands: - ./configure --enable-thread-safety (I need this because of dbt2) - make - make install I executed initdb. It's ok. I changed postgresql.conf file: listen_addresses = '*'. So, when I started postgresql, I receive these messages: $ pg_ctl start server starting $* LOG: could not bind IPv4 socket: Address already in use HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry.* LOG: database system was shut down at 2009-03-18 11:32:55 BRT LOG: autovacuum launcher started LOG: database system is ready to accept connections What's wrong? Why do I receive these messages (about IPv4 socket and HINT)? Can you help me? Thanks, Ana Carolina
Re: [HACKERS] could not bind IPv4 socket
Hi all, I resolved this problem. I had another postgresql installed and it started automatically when I restarted my computer. Thanks. 2009/3/18 Ana Carolina Brito de Almeida ana...@ig.com.br Hi all, I installed postgresql 8.3.5 with these commands: - ./configure --enable-thread-safety (I need this because of dbt2) - make - make install I executed initdb. It's ok. I changed postgresql.conf file: listen_addresses = '*'. So, when I started postgresql, I receive these messages: $ pg_ctl start server starting $* LOG: could not bind IPv4 socket: Address already in use HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry.* LOG: database system was shut down at 2009-03-18 11:32:55 BRT LOG: autovacuum launcher started LOG: database system is ready to accept connections What's wrong? Why do I receive these messages (about IPv4 socket and HINT)? Can you help me? Thanks, Ana Carolina
Re: [HACKERS] DTrace probes broken in HEAD on Solaris?
Dne 17.03.09 19:49, Tom Lane napsal(a): Zdenek Kotala zdenek.kot...@sun.com writes: Answer why it happens when probes are disabled is, that for user application there are piece of code which prepare DTrace probes arguments which will be passed into kernel DTrace modul. This code has performance penalty which depends on number of arguments. More specifically, it seems that DTrace is designed so that it evaluates all the arguments to a probe macro before it decides whether to actually take the trap or not. yeah, it is valid for USDT. I guess main reason for this is implementation is that DTrace does not have idea how compiler generates code and where he can find arguments. Only what it knows is how to call a probe and this call is noped. This seems to me to be a pretty bad/surprising behavior; it's not the way that our Assert macros work, for example. There's a performance issue, which would probably only be brutally obvious if you had an expensive function in the arguments. (Before you say no one would do that, note the relpath() calls I was complaining about last week.) But we've been muttering about dropping probes into some extremely hot hot-spots, like spinlock acquisition, and even a few more instructions to copy local variables could make a difference there. yeah, spinlock is problem, but on other side the probes are only in the branch when spinlock is not free and sleep anyway. And LWLOCK_ACQUIRE probe has minimal impact if you compare it with rest of LWLockAcquire function. The other thing I don't like is that this implementation exposes people to any bugs that may exist in the probe arguments, *even when they don't have any tracing turned on*. (Again, we had two different instances of that last week, so don't bother arguing that it doesn't happen.) I don't accept your argument here. Better if it fails every time not only when you enable the probe. DTrace is designated to be safe on production machine. It is not good to shut down postgresql server in production... Both of these considerations are strong arguments for not building production installations with --enable-dtrace, just as we don't encourage people to build for production with --enable-cassert. But of course part of the argument for dtrace support is that people would like to have such probing available in production installations. What I've found out about this is that for each probe macro, DTrace also defines a foo_ENABLED() macro that can be used like this: if (foo_ENABLED()) foo(...); I think what we should do about these considerations is fix our macro definitions so that the if(ENABLED()) test is built into the macros. I'm not sure what this will require ... probably some post-processing of the probes.h file ... but if we don't do it we're going to keep getting bit. I like this idea to used if(foo_ENABLED), but maybe we should used it only when args evaluation is more complicated? I'm not sure if it is good idea to modify macros definition. See how macro definition look like: #define TRACE_POSTGRESQL_LWLOCK_ACQUIRE(arg0, arg1) \ __dtrace_postgresql___lwlock__acquire(arg0, arg1) #define TRACE_POSTGRESQL_LWLOCK_ACQUIRE_ENABLED() \ __dtraceenabled_postgresql___lwlock__acquire() Maybe add something like this at the end of probe.h: #define TRACE_POSTGRESQL_LWLOCK_ACQUIRE_COND(arg0, arg1) \ if( TRACE_POSTGRESQL_LWLOCK_ACQUIRE_ENABLED() ) \ TRACE_POSTGRESQL_LWLOCK_ACQUIRE(arg0, arg1) Zdenek - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cs_CZ vs regression tests, part N
Dne 18.03.09 13:35, Tom Lane napsal(a): It's still broken: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gothic_mothdt=2009-03-17%2021:06:01 Yes, it is. But it is PL test now ;-). I remain of the opinion that supporting the regression tests in a locale that works like this is more trouble than it's worth. Problem disappear when collation per column will be implemented. Until it we need to workaround it somehow. Zdenek - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review: B-Tree emulation for GIN
It's easy to un-dirty that hack, but before I'd like to see your comments about thoughts above. Yeah, please revert that hack. Done. Also, I changed void *extra_data to Pointer extra_data and corresponding **extra_data and ***extra_data to simplify understanding. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ btree_gin-0.12.gz Description: Unix tar archive - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Immediate shutdown and system(3)
Ok, I've committed a minimal patch to pg_standby in CVS HEAD and REL8_3_STABLE to not interpret SIGQUIT as a signal for failover. I added a signal handler for SIGUSR1 to trigger failover; that should be considered the preferred signal for that, even though SIGINT still works too. SIGQUIT is trapped to just die immediately, but without core dumping. As we still use SIGQUIT for immediate shutdown, any other archive_command or restore_command will still receive SIGQUIT on immediate shutdown, and by default dump core. Let's just live with that for now.. This should be mentioned in release notes, as any script that might be using SIGQUIT at the moment needs to be changed to use SIGUSR1 or SIGINT instead. Where should I make a note of that so that we don't forget? Heikki Linnakangas wrote: Fujii Masao wrote: Hi, On Mon, Mar 2, 2009 at 4:59 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Fujii Masao wrote: On Fri, Feb 27, 2009 at 6:52 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: I'm leaning towards option 3, but I wonder if anyone sees a better solution. 4. Use the shared memory to tell the startup process about the shutdown state. When a shutdown signal arrives, postmaster sets the corresponding shutdown state to the shared memory before signaling to the child processes. The startup process check the shutdown state whenever executing system(), and determine how to exit according to that state. This solution doesn't change any existing behavior of pg_standby. What is your opinion? That would only solve the problem for pg_standby. Other programs you might use as a restore_command or archive_command like cp or rsync would still core dump on the SIGQUIT. Right. I've just understood your intention. I also agree with option 3 if nobody complains about lack of backward compatibility of pg_standby. If no, how about using SIGUSR2 instead of SIGINT for immediate shutdown of only the archiver and the startup process. SIGUSR2 by default terminates the process. The archiver already uses SIGUSR2 for pgarch_waken_stop, so we need to reassign that function to another signal (SIGINT is suitable, I think). This solution doesn't need signal multiplexing. Thought? Hmm, the startup/archiver process would then in turn need to kill the external command with SIGINT. I guess that would work. There's a problem with my idea of just using SIGINT instead of SIGQUIT. Some (arguably bad-behaving) programs trap SIGINT and exit() with a return code. The startup process won't recognize that as killed by signal, and we're back to same problem we have with pg_standby that the startup process doesn't die but continues with the startup. Notably rsync seems to behave like that. BTW, searching the archive, I found this long thread about this same issue: http://archives.postgresql.org/pgsql-hackers/2006-11/msg00406.php The idea of SIGUSR2 was mentioned there as well, as well as the idea of reimplementing system(3). The conclusion of that thread was the usage of setsid() and process groups, to ensure that the SIGQUIT is delivered to the archive/recovery_command. I'm starting to feel that this is getting too complicated. Maybe we should just fix pg_standby to not trap SIGQUIT, and live with the core dumps... -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Solaris getopt_long and PostgreSQL
On Tuesday 17 March 2009 20:02:14 Tom Lane wrote: Zdenek Kotala zdenek.kot...@sun.com writes: [ use Solaris' version of getopt_long ] The reason not to do that was discussed in this thread: http://archives.postgresql.org//pgsql-patches/2008-02/msg00075.php That discussion was about option parsing in postgres/postmaster, which does not use getopt_long at all. - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gettext, plural form and translation
On Wednesday 18 March 2009 11:21:03 Sergey Burladyan wrote: gnu gettext have support for correct plural form translation (http://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html), but postgresql does not use it. why not ? maybe it have some problem in some supported OS ? Yes, the main reason is that it is not clear whether this is supported on all OS, or moreover that I believe it is not. So some allowances for that will probably have to be made. - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Immediate shutdown and system(3)
Andrew Dunstan wrote: Heikki Linnakangas wrote: This should be mentioned in release notes, as any script that might be using SIGQUIT at the moment needs to be changed to use SIGUSR1 or SIGINT instead. Where should I make a note of that so that we don't forget? Unless I'm missing it the use of signals to trigger failover is not documented AT ALL. So why anyone would expect such behaviour is something of a mystery. Well, some people do read source code. If it was more widely known, I would hesitate more to change it, though. Perhaps doing that would be even more important than release notes. Agreed it should be documented. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] small but useful patches for text search
On Tuesday 17 March 2009 18:00:57 Robert Haas wrote: Basically, for the project to grow, it needs more committers, and the precondition for being added as a committer should be a promise to spend a certain amount of time reviewing and committing patches other than your own. According to the wiki, we have 15 committers, which is more than enough, but most of those are inactive or are just there as maintainers for very specific portions of the code. The limiting factor is mainly time, not talent or dedication. Contributing to PostgreSQL requires a lot of time for learning and staying up to date, and very few people have lives that permit that. The alternatives are making the code more modular and improving the tools, but both can only go so far. - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Path separator
Magnus Hagander mag...@hagander.net writes: I've seen a couple of reports that the new SSL error messages on windows look strange with paths the wrong way. For example: root certificate file C:\Documents and Settings\SNIP\Application Data/postgresql/root.crt does not exist. The issue being the mix of forward and backwards slashes. Attached patch should fix this. Is this worth doing? Comments? In view of the way that canonicalize_path() works, I can't help thinking this is going in precisely the wrong direction. Also, don't we already have a macro someplace for the platform's preferred path separator? regards, tom lane - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Immediate shutdown and system(3)
Heikki Linnakangas wrote: This should be mentioned in release notes, as any script that might be using SIGQUIT at the moment needs to be changed to use SIGUSR1 or SIGINT instead. Where should I make a note of that so that we don't forget? The CVS commit message. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Immediate shutdown and system(3)
On Wed, Mar 18, 2009 at 4:40 PM, Bruce Momjian br...@momjian.us wrote: Heikki Linnakangas wrote: This should be mentioned in release notes, as any script that might be using SIGQUIT at the moment needs to be changed to use SIGUSR1 or SIGINT instead. Where should I make a note of that so that we don't forget? The CVS commit message. Is there some reason we don't just put it in the release notes as *part* of the commit? Someone can always go back and edit it later. It seems like that would be easier and less error-prone than grepping the CVS commit logs for release notes... ...Robert - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Immediate shutdown and system(3)
Robert Haas robertmh...@gmail.com writes: On Wed, Mar 18, 2009 at 4:40 PM, Bruce Momjian br...@momjian.us wrote: The CVS commit message. Is there some reason we don't just put it in the release notes as *part* of the commit? Someone can always go back and edit it later. That was suggested before, and I think we actually tried it for a few months. It didn't work. Putting an item in the release notes *properly* is a whole lot more work than putting a short bit of text in the CVS log (especially for committers whose first language isn't English). It would also create a lot more merge-collision issues for unrelated patches. It's less trouble overall to do the editing, organizing, and SGML-ifying of all the release notes at once. Also you end up with a better product, assuming that whoever is doing the notes puts in reasonable editorial effort. regards, tom lane - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Immediate shutdown and system(3)
On Wed, Mar 18, 2009 at 5:12 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Wed, Mar 18, 2009 at 4:40 PM, Bruce Momjian br...@momjian.us wrote: The CVS commit message. Is there some reason we don't just put it in the release notes as *part* of the commit? Someone can always go back and edit it later. That was suggested before, and I think we actually tried it for a few months. It didn't work. Putting an item in the release notes *properly* is a whole lot more work than putting a short bit of text in the CVS log (especially for committers whose first language isn't English). It would also create a lot more merge-collision issues for unrelated patches. Yeah, I wouldn't ask people to include it in the patches they post. That would be a pain, and people would probably tend (with the best of intentions) to inflate the relative importance of their own work. I was thinking that the committer could make a quick entry at the time they actually committed the patch, so that the step you describe below could start with something other than an email box. It's less trouble overall to do the editing, organizing, and SGML-ifying of all the release notes at once. Also you end up with a better product, assuming that whoever is doing the notes puts in reasonable editorial effort. If it works for the people who are doing it, good enough. ...Robert - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Immediate shutdown and system(3)
Heikki Linnakangas wrote: Ok, I've committed a minimal patch to pg_standby in CVS HEAD and REL8_3_STABLE to not interpret SIGQUIT as a signal for failover. I added a signal handler for SIGUSR1 to trigger failover; that should be considered the preferred signal for that, even though SIGINT still works too. SIGQUIT is trapped to just die immediately, but without core dumping. As we still use SIGQUIT for immediate shutdown, any other archive_command or restore_command will still receive SIGQUIT on immediate shutdown, and by default dump core. Let's just live with that for now.. This should be mentioned in release notes, as any script that might be using SIGQUIT at the moment needs to be changed to use SIGUSR1 or SIGINT instead. Where should I make a note of that so that we don't forget? Unless I'm missing it the use of signals to trigger failover is not documented AT ALL. So why anyone would expect such behaviour is something of a mystery. Perhaps doing that would be even more important than release notes. cheers andrew - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gettext, plural form and translation
Alvaro Herrera alvhe...@commandprompt.com writes: Sergey Burladyan escribió: gnu gettext have support for correct plural form translation (http://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html), but postgresql does not use it. why not ? maybe it have some problem in some supported OS ? if not, can it implemented ? maybe someone already doing this ? ps: i try to translate psql message (1 row)/(3 rows) but can't do this correctly without plural form support. You don't need plural forms in this example. We have three separate messages, one for (No rows), another one for the singular (1 row) and a third one for the plural (N rows). only one third message for plural is not enough for example for Russian. Russian have three plural forms, for example: 2 rows | 2 zapisy 3 rows | 3 zapisy 5 rows | 5 zapisey 11 rows | 11 zapisey 21 rows | 21 zapis etc We avoid mixing plurals and singulars. Is this still a problem for you somewhere? don't know :) i see this untranslated message (N rows) every day and try to translate it and find this issue. Peter Eisentraut pete...@gmx.net writes: On Wednesday 18 March 2009 11:21:03 Sergey Burladyan wrote: gnu gettext have support for correct plural form translation (http://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html), but postgresql does not use it. why not ? maybe it have some problem in some supported OS ? Yes, the main reason is that it is not clear whether this is supported on all OS, or moreover that I believe it is not. So some allowances for that will probably have to be made. maybe build farm can help to test it ? i think about (N rows) message today and find other solution. i do not essentially need this support for this message. because if i exchange position of word and number in translated message - it will have right pronunciation, something like: (rows: N) | (zapisey: N) | (записей: N) is it correct to add ':' in translated message ? i think colon is need here because sense part of message is not first... ps: but this change order is look like hack and look like this program is not support correct spelling and use only one plural form :) and original order with different plural form is more closely to original English text. also, how about other languages ? IMHO not all of it can have simple solution like change words order... i think support for ngettext() still must be implemented. if some problem with it will be found - it can be rejected, isn't it ? =) -- Sergey Burladyan - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gettext, plural form and translation
Sergey Burladyan escribió: Alvaro Herrera alvhe...@commandprompt.com writes: Yes, the main reason is that it is not clear whether this is supported on all OS, or moreover that I believe it is not. So some allowances for that will probably have to be made. maybe build farm can help to test it ? Yes, I think we should implement it and see what happens with the buildfarm. If we stand still and do nothing, we won't be any wiser. Care to submit a patch? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gettext, plural form and translation
Alvaro Herrera alvhe...@commandprompt.com writes: Sergey Burladyan escribió: Alvaro Herrera alvhe...@commandprompt.com writes: Yes, the main reason is that it is not clear whether this is supported on all OS, or moreover that I believe it is not. So some allowances for that will probably have to be made. maybe build farm can help to test it ? Yes, I think we should implement it and see what happens with the buildfarm. If we stand still and do nothing, we won't be any wiser. Care to submit a patch? i will try. -- Sergey Burladyan - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gettext, plural form and translation
Alvaro Herrera alvhe...@commandprompt.com writes: Sergey Burladyan escribió: maybe build farm can help to test it ? Yes, I think we should implement it and see what happens with the buildfarm. If we stand still and do nothing, we won't be any wiser. The buildfarm is irrelevant to the fact that some platforms don't have ngettext. If the patch is designed to use ngettext where available, and to be no worse than what we have where it isn't, then we could consider it. regards, tom lane - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with accesing Oracle from plperlu functionwhen using remote pg client.
On Tue, Mar 17, 2009 at 11:27:54AM +0100, Albe Laurenz wrote: Tom Lane wrote: The solution to this is to change the following line in src/backend/postmaster/postmaster.c: We're not going to break a bunch of other applications in order to make some undocumented, unsupported Oracle thingie work (until they change it...). Got another solution? Yes :^) Upgrade to a recent Oracle Patch Set. OK, I'm not taking on responsibility for a *fixed* Oracle bug, so that's what I've put in the README.Oracle :) Cheers, David. The problem is not a corner case, as it also affected user and machine names (though I have no idea who would have parentheses or equality signs in these) as well as programs run from directories with bad characters in the name. The problem is tracked as bug 3807408 by oracle and has been fixed in 9.2.0.8, 10.2.0.3 and 11.1.0.6. If you don't want to upgrade, you can also apply the One-Off Patch 3807408 which has been issued for 10.2.0.1 and 9.2.0.7 for most UNIX platforms. I tested it with a C program named parens (5432) on Linux with Oracle 10.2.0.4, and it works fine. Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
