1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* main.c
|
2000-11-25 04:45:47 +01:00
|
|
|
* Stub main() routine for the postgres executable.
|
|
|
|
*
|
|
|
|
* This does some essential startup tasks for any incarnation of postgres
|
2010-12-16 23:57:57 +01:00
|
|
|
* (postmaster, standalone backend, standalone bootstrap process, or a
|
|
|
|
* separately exec'd child of a postmaster) and then dispatches to the
|
|
|
|
* proper FooMain() routine for the incarnation.
|
2000-11-25 04:45:47 +01:00
|
|
|
*
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2020-01-01 18:21:45 +01:00
|
|
|
* Portions Copyright (c) 1996-2020, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/main/main.c
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
2000-09-06 16:15:31 +02:00
|
|
|
#include "postgres.h"
|
|
|
|
|
1996-11-14 21:49:09 +01:00
|
|
|
#include <unistd.h>
|
1997-04-12 11:37:31 +02:00
|
|
|
|
2000-12-31 04:34:01 +01:00
|
|
|
#if defined(__NetBSD__)
|
|
|
|
#include <sys/param.h>
|
|
|
|
#endif
|
1999-07-17 22:18:55 +02:00
|
|
|
|
2016-03-10 13:48:58 +01:00
|
|
|
#if defined(_M_AMD64) && _MSC_VER == 1800
|
|
|
|
#include <math.h>
|
|
|
|
#include <versionhelpers.h>
|
|
|
|
#endif
|
|
|
|
|
1999-07-16 05:14:30 +02:00
|
|
|
#include "bootstrap/bootstrap.h"
|
2014-01-11 00:03:28 +01:00
|
|
|
#include "common/username.h"
|
2016-11-23 01:57:45 +01:00
|
|
|
#include "port/atomics.h"
|
2004-05-30 00:48:23 +02:00
|
|
|
#include "postmaster/postmaster.h"
|
Add a basic atomic ops API abstracting away platform/architecture details.
Several upcoming performance/scalability improvements require atomic
operations. This new API avoids the need to splatter compiler and
architecture dependent code over all the locations employing atomic
ops.
For several of the potential usages it'd be problematic to maintain
both, a atomics using implementation and one using spinlocks or
similar. In all likelihood one of the implementations would not get
tested regularly under concurrency. To avoid that scenario the new API
provides a automatic fallback of atomic operations to spinlocks. All
properties of atomic operations are maintained. This fallback -
obviously - isn't as fast as just using atomic ops, but it's not bad
either. For one of the future users the atomics ontop spinlocks
implementation was actually slightly faster than the old purely
spinlock using implementation. That's important because it reduces the
fear of regressing older platforms when improving the scalability for
new ones.
The API, loosely modeled after the C11 atomics support, currently
provides 'atomic flags' and 32 bit unsigned integers. If the platform
efficiently supports atomic 64 bit unsigned integers those are also
provided.
To implement atomics support for a platform/architecture/compiler for
a type of atomics 32bit compare and exchange needs to be
implemented. If available and more efficient native support for flags,
32 bit atomic addition, and corresponding 64 bit operations may also
be provided. Additional useful atomic operations are implemented
generically ontop of these.
The implementation for various versions of gcc, msvc and sun studio have
been tested. Additional existing stub implementations for
* Intel icc
* HUPX acc
* IBM xlc
are included but have never been tested. These will likely require
fixes based on buildfarm and user feedback.
As atomic operations also require barriers for some operations the
existing barrier support has been moved into the atomics code.
Author: Andres Freund with contributions from Oskari Saarenmaa
Reviewed-By: Amit Kapila, Robert Haas, Heikki Linnakangas and Álvaro Herrera
Discussion: CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com,
20131015123303.GH5300@awork2.anarazel.de,
20131028205522.GI20248@awork2.anarazel.de
2014-09-25 23:49:05 +02:00
|
|
|
#include "storage/s_lock.h"
|
2014-05-18 00:29:46 +02:00
|
|
|
#include "storage/spin.h"
|
1999-07-16 05:14:30 +02:00
|
|
|
#include "tcop/tcopprot.h"
|
2003-07-04 18:41:22 +02:00
|
|
|
#include "utils/help_config.h"
|
2014-01-11 22:35:26 +01:00
|
|
|
#include "utils/memutils.h"
|
2005-12-29 00:22:51 +01:00
|
|
|
#include "utils/pg_locale.h"
|
2001-10-21 05:25:36 +02:00
|
|
|
#include "utils/ps_status.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2006-06-18 17:38:37 +02:00
|
|
|
|
2006-02-01 01:31:59 +01:00
|
|
|
const char *progname;
|
1996-11-14 21:49:09 +01:00
|
|
|
|
2000-11-25 04:45:47 +01:00
|
|
|
|
2006-06-18 17:38:37 +02:00
|
|
|
static void startup_hacks(const char *progname);
|
2015-06-09 19:37:08 +02:00
|
|
|
static void init_locale(const char *categoryname, int category, const char *locale);
|
2006-06-18 17:38:37 +02:00
|
|
|
static void help(const char *progname);
|
|
|
|
static void check_root(const char *progname);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1998-02-03 02:25:47 +01:00
|
|
|
|
2010-12-16 23:57:57 +01:00
|
|
|
/*
|
|
|
|
* Any Postgres server process begins execution here.
|
|
|
|
*/
|
2006-06-18 17:38:37 +02:00
|
|
|
int
|
|
|
|
main(int argc, char *argv[])
|
|
|
|
{
|
Allow "-C variable" and "--describe-config" even to root users.
There's no really compelling reason to refuse to do these read-only,
non-server-starting options as root, and there's at least one good
reason to allow -C: pg_ctl uses -C to find out the true data directory
location when pointed at a config-only directory. On Windows, this is
done before dropping administrator privileges, which means that pg_ctl
fails for administrators if and only if a config-only layout is used.
Since the root-privilege check is done so early in startup, it's a bit
awkward to check for these switches. Make the somewhat arbitrary
decision that we'll only skip the root check if -C is the first switch.
This is not just to make the code a bit simpler: it also guarantees that
we can't misinterpret a --boot mode switch. (While AuxiliaryProcessMain
doesn't currently recognize any such switch, it might have one in the
future.) This is no particular problem for pg_ctl, and since the whole
behavior is undocumented anyhow, it's not a documentation issue either.
(--describe-config only works as the first switch anyway, so this is
no restriction for that case either.)
Back-patch to 9.2 where pg_ctl first began to use -C.
MauMau, heavily edited by me
2014-04-05 04:03:35 +02:00
|
|
|
bool do_check_root = true;
|
|
|
|
|
2017-11-12 23:31:00 +01:00
|
|
|
/*
|
|
|
|
* If supported on the current platform, set up a handler to be called if
|
|
|
|
* the backend/postmaster crashes with a fatal signal or exception.
|
|
|
|
*/
|
|
|
|
#if defined(WIN32) && defined(HAVE_MINIDUMP_TYPE)
|
|
|
|
pgwin32_install_crashdump_handler();
|
|
|
|
#endif
|
|
|
|
|
2006-02-01 01:31:59 +01:00
|
|
|
progname = get_progname(argv[0]);
|
|
|
|
|
2004-09-24 08:29:07 +02:00
|
|
|
/*
|
2006-06-18 17:38:37 +02:00
|
|
|
* Platform-specific startup hacks
|
2001-10-21 05:25:36 +02:00
|
|
|
*/
|
2006-06-18 17:38:37 +02:00
|
|
|
startup_hacks(progname);
|
2001-10-21 05:25:36 +02:00
|
|
|
|
2001-10-22 21:41:38 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Remember the physical location of the initially given argv[] array for
|
2014-05-06 18:12:18 +02:00
|
|
|
* possible use by ps display. On some platforms, the argv[] storage must
|
2005-10-15 04:49:52 +02:00
|
|
|
* be overwritten in order to set the process title for ps. In such cases
|
|
|
|
* save_ps_display_args makes and returns a new copy of the argv[] array.
|
2001-10-22 21:41:38 +02:00
|
|
|
*
|
2005-11-22 19:17:34 +01:00
|
|
|
* save_ps_display_args may also move the environment strings to make
|
|
|
|
* extra room. Therefore this should be done as early as possible during
|
2005-10-15 04:49:52 +02:00
|
|
|
* startup, to avoid entanglements with code that might save a getenv()
|
|
|
|
* result pointer.
|
2001-10-22 21:41:38 +02:00
|
|
|
*/
|
2004-02-22 22:26:55 +01:00
|
|
|
argv = save_ps_display_args(argc, argv);
|
2001-10-22 21:41:38 +02:00
|
|
|
|
2014-01-11 22:35:26 +01:00
|
|
|
/*
|
|
|
|
* Fire up essential subsystems: error and memory management
|
|
|
|
*
|
|
|
|
* Code after this point is allowed to use elog/ereport, though
|
|
|
|
* localization of messages may not work right away, and messages won't go
|
|
|
|
* anywhere but stderr until GUC settings get loaded.
|
|
|
|
*/
|
|
|
|
MemoryContextInit();
|
|
|
|
|
2002-04-03 07:39:33 +02:00
|
|
|
/*
|
2019-08-14 06:50:47 +02:00
|
|
|
* Set up locale information
|
2002-04-03 07:39:33 +02:00
|
|
|
*/
|
2008-12-11 08:34:09 +01:00
|
|
|
set_pglocale_pgservice(argv[0], PG_TEXTDOMAIN("postgres"));
|
2004-05-25 03:00:30 +02:00
|
|
|
|
2004-05-27 17:07:41 +02:00
|
|
|
/*
|
2019-08-14 06:50:47 +02:00
|
|
|
* In the postmaster, absorb the environment values for LC_COLLATE and
|
|
|
|
* LC_CTYPE. Individual backends will change these later to settings
|
|
|
|
* taken from pg_database, but the postmaster cannot do that. If we leave
|
|
|
|
* these set to "C" then message localization might not work well in the
|
|
|
|
* postmaster.
|
2004-03-15 17:14:26 +01:00
|
|
|
*/
|
2015-06-09 19:37:08 +02:00
|
|
|
init_locale("LC_COLLATE", LC_COLLATE, "");
|
|
|
|
init_locale("LC_CTYPE", LC_CTYPE, "");
|
2004-03-15 17:14:26 +01:00
|
|
|
|
2019-08-14 06:50:47 +02:00
|
|
|
/*
|
|
|
|
* LC_MESSAGES will get set later during GUC option processing, but we set
|
|
|
|
* it here to allow startup error messages to be localized.
|
|
|
|
*/
|
2001-06-02 20:25:18 +02:00
|
|
|
#ifdef LC_MESSAGES
|
2015-06-09 19:37:08 +02:00
|
|
|
init_locale("LC_MESSAGES", LC_MESSAGES, "");
|
2001-06-02 20:25:18 +02:00
|
|
|
#endif
|
2002-09-04 22:31:48 +02:00
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* We keep these set to "C" always, except transiently in pg_locale.c; see
|
|
|
|
* that file for explanations.
|
2002-09-04 22:31:48 +02:00
|
|
|
*/
|
2015-06-09 19:37:08 +02:00
|
|
|
init_locale("LC_MONETARY", LC_MONETARY, "C");
|
|
|
|
init_locale("LC_NUMERIC", LC_NUMERIC, "C");
|
|
|
|
init_locale("LC_TIME", LC_TIME, "C");
|
2005-12-29 00:22:51 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Now that we have absorbed as much as we wish to from the locale
|
|
|
|
* environment, remove any LC_ALL setting, so that the environment
|
|
|
|
* variables installed by pg_perm_setlocale have force.
|
|
|
|
*/
|
|
|
|
unsetenv("LC_ALL");
|
2002-04-03 07:39:33 +02:00
|
|
|
|
2015-07-09 02:44:21 +02:00
|
|
|
check_strxfrm_bug();
|
|
|
|
|
2000-11-25 04:45:47 +01:00
|
|
|
/*
|
Allow "-C variable" and "--describe-config" even to root users.
There's no really compelling reason to refuse to do these read-only,
non-server-starting options as root, and there's at least one good
reason to allow -C: pg_ctl uses -C to find out the true data directory
location when pointed at a config-only directory. On Windows, this is
done before dropping administrator privileges, which means that pg_ctl
fails for administrators if and only if a config-only layout is used.
Since the root-privilege check is done so early in startup, it's a bit
awkward to check for these switches. Make the somewhat arbitrary
decision that we'll only skip the root check if -C is the first switch.
This is not just to make the code a bit simpler: it also guarantees that
we can't misinterpret a --boot mode switch. (While AuxiliaryProcessMain
doesn't currently recognize any such switch, it might have one in the
future.) This is no particular problem for pg_ctl, and since the whole
behavior is undocumented anyhow, it's not a documentation issue either.
(--describe-config only works as the first switch anyway, so this is
no restriction for that case either.)
Back-patch to 9.2 where pg_ctl first began to use -C.
MauMau, heavily edited by me
2014-04-05 04:03:35 +02:00
|
|
|
* Catch standard options before doing much else, in particular before we
|
|
|
|
* insist on not being root.
|
2001-03-22 05:01:46 +01:00
|
|
|
*/
|
2006-06-18 17:38:37 +02:00
|
|
|
if (argc > 1)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2006-06-18 17:38:37 +02:00
|
|
|
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
|
2001-04-21 20:29:29 +02:00
|
|
|
{
|
2006-06-18 17:38:37 +02:00
|
|
|
help(progname);
|
|
|
|
exit(0);
|
2004-06-24 23:03:42 +02:00
|
|
|
}
|
2006-06-18 17:38:37 +02:00
|
|
|
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
|
2004-06-24 23:03:42 +02:00
|
|
|
{
|
Change pg_ctl to detect server-ready by watching status in postmaster.pid.
Traditionally, "pg_ctl start -w" has waited for the server to become
ready to accept connections by attempting a connection once per second.
That has the major problem that connection issues (for instance, a
kernel packet filter blocking traffic) can't be reliably told apart
from server startup issues, and the minor problem that if server startup
isn't quick, we accumulate "the database system is starting up" spam
in the server log. We've hacked around many of the possible connection
issues, but it resulted in ugly and complicated code in pg_ctl.c.
In commit c61559ec3, I changed the probe rate to every tenth of a second.
That prompted Jeff Janes to complain that the log-spam problem had become
much worse. In the ensuing discussion, Andres Freund pointed out that
we could dispense with connection attempts altogether if the postmaster
were changed to report its status in postmaster.pid, which "pg_ctl start"
already relies on being able to read. This patch implements that, teaching
postmaster.c to report a status string into the pidfile at the same
state-change points already identified as being of interest for systemd
status reporting (cf commit 7d17e683f). pg_ctl no longer needs to link
with libpq at all; all its functions now depend on reading server files.
In support of this, teach AddToDataDirLockFile() to allow addition of
postmaster.pid lines in not-necessarily-sequential order. This is needed
on Windows where the SHMEM_KEY line will never be written at all. We still
have the restriction that we don't want to truncate the pidfile; document
the reasons for that a bit better.
Also, fix the pg_ctl TAP tests so they'll notice if "start -w" mode
is broken --- before, they'd just wait out the sixty seconds until
the loop gives up, and then report success anyway. (Yes, I found that
out the hard way.)
While at it, arrange for pg_ctl to not need to #include miscadmin.h;
as a rather low-level backend header, requiring that to be compilable
client-side is pretty dubious. This requires moving the #define's
associated with the pidfile into a new header file, and moving
PG_BACKEND_VERSIONSTR someplace else. For lack of a clearly better
"someplace else", I put it into port.h, beside the declaration of
find_other_exec(), since most users of that macro are passing the value to
find_other_exec(). (initdb still depends on miscadmin.h, but at least
pg_ctl and pg_upgrade no longer do.)
In passing, fix main.c so that PG_BACKEND_VERSIONSTR actually defines the
output of "postgres -V", which remarkably it had never done before.
Discussion: https://postgr.es/m/CAMkU=1xJW8e+CTotojOMBd-yzUvD0e_JZu2xHo=MnuZ4__m7Pg@mail.gmail.com
2017-06-28 23:31:24 +02:00
|
|
|
fputs(PG_BACKEND_VERSIONSTR, stdout);
|
2006-06-18 17:38:37 +02:00
|
|
|
exit(0);
|
2001-04-21 20:29:29 +02:00
|
|
|
}
|
Allow "-C variable" and "--describe-config" even to root users.
There's no really compelling reason to refuse to do these read-only,
non-server-starting options as root, and there's at least one good
reason to allow -C: pg_ctl uses -C to find out the true data directory
location when pointed at a config-only directory. On Windows, this is
done before dropping administrator privileges, which means that pg_ctl
fails for administrators if and only if a config-only layout is used.
Since the root-privilege check is done so early in startup, it's a bit
awkward to check for these switches. Make the somewhat arbitrary
decision that we'll only skip the root check if -C is the first switch.
This is not just to make the code a bit simpler: it also guarantees that
we can't misinterpret a --boot mode switch. (While AuxiliaryProcessMain
doesn't currently recognize any such switch, it might have one in the
future.) This is no particular problem for pg_ctl, and since the whole
behavior is undocumented anyhow, it's not a documentation issue either.
(--describe-config only works as the first switch anyway, so this is
no restriction for that case either.)
Back-patch to 9.2 where pg_ctl first began to use -C.
MauMau, heavily edited by me
2014-04-05 04:03:35 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* In addition to the above, we allow "--describe-config" and "-C var"
|
|
|
|
* to be called by root. This is reasonably safe since these are
|
|
|
|
* read-only activities. The -C case is important because pg_ctl may
|
|
|
|
* try to invoke it while still holding administrator privileges on
|
|
|
|
* Windows. Note that while -C can normally be in any argv position,
|
2016-06-03 16:13:36 +02:00
|
|
|
* if you want to bypass the root check you must put it first. This
|
Allow "-C variable" and "--describe-config" even to root users.
There's no really compelling reason to refuse to do these read-only,
non-server-starting options as root, and there's at least one good
reason to allow -C: pg_ctl uses -C to find out the true data directory
location when pointed at a config-only directory. On Windows, this is
done before dropping administrator privileges, which means that pg_ctl
fails for administrators if and only if a config-only layout is used.
Since the root-privilege check is done so early in startup, it's a bit
awkward to check for these switches. Make the somewhat arbitrary
decision that we'll only skip the root check if -C is the first switch.
This is not just to make the code a bit simpler: it also guarantees that
we can't misinterpret a --boot mode switch. (While AuxiliaryProcessMain
doesn't currently recognize any such switch, it might have one in the
future.) This is no particular problem for pg_ctl, and since the whole
behavior is undocumented anyhow, it's not a documentation issue either.
(--describe-config only works as the first switch anyway, so this is
no restriction for that case either.)
Back-patch to 9.2 where pg_ctl first began to use -C.
MauMau, heavily edited by me
2014-04-05 04:03:35 +02:00
|
|
|
* reduces the risk that we might misinterpret some other mode's -C
|
|
|
|
* switch as being the postmaster/postgres one.
|
|
|
|
*/
|
|
|
|
if (strcmp(argv[1], "--describe-config") == 0)
|
|
|
|
do_check_root = false;
|
|
|
|
else if (argc > 2 && strcmp(argv[1], "-C") == 0)
|
|
|
|
do_check_root = false;
|
2001-04-21 20:29:29 +02:00
|
|
|
}
|
|
|
|
|
2000-11-25 04:45:47 +01:00
|
|
|
/*
|
Allow "-C variable" and "--describe-config" even to root users.
There's no really compelling reason to refuse to do these read-only,
non-server-starting options as root, and there's at least one good
reason to allow -C: pg_ctl uses -C to find out the true data directory
location when pointed at a config-only directory. On Windows, this is
done before dropping administrator privileges, which means that pg_ctl
fails for administrators if and only if a config-only layout is used.
Since the root-privilege check is done so early in startup, it's a bit
awkward to check for these switches. Make the somewhat arbitrary
decision that we'll only skip the root check if -C is the first switch.
This is not just to make the code a bit simpler: it also guarantees that
we can't misinterpret a --boot mode switch. (While AuxiliaryProcessMain
doesn't currently recognize any such switch, it might have one in the
future.) This is no particular problem for pg_ctl, and since the whole
behavior is undocumented anyhow, it's not a documentation issue either.
(--describe-config only works as the first switch anyway, so this is
no restriction for that case either.)
Back-patch to 9.2 where pg_ctl first began to use -C.
MauMau, heavily edited by me
2014-04-05 04:03:35 +02:00
|
|
|
* Make sure we are not running as root, unless it's safe for the selected
|
|
|
|
* option.
|
2000-11-25 04:45:47 +01:00
|
|
|
*/
|
Allow "-C variable" and "--describe-config" even to root users.
There's no really compelling reason to refuse to do these read-only,
non-server-starting options as root, and there's at least one good
reason to allow -C: pg_ctl uses -C to find out the true data directory
location when pointed at a config-only directory. On Windows, this is
done before dropping administrator privileges, which means that pg_ctl
fails for administrators if and only if a config-only layout is used.
Since the root-privilege check is done so early in startup, it's a bit
awkward to check for these switches. Make the somewhat arbitrary
decision that we'll only skip the root check if -C is the first switch.
This is not just to make the code a bit simpler: it also guarantees that
we can't misinterpret a --boot mode switch. (While AuxiliaryProcessMain
doesn't currently recognize any such switch, it might have one in the
future.) This is no particular problem for pg_ctl, and since the whole
behavior is undocumented anyhow, it's not a documentation issue either.
(--describe-config only works as the first switch anyway, so this is
no restriction for that case either.)
Back-patch to 9.2 where pg_ctl first began to use -C.
MauMau, heavily edited by me
2014-04-05 04:03:35 +02:00
|
|
|
if (do_check_root)
|
|
|
|
check_root(progname);
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/*
|
2006-10-04 02:30:14 +02:00
|
|
|
* Dispatch to one of various subprograms depending on first argument.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2006-06-18 17:38:37 +02:00
|
|
|
|
2003-12-25 04:52:51 +01:00
|
|
|
#ifdef EXEC_BACKEND
|
2006-06-18 17:38:37 +02:00
|
|
|
if (argc > 1 && strncmp(argv[1], "--fork", 6) == 0)
|
2013-05-29 22:58:43 +02:00
|
|
|
SubPostmasterMain(argc, argv); /* does not return */
|
2004-05-28 07:13:32 +02:00
|
|
|
#endif
|
2004-05-27 17:07:41 +02:00
|
|
|
|
2004-11-17 01:14:14 +01:00
|
|
|
#ifdef WIN32
|
2014-05-06 18:12:18 +02:00
|
|
|
|
2004-11-17 01:14:14 +01:00
|
|
|
/*
|
|
|
|
* Start our win32 signal implementation
|
|
|
|
*
|
2005-11-22 19:17:34 +01:00
|
|
|
* SubPostmasterMain() will do this for itself, but the remaining modes
|
|
|
|
* need it here
|
2004-11-17 01:14:14 +01:00
|
|
|
*/
|
|
|
|
pgwin32_signal_initialize();
|
|
|
|
#endif
|
|
|
|
|
2006-06-18 17:38:37 +02:00
|
|
|
if (argc > 1 && strcmp(argv[1], "--boot") == 0)
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
AuxiliaryProcessMain(argc, argv); /* does not return */
|
2012-06-25 20:25:26 +02:00
|
|
|
else if (argc > 1 && strcmp(argv[1], "--describe-config") == 0)
|
|
|
|
GucInfoMain(); /* does not return */
|
|
|
|
else if (argc > 1 && strcmp(argv[1], "--single") == 0)
|
2013-04-01 20:00:51 +02:00
|
|
|
PostgresMain(argc, argv,
|
|
|
|
NULL, /* no dbname */
|
2013-12-18 18:16:16 +01:00
|
|
|
strdup(get_user_name_or_exit(progname))); /* does not return */
|
2012-06-25 20:25:26 +02:00
|
|
|
else
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
PostmasterMain(argc, argv); /* does not return */
|
2013-05-29 22:58:43 +02:00
|
|
|
abort(); /* should not get here */
|
2006-06-18 17:38:37 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
2014-05-06 18:12:18 +02:00
|
|
|
* Place platform-specific startup hacks here. This is the right
|
2010-12-16 23:57:57 +01:00
|
|
|
* place to put code that must be executed early in the launch of any new
|
2014-05-06 18:12:18 +02:00
|
|
|
* server process. Note that this code will NOT be executed when a backend
|
2010-12-16 23:57:57 +01:00
|
|
|
* or sub-bootstrap process is forked, unless we are in a fork/exec
|
|
|
|
* environment (ie EXEC_BACKEND is defined).
|
2006-06-18 17:38:37 +02:00
|
|
|
*
|
|
|
|
* XXX The need for code here is proof that the platform in question
|
|
|
|
* is too brain-dead to provide a standard C execution environment
|
|
|
|
* without help. Avoid adding more here, if you can.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
startup_hacks(const char *progname)
|
|
|
|
{
|
2010-12-16 23:57:57 +01:00
|
|
|
/*
|
|
|
|
* Windows-specific execution environment hacking.
|
|
|
|
*/
|
2006-06-18 17:38:37 +02:00
|
|
|
#ifdef WIN32
|
|
|
|
{
|
|
|
|
WSADATA wsaData;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
/* Make output streams unbuffered by default */
|
|
|
|
setvbuf(stdout, NULL, _IONBF, 0);
|
|
|
|
setvbuf(stderr, NULL, _IONBF, 0);
|
|
|
|
|
|
|
|
/* Prepare Winsock */
|
|
|
|
err = WSAStartup(MAKEWORD(2, 2), &wsaData);
|
|
|
|
if (err != 0)
|
|
|
|
{
|
|
|
|
write_stderr("%s: WSAStartup failed: %d\n",
|
|
|
|
progname, err);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* In case of general protection fault, don't show GUI popup box */
|
2006-10-04 02:30:14 +02:00
|
|
|
SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
|
2016-03-10 13:48:58 +01:00
|
|
|
|
|
|
|
#if defined(_M_AMD64) && _MSC_VER == 1800
|
2016-06-10 00:02:36 +02:00
|
|
|
|
2016-06-10 00:09:17 +02:00
|
|
|
/*----------
|
2016-06-10 00:02:36 +02:00
|
|
|
* Avoid crashing in certain floating-point operations if we were
|
|
|
|
* compiled for x64 with MS Visual Studio 2013 and are running on
|
|
|
|
* Windows prior to 7/2008R2 SP1 on an AVX2-capable CPU.
|
2016-03-10 13:48:58 +01:00
|
|
|
*
|
2016-06-10 00:09:17 +02:00
|
|
|
* Ref: https://connect.microsoft.com/VisualStudio/feedback/details/811093/visual-studio-2013-rtm-c-x64-code-generation-bug-for-avx2-instructions
|
|
|
|
*----------
|
2016-03-10 13:48:58 +01:00
|
|
|
*/
|
|
|
|
if (!IsWindows7SP1OrGreater())
|
|
|
|
{
|
|
|
|
_set_FMA3_enable(0);
|
|
|
|
}
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* defined(_M_AMD64) && _MSC_VER == 1800 */
|
2016-03-10 13:48:58 +01:00
|
|
|
|
2006-06-18 17:38:37 +02:00
|
|
|
}
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* WIN32 */
|
2014-05-18 00:29:46 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize dummy_spinlock, in case we are on a platform where we have
|
|
|
|
* to use the fallback implementation of pg_memory_barrier().
|
|
|
|
*/
|
|
|
|
SpinLockInit(&dummy_spinlock);
|
2006-06-18 17:38:37 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2015-01-08 04:34:57 +01:00
|
|
|
/*
|
|
|
|
* Make the initial permanent setting for a locale category. If that fails,
|
|
|
|
* perhaps due to LC_foo=invalid in the environment, use locale C. If even
|
|
|
|
* that fails, perhaps due to out-of-memory, the entire startup fails with it.
|
|
|
|
* When this returns, we are guaranteed to have a setting for the given
|
|
|
|
* category's environment variable.
|
|
|
|
*/
|
|
|
|
static void
|
2015-06-09 19:37:08 +02:00
|
|
|
init_locale(const char *categoryname, int category, const char *locale)
|
2015-01-08 04:34:57 +01:00
|
|
|
{
|
|
|
|
if (pg_perm_setlocale(category, locale) == NULL &&
|
|
|
|
pg_perm_setlocale(category, "C") == NULL)
|
2015-06-09 19:37:08 +02:00
|
|
|
elog(FATAL, "could not adopt \"%s\" locale nor C locale for %s",
|
|
|
|
locale, categoryname);
|
2015-01-08 04:34:57 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-01-04 01:57:51 +01:00
|
|
|
/*
|
|
|
|
* Help display should match the options accepted by PostmasterMain()
|
|
|
|
* and PostgresMain().
|
Renovate display of non-ASCII messages on Windows.
GNU gettext selects a default encoding for the messages it emits in a
platform-specific manner; it uses the Windows ANSI code page on Windows
and follows LC_CTYPE on other platforms. This is inconvenient for
PostgreSQL server processes, so realize consistent cross-platform
behavior by calling bind_textdomain_codeset() on Windows each time we
permanently change LC_CTYPE. This primarily affects SQL_ASCII databases
and processes like the postmaster that do not attach to a database,
making their behavior consistent with PostgreSQL on non-Windows
platforms. Messages from SQL_ASCII databases use the encoding implied
by the database LC_CTYPE, and messages from non-database processes use
LC_CTYPE from the postmaster system environment. PlatformEncoding
becomes unused, so remove it.
Make write_console() prefer WriteConsoleW() to write() regardless of the
encodings in use. In this situation, write() will invariably mishandle
non-ASCII characters.
elog.c has assumed that messages conform to the database encoding.
While usually true, this does not hold for SQL_ASCII and MULE_INTERNAL.
Introduce MessageEncoding to track the actual encoding of message text.
The present consumers are Windows-specific code for converting messages
to UTF16 for use in system interfaces. This fixes the appearance in
Windows event logs and consoles of translated messages from SQL_ASCII
processes like the postmaster. Note that SQL_ASCII inherently disclaims
a strong notion of encoding, so non-ASCII byte sequences interpolated
into messages by %s may yet yield a nonsensical message. MULE_INTERNAL
has similar problems at present, albeit for a different reason: its lack
of libiconv support or a conversion to UTF8.
Consequently, one need no longer restart Windows with a different
Windows ANSI code page to broadly test backend logging under a given
language. Changing the user's locale ("Format") is enough. Several
accounts can simultaneously run postmasters under different locales, all
correctly logging localized messages to Windows event logs and consoles.
Alexander Law and Noah Misch
2013-06-26 17:17:33 +02:00
|
|
|
*
|
|
|
|
* XXX On Windows, non-ASCII localizations of these messages only display
|
|
|
|
* correctly if the console output code page covers the necessary characters.
|
|
|
|
* Messages emitted in write_console() do not exhibit this problem.
|
2007-01-04 01:57:51 +01:00
|
|
|
*/
|
2006-06-18 17:38:37 +02:00
|
|
|
static void
|
|
|
|
help(const char *progname)
|
|
|
|
{
|
|
|
|
printf(_("%s is the PostgreSQL server.\n\n"), progname);
|
|
|
|
printf(_("Usage:\n %s [OPTION]...\n\n"), progname);
|
|
|
|
printf(_("Options:\n"));
|
2012-05-18 19:34:14 +02:00
|
|
|
printf(_(" -B NBUFFERS number of shared buffers\n"));
|
|
|
|
printf(_(" -c NAME=VALUE set run-time parameter\n"));
|
2012-06-13 12:41:25 +02:00
|
|
|
printf(_(" -C NAME print value of run-time parameter, then exit\n"));
|
2012-05-18 19:34:14 +02:00
|
|
|
printf(_(" -d 1-5 debugging level\n"));
|
|
|
|
printf(_(" -D DATADIR database directory\n"));
|
|
|
|
printf(_(" -e use European date input format (DMY)\n"));
|
|
|
|
printf(_(" -F turn fsync off\n"));
|
|
|
|
printf(_(" -h HOSTNAME host name or IP address to listen on\n"));
|
|
|
|
printf(_(" -i enable TCP/IP connections\n"));
|
|
|
|
printf(_(" -k DIRECTORY Unix-domain socket location\n"));
|
2006-06-18 17:38:37 +02:00
|
|
|
#ifdef USE_SSL
|
2012-05-18 19:34:14 +02:00
|
|
|
printf(_(" -l enable SSL connections\n"));
|
2006-06-18 17:38:37 +02:00
|
|
|
#endif
|
2012-05-18 19:34:14 +02:00
|
|
|
printf(_(" -N MAX-CONNECT maximum number of allowed connections\n"));
|
|
|
|
printf(_(" -o OPTIONS pass \"OPTIONS\" to each server process (obsolete)\n"));
|
|
|
|
printf(_(" -p PORT port number to listen on\n"));
|
|
|
|
printf(_(" -s show statistics after each query\n"));
|
|
|
|
printf(_(" -S WORK-MEM set amount of memory for sorts (in kB)\n"));
|
2012-06-18 01:44:00 +02:00
|
|
|
printf(_(" -V, --version output version information, then exit\n"));
|
2012-05-18 19:34:14 +02:00
|
|
|
printf(_(" --NAME=VALUE set run-time parameter\n"));
|
2006-06-18 17:38:37 +02:00
|
|
|
printf(_(" --describe-config describe configuration parameters, then exit\n"));
|
2012-06-18 01:44:00 +02:00
|
|
|
printf(_(" -?, --help show this help, then exit\n"));
|
2006-06-18 17:38:37 +02:00
|
|
|
|
|
|
|
printf(_("\nDeveloper options:\n"));
|
2012-05-18 19:34:14 +02:00
|
|
|
printf(_(" -f s|i|n|m|h forbid use of some plan types\n"));
|
|
|
|
printf(_(" -n do not reinitialize shared memory after abnormal exit\n"));
|
|
|
|
printf(_(" -O allow system table structure changes\n"));
|
|
|
|
printf(_(" -P disable system indexes\n"));
|
|
|
|
printf(_(" -t pa|pl|ex show timings after each query\n"));
|
|
|
|
printf(_(" -T send SIGSTOP to all backend processes if one dies\n"));
|
|
|
|
printf(_(" -W NUM wait NUM seconds to allow attach from a debugger\n"));
|
2006-06-18 17:38:37 +02:00
|
|
|
|
|
|
|
printf(_("\nOptions for single-user mode:\n"));
|
2012-05-18 19:34:14 +02:00
|
|
|
printf(_(" --single selects single-user mode (must be first argument)\n"));
|
|
|
|
printf(_(" DBNAME database name (defaults to user name)\n"));
|
|
|
|
printf(_(" -d 0-5 override debugging level\n"));
|
|
|
|
printf(_(" -E echo statement before execution\n"));
|
|
|
|
printf(_(" -j do not use newline as interactive query delimiter\n"));
|
|
|
|
printf(_(" -r FILENAME send stdout and stderr to given file\n"));
|
2006-06-18 17:38:37 +02:00
|
|
|
|
|
|
|
printf(_("\nOptions for bootstrapping mode:\n"));
|
2012-05-18 19:34:14 +02:00
|
|
|
printf(_(" --boot selects bootstrapping mode (must be first argument)\n"));
|
|
|
|
printf(_(" DBNAME database name (mandatory argument in bootstrapping mode)\n"));
|
|
|
|
printf(_(" -r FILENAME send stdout and stderr to given file\n"));
|
|
|
|
printf(_(" -x NUM internal use\n"));
|
2006-06-18 17:38:37 +02:00
|
|
|
|
|
|
|
printf(_("\nPlease read the documentation for the complete list of run-time\n"
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
"configuration settings and how to set them on the command line or in\n"
|
2006-06-18 17:38:37 +02:00
|
|
|
"the configuration file.\n\n"
|
2020-02-28 08:54:49 +01:00
|
|
|
"Report bugs to <%s>.\n"), PACKAGE_BUGREPORT);
|
2020-02-28 08:54:49 +01:00
|
|
|
printf(_("%s home page: <%s>\n"), PACKAGE_NAME, PACKAGE_URL);
|
2006-06-18 17:38:37 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
check_root(const char *progname)
|
|
|
|
{
|
|
|
|
#ifndef WIN32
|
|
|
|
if (geteuid() == 0)
|
|
|
|
{
|
|
|
|
write_stderr("\"root\" execution of the PostgreSQL server is not permitted.\n"
|
|
|
|
"The server must be started under an unprivileged user ID to prevent\n"
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
"possible system security compromise. See the documentation for\n"
|
|
|
|
"more information on how to properly start the server.\n");
|
2006-06-18 17:38:37 +02:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2000-11-25 04:45:47 +01:00
|
|
|
/*
|
2006-10-04 02:30:14 +02:00
|
|
|
* Also make sure that real and effective uids are the same. Executing as
|
|
|
|
* a setuid program from a root shell is a security hole, since on many
|
|
|
|
* platforms a nefarious subroutine could setuid back to root if real uid
|
|
|
|
* is root. (Since nobody actually uses postgres as a setuid program,
|
|
|
|
* trying to actively fix this situation seems more trouble than it's
|
|
|
|
* worth; we'll just expend the effort to check for it.)
|
2000-11-25 04:45:47 +01:00
|
|
|
*/
|
2006-06-18 17:38:37 +02:00
|
|
|
if (getuid() != geteuid())
|
|
|
|
{
|
|
|
|
write_stderr("%s: real and effective user IDs must match\n",
|
|
|
|
progname);
|
|
|
|
exit(1);
|
|
|
|
}
|
2006-10-04 02:30:14 +02:00
|
|
|
#else /* WIN32 */
|
2006-06-18 17:38:37 +02:00
|
|
|
if (pgwin32_is_admin())
|
|
|
|
{
|
|
|
|
write_stderr("Execution of PostgreSQL by a user with administrative permissions is not\n"
|
|
|
|
"permitted.\n"
|
|
|
|
"The server must be started under an unprivileged user ID to prevent\n"
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
"possible system security compromises. See the documentation for\n"
|
|
|
|
"more information on how to properly start the server.\n");
|
2006-06-18 17:38:37 +02:00
|
|
|
exit(1);
|
|
|
|
}
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* WIN32 */
|
2006-06-18 17:38:37 +02:00
|
|
|
}
|