Making PQrequestCancel safe to call in a signal handler turned out to be
much easier than I feared. So here are the diffs.
Some notes:
* I modified the postmaster's packet "iodone" callback interface to allow
the callback routine to return a continue-or-drop-connection return
code; this was necessary to allow the connection to be closed after
receiving a Cancel, rather than proceeding to launch a new backend...
Being a neatnik, I also made the iodone proc have a typechecked
parameter list.
* I deleted all code I could find that had to do with OOB.
* I made some edits to ensure that all signals mentioned in the code
are referred to symbolically not by numbers ("SIGUSR2" not "2").
I think Bruce may have already done at least some of the same edits;
I hope that merging these patches is not too painful.
Subject: [HACKERS] More patches for date/time
I have accumulated several patches to add functionality to the datetime
and timespan data types as well as to fix reported porting bugs on non-BSD
machines. These patches are:
dt.c.patch - add datetime_part(), fix bugs
dt.h.patch - add quarter and timezone support, add prototypes
globals.c.patch - add time and timezone variables
miscadmin.h.patch - add time and timezone variables
nabstime.c.patch - add datetime conversion routine
nabstime.h.patch - add prototypes
pg_operator.h.patch - add datetime operators, clean up formatting
pg_proc.h.patch - add datetime functions, reassign conflicting date OIDs
pg_type.h.patch - add datetime and timespan data types
The dt.c and pg_proc.h patches are fairly large; the latter mostly because I tried
to get some columns for existing entries to line up.
of common routines in pqcomprim.c (pq communication primitives).
Not all adapted to it yet, but it's a start.
- Rewritten some of those routines, to write/read bigger chunks of
data, precomputing stuff in buffers instead of sending out byte
by byte.
- As a consequence, I need to know the endianness of the machine.
Currently I rely on getting it from machine/endian.h, but this
may not be available everywhere? (Who the hell thought it was
a good idea to pass integers to the backend the other way around
than the normal network byte order? *argl*)
- Libpq looks in the environment for magic variables, and upon
establishing a connection to the backend, sends it queries
of the form "SET var_name TO 'var_value'". This needs a change
in the backend parser (Mr. Parser, are you there? :)
- Currently it looks for two Env-Vars, namely PG_DATEFORMAT
and PG_FLOATFORMAT. What else makes sense? PG_TIMEFORMAT?
PG_TIMEZONE?
From: "Martin J. Laubach" <mjl@wwx.vip.at>
In particular, no more compiled-in default for PGDATA or LIBDIR. Commands
that need them need either invocation options or environment variables.
PGPORT default is hardcoded as 5432, but overrideable with options or
environment variables.
I'm able to get through a 'make' of the backend with no errors except
the occasional 'might not be initialized error', which is nothing major,
just annoying.
Have a few patches from D'Arcy to incorporate, but am waiting until I can
get a clean compile first, which I'm hoping to have before bed, or sometime
tomorrow.
Marc G. Fournier
Bruce Momjian
Thomas G. Lockhart
Vadim B. Mikheev
Bryan Henderson