CommitDelay in guc.c

included by everything that includes bufmgr.h --- it's supposed to be
internals, after all, not part of the API!  This fixes the conflict
against FreeBSD headers reported by Rosenman, by making it unnecessary
for s_lock.h to be included by plperl.c.

   SetConfigOption(name, value,
        (IsUnderPostmaster) ? PGC_BACKEND : PGC_POSTMASTER);

postmaster, because it isn't updated after forking away from the terminal.
Apparently it's not used anyplace in the postmaster ... but seems best
to make it show the correct PID ...

socket file, in favor of having an ordinary lockfile beside the socket file.
Clean up a few robustness problems in the lockfile code.  If postmaster is
going to reject a connection request based on database state, it will now
tell you so before authentication exchange not after.  (Of course, a failure
after is still possible if conditions change meanwhile, but this makes life
easier for a yet-to-be-written pg_ping utility.)

information.

for a now-vanished group.  Instead, display the numeric group ID, same
as it does for vanished users.

IPC key assignment will now work correctly even when multiple postmasters
are using same logical port number (which is possible given -k switch).
There is only one shared-mem segment per postmaster now, not 3.
Rip out broken code for non-TAS case in bufmgr and xlog, substitute a
complete S_LOCK emulation using semaphores in spin.c.  TAS and non-TAS
logic is now exactly the same.
When deadlock is detected, "Deadlock detected" is now the elog(ERROR)
message, rather than a NOTICE that comes out before an unhelpful ERROR.

key exist).

awn@bcs.zp.ua

Made pg_lo_read and pg_lo_write binary data safe when libpgtcl
is compiled against Tcl version 8.0 or higher.


Jan

to die.

pg_ctl should invoke it from there, not use whatever random psql might
(or might not) live in its $PATH.

Avoid infinite loop prompting for password at stdin EOF.

little patch which correct that.

    thanks

                cyril

space as separator again.

types.

```-----------------------------------------------
Subject: Bug in unicode conversion ...
From: Jan Varga <varga@utcru.sk>
To: t-ishii@sra.co.jp
Date: Sat, 18 Nov 2000 17:41:20 +0100 (CET)


Hi,

I tried this new feature in PostgreSQL. I found one bug.
Script UCS_to_8859.pl skips input lines which
1. code <0x80 or
2. ucs <0x100

I think second one is not good idea because some codes in ISO8859-2
have ucs <0x100 (e.g. 0xE9 - 0x00E9)
```

-----------------------------------------------

for any other purpose than PGLC_localeconv()'s internal save/restore of
locale settings.  Fix cash.c to call PGLC_localeconv() rather than
making a direct call to localeconv() --- the old way, if PGLC_localeconv()
had already cached a locale result, it would be overwritten by the first
cash_in or cash_out operation, leading to wrong-locale results later.
Probably no demonstrable bug today, since we only appear to be looking
at the LC_MONETARY results which should be the same anyway, but definitely
a gotcha waiting to strike.

sure that broadcast('foo/32') means anything, but if it does, surely
it ought to return foo, not 255.255.255.255.

shifting by the word width is not defined by ANSI C...

re-adopt these settings at every postmaster or standalone-backend startup.
This should fix problems with indexes becoming corrupt due to failure to
provide consistent locale environment for postmaster at all times.  Also,
refuse to start up a non-locale-enabled compilation in a database originally
initdb'd with a non-C locale.  Suppress LIKE index optimization if locale
is not "C" or "POSIX" (are there any other locales where it's safe?).
Issue NOTICE during initdb if selected locale disables LIKE optimization.

other standalone-backend situations) are not duplicated.  Remove some
dead code, add some comments, too.

Accept --help even if no general long options support exists.

with current postmaster.