Re: [HACKERS] spinlocks on HP-UX
On Thu, Dec 29, 2011 at 11:37:22AM +0900, Manabu Ori wrote: a configure test only proves whether the build machine can deal with the flag, not whether the machine the executables will ultimately run on knows what the flag means. We cannot assume that the build and execution boxes are the same. (In general, AC_TRY_RUN tests are best avoided because of this.) I understand why that is important in general, but as a shop which builds from source, and is fine with a separate build for each hardware model / OS version combination, it would be great if any optimizations which are only available if you *do* assume that the build machine and the run machine are the same (or at lease identical) could be enabled with some configure switch. Maybe something like --enable-platform-specific-optimizations. I don't know if any such possible optimizations currently exist, I'm just saying that if any are identified, it would be nice to have the option of using them. I can't say the right way to go for now, but I'd like binary packages could enjoy the effect of my patch as far as possible so that I made lwarx hint test run in configure runtime. Was there any conclusion to this discussion? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] [NOVICE] index refuses to build
On Thu, Dec 29, 2011 at 10:40:19PM -0500, Tom Lane wrote: Merlin Moncure mmonc...@gmail.com writes: On Thu, Dec 29, 2011 at 5:10 PM, Jean-Yves F. Barbier 12u...@gmail.com wrote: CREATE INDEX tst1m_name_lu_ix ON tst1m(unaccent(name)); ERROR: functions in index expression must be marked IMMUTABLE your problem is the unaccent function. it's defined stable because the rules function it depends on can change after the index is built -- that would effectively introduce index corruption. it's possible to bypass that restriction, but are you sure that's what you want to do? Hmm ... it's clear why unaccent(text) is only stable, because it depends on the current search_path to find the unaccent dictionary. But I wonder whether it was an oversight that unaccent(regdictionary, text) is stable and not immutable. We don't normally mark functions as stable just because you could in principle change their behavior by altering some outside-the-database configuration files. Should we change the function signature for unaccent(regdictionary, text)? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] plperl sigfpe reset can crash the server
On Saturday, August 25, 2012 06:38:09 AM Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: Doing a pqsignal(SIGFPE, FloatExceptionHandler) after PERL_SYS_INIT3 seems to work. Is that acceptable? Surely that's breaking perl's expectations, to more or less the same degree they're breaking ours? In the referenced bug they agree that this is the way forward. There is the issue of corrupting the perl environment if you manage to generate a SIGFPE - I couldn't so far - but I see no way other than of teaching the sigfpe handler to really ignore the error as perl wants. Not sure if adding such ugliness is acceptable. The issue that the handler does a longjmp out of external code is a general problem btw. While pg will probably never create a sigfpe while in anything critical the same cannot be said about external code. So anything external with persistent state probably can be made to crash or similar. Not sure if there is any real way out of this but making the handler FATAL if non pg code is running. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- 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] PATCH: pgbench - random sampling of transaction written into log
On 26.8.2012 02:48, Tomas Vondra wrote:
On 26.8.2012 00:19, Jeff Janes wrote:
On Fri, Aug 24, 2012 at 2:16 PM, Tomas Vondra t...@fuzzy.cz wrote:
Hi,
attached is a patch that adds support for random sampling in pgbench, when
it's executed with -l flag. You can do for example this:
$ pgbench -l -T 120 -R 1 db
and then only 1% of transactions will be written into the log file. If you
omit the tag, all the transactions are written (i.e. it's backward
compatible).
Hi Tomas,
You use the rand() function. Isn't that function not thread-safe?
Or, if it is thread-safe, does it accomplish that with a mutex? That
was a problem with a different rand function used in pgbench that
Robert Haas fixed a while ago, 4af43ee3f165c8e4b332a7e680.
Hi Jeff,
Aha! Good catch. I've used rand() which seems to be neither reentrant or
thread-safe (unless the man page is incorrect). Anyway, using pg_erand48
or getrand seems like an appropriate fix.
Also, what benefit is had by using modulus on rand(), rather than just
modulus on an incrementing counter?
Hmm, I was thinking about that too, but I wasn't really sure how would
that behave with multiple SQL files etc. But now I see the files are
actually chosen randomly, so using a counter seems like a good idea.
Attached is an improved patch, with a call to rand() replaced with
getrand().
I was thinking about the counter but I'm not really sure how to handle
cases like 39% - I'm not sure a plain (counter % 100 37) is not a
good sampling, because it always keeps continuous sequences of
transactions. Maybe there's a clever way to use a counter, but let's
stick to a getrand() unless we can prove is't causing issues. Especially
considering that a lot of data won't be be written at all with low
sampling rates.
kind regards
Tomas
diff --git a/contrib/pgbench/pgbench.c b/contrib/pgbench/pgbench.c
index 00cab73..12c1338 100644
--- a/contrib/pgbench/pgbench.c
+++ b/contrib/pgbench/pgbench.c
@@ -145,6 +145,9 @@ char *index_tablespace = NULL;
#define naccounts 10
bool use_log;/* log transaction latencies to
a file */
+bool use_log_sampling; /* sample the log randomly */
+intnsample_rate = 100; /* default log sampling rate */
+
bool is_connect; /* establish connection for
each transaction */
bool is_latencies; /* report per-command latencies */
intmain_pid; /* main process id used
in log filename */
@@ -364,6 +367,7 @@ usage(void)
-f FILENAME read transaction script from FILENAME\n
-j NUM number of threads (default: 1)\n
-l write transaction times to log file\n
+-R NUM log sampling rate in pct (default: 100)\n
-M simple|extended|prepared\n
protocol for submitting queries to server
(default: simple)\n
-n do not run VACUUM before tests\n
@@ -877,21 +881,25 @@ top:
instr_time diff;
double usec;
- INSTR_TIME_SET_CURRENT(now);
- diff = now;
- INSTR_TIME_SUBTRACT(diff, st-txn_begin);
- usec = (double) INSTR_TIME_GET_MICROSEC(diff);
+ /* either no sampling or is within the sample */
+ if ((! use_log_sampling) || (getrand(thread, 0, 99)
nsample_rate)) {
+
+ INSTR_TIME_SET_CURRENT(now);
+ diff = now;
+ INSTR_TIME_SUBTRACT(diff, st-txn_begin);
+ usec = (double) INSTR_TIME_GET_MICROSEC(diff);
#ifndef WIN32
- /* This is more than we really ought to know about
instr_time */
- fprintf(logfile, %d %d %.0f %d %ld %ld\n,
- st-id, st-cnt, usec, st-use_file,
- (long) now.tv_sec, (long) now.tv_usec);
+ /* This is more than we really ought to know
about instr_time */
+ fprintf(logfile, %d %d %.0f %d %ld %ld\n,
+ st-id, st-cnt, usec,
st-use_file,
+ (long) now.tv_sec, (long)
now.tv_usec);
#else
- /* On Windows, instr_time doesn't provide a timestamp
anyway */
- fprintf(logfile, %d %d %.0f %d 0 0\n,
- st-id, st-cnt, usec, st-use_file);
+ /* On Windows, instr_time doesn't provide a
timestamp anyway */
+ fprintf(logfile, %d %d %.0f %d 0 0\n,
+
Re: [HACKERS] 9.2RC1 wraps this Thursday ...
On 08/24/2012 10:10 AM, Tom Lane wrote: Magnus Hagander mag...@hagander.net writes: On Fri, Aug 24, 2012 at 1:06 AM, Andrew Dunstan and...@dunslane.net wrote: TBH I'd rather stick with the less invasive approach of the original patch at this stage, and see about refactoring for 9.3. +1. While I haven't looked at the code specifically, these areas can be quite fragile and very environment-dependent. I'd rather not upset it this close to release - especially not after RC wrap. Fair enough. Will one of you deal with the patch as-is, then? I had a brief talk with Magnus the other day, and I have just spent more time looking over this. This is a fairly narrow failure case, with a not so narrow proposed solution. Making pg_ctl re-exec itself whenever we see that we're running as an admin user is a very broad brush approach, since the problem is restricted to cases where we have a config-only data directory. I'm particularly concerned about the possible effect that might have on pg_ctl when it's running as a service controller, and I'm not prepared to commit anything like the current patch without a great deal more testing. A temporary bandaid might be to do the detection of admin privileges and go back to doing what we did there before we got adjust_data_dir() for that case. That at least should work no worse than what we have now. 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] 9.2RC1 wraps this Thursday ...
Andrew Dunstan and...@dunslane.net writes: I had a brief talk with Magnus the other day, and I have just spent more time looking over this. This is a fairly narrow failure case, with a not so narrow proposed solution. Making pg_ctl re-exec itself whenever we see that we're running as an admin user is a very broad brush approach, since the problem is restricted to cases where we have a config-only data directory. I'm particularly concerned about the possible effect that might have on pg_ctl when it's running as a service controller, and I'm not prepared to commit anything like the current patch without a great deal more testing. Good point. A temporary bandaid might be to do the detection of admin privileges and go back to doing what we did there before we got adjust_data_dir() for that case. That at least should work no worse than what we have now. Unless I'm missing something, pg_ctl basically doesn't work with config-only directory setups before 9.2: since it has no way to find the postmaster.pid file, any case that waits for the postmaster to start or stop will fail in a confusing fashion. So the fact that the case still doesn't work on Windows doesn't constitute a regression; in fact, it might be *more* user-friendly this way, since you'll get an error rather than obscure misbehavior. Rather than applying a hasty band-aid, I think it's probably better to sit back and think about a solution for 9.3. BTW, one idea that occurs to me is to bypass the problem by skipping the server's no-root-privileges check when the postmaster is given the -C switch. (This shouldn't pose a security hazard, since reading the config files is something a root-privileged caller could do anyway.) I don't immediately see a non-ugly way to do that in the current server code structure, but maybe somebody else will have an idea. 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] 9.2RC1 wraps this Thursday ...
On 08/26/2012 03:15 PM, Tom Lane wrote: BTW, one idea that occurs to me is to bypass the problem by skipping the server's no-root-privileges check when the postmaster is given the -C switch. (This shouldn't pose a security hazard, since reading the config files is something a root-privileged caller could do anyway.) I don't immediately see a non-ugly way to do that in the current server code structure, but maybe somebody else will have an idea. I had the same idea, and couldn't see a simple way to do it either. The trouble is that the check_root() call comes too early for us to do it cleanly. But I'll have another look. 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] 64-bit API for large object
Hi, I found this in the TODO list: Add API for 64-bit large object access If this is a still valid TODO item and nobody is working on this, I would like to work in this. Here are the list of functions think we need to change. 1) Frontend lo_* libpq functions(fe-lobj.c) lo_initialize() need to get backend 64-bit large object handling function's oid, namely lo_lseek64, lo_tell64, lo_truncate64, loread64, lowrite64(explained later). If they are not available, use older 32-bit backend functions. BTW, currently lo_initialize() throws an error if one of oids are not avilable. I doubt we do the same way for 64-bit functions since this will make 9.3 libpq unable to access large objects stored in pre-9.2 PostgreSQL servers. 2) Bakend lo_* functions (be-fsstubs.c) Add lo_lseek64, lo_tell64, lo_truncate64, loread64 and lowrite64 so that they can handle 64-bit seek position and data lenghth. 3) Backend inv_api.c functions No need to add new functions. Just extend them to handle 64-bit data. BTW , what will happen if older 32-bit libpq accesses large objects over 2GB? lo_read and lo_write: they can read or write lobjs using 32-bit API as long as requested read/write data length is smaller than 2GB. So I think we can safely allow them to access over 2GB lobjs. lo_lseek: again as long as requested offset is smaller than 2GB, there would be no problem. lo_tell:if current seek position is beyond 2GB, returns an error. Comments, suggestions? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Incorrect comment in fe-lobj.c
I found following in fe-lobj.c: /* * lo_lseek *change the current read or write location on a large object * currently, only L_SET is a legal value for whence * */ I don't know where L_SET comes from. Anyway this should be: * whence must be one of SEEK_SET, SEEK_CUR or SEEK_END. If there's no objection, I will change this. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- 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] 64-bit API for large object
Tatsuo Ishii is...@postgresql.org writes: Here are the list of functions think we need to change. 1) Frontend lo_* libpq functions(fe-lobj.c) lo_initialize() need to get backend 64-bit large object handling function's oid, namely lo_lseek64, lo_tell64, lo_truncate64, loread64, lowrite64(explained later). If they are not available, use older 32-bit backend functions. I don't particularly see a need for loread64 or lowrite64. Who's going to be reading or writing more than 2GB at once? If someone tries, they'd be well advised to reconsider their code design anyway. 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] Incorrect comment in fe-lobj.c
Tatsuo Ishii is...@postgresql.org writes: I found following in fe-lobj.c: * currently, only L_SET is a legal value for whence I don't know where L_SET comes from. Hmm, seems to be that way in the original commit to our CVS (Postgres95). I don't find this code at all in Postgres v4r2 though. I just remembered that L_SET came from old BSDish systems. Anyway this should be: * whence must be one of SEEK_SET, SEEK_CUR or SEEK_END. Agreed. But looking at this brings a thought to mind: our code is assuming that SEEK_SET, SEEK_CUR, SEEK_END have identical values on the client and server. The lack of complaints over the past fifteen years suggests that every Unix-oid platform is in fact using the same values for these macros ... but that seems kind of a risky assumption. Is it worth changing? And if so, how would we go about that? I personaly have not seen any definitions other than below before. # define SEEK_SET 0 /* Seek from beginning of file. */ # define SEEK_CUR 1 /* Seek from current position. */ # define SEEK_END 2 /* Seek from end of file. */ However I agree your point. What about defining our own definitions which have exact same values as above? i.e.; # define PG_SEEK_SET0 /* Seek from beginning of file. */ # define PG_SEEK_CUR1 /* Seek from current position. */ # define PG_SEEK_END2 /* Seek from end of file. */ -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- 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] 64-bit API for large object
1) Frontend lo_* libpq functions(fe-lobj.c) lo_initialize() need to get backend 64-bit large object handling function's oid, namely lo_lseek64, lo_tell64, lo_truncate64, loread64, lowrite64(explained later). If they are not available, use older 32-bit backend functions. I don't particularly see a need for loread64 or lowrite64. Who's going to be reading or writing more than 2GB at once? If someone tries, they'd be well advised to reconsider their code design anyway. Ok, loread64 and lowrite64 will not be added. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- 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] alternate psql file locations
On Mon, Jan 2, 2012 at 11:18:47AM -0500, Andrew Dunstan wrote: It's worked for things I've wanted, I haven't tried it for psql stuff Yeah, but it's a bit hacky. I might well not want $HOME reset. Here's a small patch that does what I think would suit me and Alvaro. Incidentally, this actually doesn't work anyway. psql gets the home path from getpwuid() and ignores $HOME. You could argue that that's a bug, but it's been that way for a long time. So, do we want to fix this and honor $HOME? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] alternate psql file locations
On 08/26/2012 10:13 PM, Bruce Momjian wrote: On Mon, Jan 2, 2012 at 11:18:47AM -0500, Andrew Dunstan wrote: It's worked for things I've wanted, I haven't tried it for psql stuff Yeah, but it's a bit hacky. I might well not want $HOME reset. Here's a small patch that does what I think would suit me and Alvaro. Incidentally, this actually doesn't work anyway. psql gets the home path from getpwuid() and ignores $HOME. You could argue that that's a bug, but it's been that way for a long time. So, do we want to fix this and honor $HOME? Not really. Mangling it is a nasty hack anyway. Meanwhile see the subsequent 9.2 feature (described thus in the release notes): * Provide environment variable overrides for psql history and startup file locations (Andrew Dunstan) Specifically, PSQL_HISTORY and PSQLRC determine these file names if set. 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] Why does analyze_new_cluster.sh use sleep?
On Fri, 2012-08-24 at 08:19 -0400, Bruce Momjian wrote: Well, the idea is that the script is running stages, and your system is mostly useful after the first stage is done. I don't see a keypress as helping there. I think this is different from the vacuumdb case. Well, this is all debatable, but we certainly don't need the sleep before the first vacuum, do we? -- 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] [patch] Improve documentation around FreeBSD Kernel Tuning
On Tue, Jan 3, 2012 at 05:24:06PM -0700, Brad Davis wrote: On Tue, Jan 03, 2012 at 06:43:52PM -0500, Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: Since I didn't actually tell you that I've made a context diff for you, and it's attached. I'll let someone with more FBSD-fu than me actually comment on it. I have no FBSD-fu whatever, but the question this patch raises in my mind is whether /boot/loader.conf exists in every version of FBSD. If not, we probably need to say something like do this in versions = whatever, and do the other in versions before that. Likewise, has it always been true that -w is unnecessary? For other systems such as Mac OS X, we have recommendations covering quite ancient OS releases, and I don't see why we'd not hold the FreeBSD section to the same standard. Well.. The man page appeared somewhere between FreeBSD 3.0 and 4.0.. and 4.0 was released March 14, 2000. Applied to PG 9.3. Sorry for the long delay. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Why does analyze_new_cluster.sh use sleep?
On Sun, Aug 26, 2012 at 11:12:15PM -0400, Peter Eisentraut wrote: On Fri, 2012-08-24 at 08:19 -0400, Bruce Momjian wrote: Well, the idea is that the script is running stages, and your system is mostly useful after the first stage is done. I don't see a keypress as helping there. I think this is different from the vacuumdb case. Well, this is all debatable, but we certainly don't need the sleep before the first vacuum, do we? That sleep is there so they can react to this line: fprintf(script, echo %sIf you would like default statistics as quickly as possible, cancel%s\n, -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Incorrect comment in fe-lobj.c
Tatsuo Ishii is...@postgresql.org writes: Agreed. But looking at this brings a thought to mind: our code is assuming that SEEK_SET, SEEK_CUR, SEEK_END have identical values on the client and server. The lack of complaints over the past fifteen years suggests that every Unix-oid platform is in fact using the same values for these macros ... but that seems kind of a risky assumption. Is it worth changing? And if so, how would we go about that? I personaly have not seen any definitions other than below before. # define SEEK_SET 0 /* Seek from beginning of file. */ # define SEEK_CUR 1 /* Seek from current position. */ # define SEEK_END 2 /* Seek from end of file. */ Same here. However I agree your point. What about defining our own definitions which have exact same values as above? i.e.; # define PG_SEEK_SET 0 /* Seek from beginning of file. */ # define PG_SEEK_CUR 1 /* Seek from current position. */ # define PG_SEEK_END 2 /* Seek from end of file. */ Well, the thing is: if all platforms use those same values, then this is a pretty useless change (and yet one that affects client applications, not only our own code). If not all platforms use those values, then this is a wire-protocol break for those that don't. Is there a way to fix things so that we don't have a protocol break? I think it's clearly impossible across platforms that have inconsistent SEEK_XXX definitions; but such cases were incompatible before anyway. Can we make it not break if client and server are the same platform, but have some other set of SEEK_XXX values? 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] FATAL: bogus data in lock file postmaster.pid:
On Fri, Jan 6, 2012 at 08:28:48AM -0500, Michael Beattie wrote: On Fri, Jan 6, 2012 at 6:13 AM, Magnus Hagander mag...@hagander.net wrote: On Thu, Jan 5, 2012 at 23:19, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Thu, Jan 5, 2012 at 17:13, Tom Lane t...@sss.pgh.pa.us wrote: I think link(2) would create race conditions of its own. I'd be inclined to suggest that maybe we should just special-case a zero length postmaster.pid file as meaning okay to proceed. In general, garbage That's pretty much what I meant - but with a warning message. Actually ... wait a minute. If we allow that, don't we create a race condition between two postmasters starting at almost the same instant? The second one could see the lock file when the first has created but not yet filled it. Good point, yeah, it should do that. But I still think it's rare enough that just special-casing the error message should be enough... so just something that does like stat(filename, st); size = st.st_size; if (size == 0) elog(ERROR, lock file \%s\ has 0 length., filename); somewhere in CreateLockFile in miscinit.c? I have developed the attached patch to report a zero-length file, as you suggested. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + diff --git a/src/backend/utils/init/miscinit.c b/src/backend/utils/init/miscinit.c new file mode 100644 index 775d71f..7b7c141 *** a/src/backend/utils/init/miscinit.c --- b/src/backend/utils/init/miscinit.c *** CreateLockFile(const char *filename, boo *** 765,770 --- 765,772 errmsg(could not read lock file \%s\: %m, filename))); close(fd); + if (len == 0) + elog(FATAL, lock file \%s\ is empty, DIRECTORY_LOCK_FILE); buffer[len] = '\0'; encoded_pid = atoi(buffer); -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
