Re: [HACKERS] Patch: Add launchd Support
On Oct 20, 2014, at 5:03 PM, David E. Wheeler da...@justatheory.com wrote: This another reason not to use KeepAlive, I guess. OnDemand is supposed to fire up a job only when it’s needed. No idea what that means. I think the idea of OnDemand is for launchd items to act a bit like inetd does: launchd creates the listening socket (or mach port or file-change notification) on the port specified in the plist, and only starts the process when someone tries to connect to it. This might not be a terrible thing to support, but it would require more changes throughout postgres (postmaster would have to check in with launchd at start time to get the listen socket; ports and socket paths would no longer be specifiable in postgres’ config, etc) and I’m skeptical that it’d be worth the work without a more concrete motivation. Apple has published their changes to Postgres (since they ship it in recent versions of OSX) here, fwiw, including the launchd plist they use: http://www.opensource.apple.com/source/PostgreSQL/ One thing I noticed is that Apple also used the label “org.postgres.postgres” for their launchd job. I don’t know if that will collide in some way with a second job with the same label. Launchctl load/unload takes a pathname, not a job label, so I don’t think it’d be a problem unless you actually do want to run both copies of postgres at the same time. MacPorts also has a launchd job for their postgresql port, which invokes daemondo, which invokes a wrapper script, which invokes postgres. I’m not sure why they did it that way. 2) AFAICS, this .plist file doesn't do anything about launchd's habit of not waiting for the network to come up. Have you experimented with this setting?: keyKeepAlive/key dictkeyNetworkState/keytrue//dict The launchd.plist man page claims that if you set that key in the sub-dictionary: If true, the job will be kept alive as long as the network is up, where up is defined as at least one non-loopback interface being up and having IPv4 or IPv6 addresses assigned to them. If false, the job will be kept alive in the inverse condition. On the other hand, it’s not unreasonable to have postgres running on a machine with only a loopback interface, depending on the use. We might be able to put something in LaunchEvents that gets it to fire when the network launches, but documentation is hella thin (and may only be supported on Yosemite, where there are a bunch of poorly-documented launchd changes). If one were desperate enough... it’s possible to dig through the launchd sources to make up for the gaps in the documentation (also on opensource.apple.com; there used to be a community-ish site for it at macosforge.org as well). It’s rough going, though, IIRC. (3) I don't think you want Disabled = true. It’s the default. When you run `launchctl load -w` it overrides it to false in its database. I’m fine to have it be less opaque, though. Yes, AFAICT it’s conventional to specify Disabled=true in a launchd plist and use launchctl to enable the item. BTW, Mavericks has a comment that /etc/hostconfig is going away, but google isn't telling me what's replacing it… I think that’s been “going away” for a decade now. -- 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] B-Tree support function number 3 (strxfrm() optimization)
On 28 Jul 2014, at 4:57 PM, Peter Geoghegan wrote: [] Then again, who knows? The Mac OS X behavior seems totally arbitrary to me. If I had to guess I'd say it has something to do with their providing an open standard shim to a UTF-16 based proprietary API. A quick glance at OSX's strxfrm() suggests they're using an implementation of strxfrm() from FreeBSD. You can find the source here: http://www.opensource.apple.com/source/Libc/Libc-997.90.3/string/FreeBSD/strxfrm.c (and a really quick glance at the contents of libc on OSX 10.9 reinforces this--- I don't see any calls into their CoreFoundation unicode string APIs.) -- 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] Fwd: SSL auth question
On 1 Apr 2014, at 11:38 PM, carriingfat...@ya.ru wrote: I set certificate auth on postgresql 9.3. I generate SSL certificate with my custom extension. So, OpenSSL read it, PostgreSQL accept it if this extension is not critical, but if I set this extension critical, PostgreSQL deny connection. I think that is the correct behavior. The critical bit tells PostgreSQL (or other software) what to do if it does not understand the extension: if there's an unknown extension with the critical bit set, then the certificate can't be validated. If the critical bit is not set, then the unknown extension is ignored, and the certificate is processed as if the extension weren't there. See this section of RFC 5280: http://tools.ietf.org/html/rfc5280#section-4.2 The idea is that you can set the critical bit for extensions that are supposed *restrict* the usability of the certificate, so that the certificate won't be used in undesired ways by software that doesn't understand the extension. -- 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] It seems no Windows buildfarm members are running find_typedefs
On 2 Apr 2014, at 5:43 PM, Tom Lane wrote: I poked around a bit, and so far as I can tell, OS X does not store debug symbol tables in executables. It looks like gdb goes to the .o files when it wants debug info. What's in the .o files is good ol' DWARF (at least in reasonably recent OS X releases), so it's not any harder to pull out the typedef names than it is on Linux. The problem is that you gotta iterate over all the .o files in the build tree rather than the installed executables. I looked at fixing find_typedefs but it seems like it's pretty fixated on the latter approach; any thoughts on how to revise it? The Apple development tools gather the debug information during the final link stage (the one that produces the executable or shared object) using dsymutil, which simply iterates over all of the .o files and links the debug info into a separate object, foo.dSYM. Apple's gdb and lldb then find the relevant .dSYM file using a per-build UUID embedded in the executable/library/debug symbol file. The dSYM file is a normal object file which has the DWARF sections but not the usual text/data sections, so if it can be generated/found, it should be possible to dump the DWARF data from it and look for typedefs that way. (I'm pretty sure that if you were to run dsymutil and then merge the resulting object file's sections into the executable/shlib, you'd get a perfectly functional and debuggable result without having to look for or cart around the extra dSYM file--- I haven't tried this though.) -- 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] pgcrypto: implement gen_random_uuid
One comment, this: /* get 128 random bits */ int err = px_get_random_bytes(buf, 16); might be better to use px_get_pseudo_random_bytes(). UUIDs don't need to be unguessable or have perfect entropy; they just need to be collision-resistant. RFC4122 mentions this I think, and if you look at the ossp-uuid function that this is replacing, it also uses its internal PRNG for v4 UUIDs rather than strong high-entropy randomness. (The downside of requesting strong randomness when you don't need it is that it can potentially cause the server to block while the system gathers entropy.) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [review] libpq: Support TLSv1.1+ (was: fe-secure.c and SSL/TLS)
I applied both libpq.tls11plus.diff and the related psql.conninfo.tlsver.diff patch to postgresql git head. Source review: The source changes are pretty tiny. Although I think the change from TLSv1_method to SSLv23_method is correct, the comment is not quite correct: * SSLv23_method() is only method that negotiates * higher protocol versions. Rest of the methods * allow only one specific TLS version. As I understand it (backed up by a quick glance through the openssl source), the TLSv1_method, TLSv1_1_method, and TLSv1_2_method will all advertise the corresponding protocol version to the peer, meaning that in practice they will negotiate *up to* that TLS version, but will still negotiate down to SSLv3. So, using TLSv1_2_method would give the right behavior when compiled against a recent openssl. However, someday when TLSv1.3 (or 2.0) appears, presumably the SSLv23_method will be extended to include it but TLSv1_2_method would have to be changed to TLSv1_3_method. Therefore using SSLv23_method and disabling older protocol versions with SSL_CTX_set_options() should have the desired behavior even in future versions. (And it doesn't require autoconf to probe the openssl version.) Testing: I built the patched postgresql against a handful of openssl versions: 1.0.1 (netbsd, x86-64, supports TLSv1.1); Git head aka 1.0.1f++ (osx, x86-32, supports TLSv1.2), and 0.9.8y (osx, x86-32, supports TLSv1.0). They all built cleanly and passed 'make check'. I also built 'contrib' and installed the sslinfo extension. I connected between each pair of versions (with psql) and saw that the connection negotiated the highest protocol version supported by both ends and a corresponding ciphersuite. /conninfo and the sslinfo extension agreed on the protocol version and ciphersuite in use. Things I didn't test: Client certificates, restricted sets of ciphersuites, MITM protocol-downgrade attacks, non-x86 architectures, or 1.0.0* versions of openssl. -- 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] Make various variables read-only (const)
By an odd coincidence, I also decided to try to const-ify libpq
recently, and noticed this thread as I was cleaning up my patch for
submission. For what it's worth, I've attached my patch to this message.
It doesn't move as much data into the text segment as Oskari Saarenmaa's
patch does, but it is less intrusive (simply adding const modifiers here
and there). I just went after the low-hanging fruit in libpq.
As an aside, it might make sense to make pg_encname_tbl and
pg_encname_tbl_sz static, since as far as I can tell those symbols are
never used outside of encnames.c nor are they likely to be. I didn't
make that change in this patch though.
On Mon, Dec 23, 2013, Robert Haas robertmh...@gmail.com wrote:
And how much does this really affect data sharing? Doesn't copy-on-write do
the same thing for writable data?
It can have a surprisingly large effect if read-only data gets
intermixed on pages with actual read-write data and can get COWd
unnecessarily.
My motivation, though, was more about code correctness than memory
sharing, though sharing is a nice benefit--- I was examining unexpected
symbols in .data/.bss in case they represented a thread-safety problem
for my program linked against libpq. (They didn't, FWIW, except for the
known and documented issue with PQoidStatus(). Not that I really
expected to find a problem in libpq, but marking those structures const
makes it nice and clear that they're not mutable.)
diff --git a/src/backend/utils/mb/encnames.c b/src/backend/utils/mb/encnames.c
index 772d4a5..3f8c592 100644
--- a/src/backend/utils/mb/encnames.c
+++ b/src/backend/utils/mb/encnames.c
@@ -29,7 +29,7 @@
* Karel Zak, Aug 2001
* --
*/
-pg_encname pg_encname_tbl[] =
+const pg_encname pg_encname_tbl[] =
{
{
abc, PG_WIN1258
@@ -291,7 +291,7 @@ pg_encname pg_encname_tbl[] =
} /* last */
};
-unsigned int pg_encname_tbl_sz = \
+const unsigned int pg_encname_tbl_sz = \
sizeof(pg_encname_tbl) / sizeof(pg_encname_tbl[0]) - 1;
/* --
@@ -304,7 +304,7 @@ sizeof(pg_encname_tbl) / sizeof(pg_encname_tbl[0]) - 1;
#else
#define DEF_ENC2NAME(name, codepage) { #name, PG_##name, codepage }
#endif
-pg_enc2name pg_enc2name_tbl[] =
+const pg_enc2name pg_enc2name_tbl[] =
{
DEF_ENC2NAME(SQL_ASCII, 0),
DEF_ENC2NAME(EUC_JP, 20932),
@@ -356,7 +356,7 @@ pg_enc2name pg_enc2name_tbl[] =
* This covers all encodings except MULE_INTERNAL, which is alien to gettext.
* --
*/
-pg_enc2gettext pg_enc2gettext_tbl[] =
+const pg_enc2gettext pg_enc2gettext_tbl[] =
{
{PG_SQL_ASCII, US-ASCII},
{PG_UTF8, UTF-8},
@@ -469,11 +469,11 @@ clean_encoding_name(const char *key, char *newkey)
* Search encoding by encoding name
* --
*/
-pg_encname *
+const pg_encname *
pg_char_to_encname_struct(const char *name)
{
unsigned int nel = pg_encname_tbl_sz;
- pg_encname *base = pg_encname_tbl,
+ const pg_encname *base = pg_encname_tbl,
*last = base + nel - 1,
*position;
int result;
@@ -521,7 +521,7 @@ pg_char_to_encname_struct(const char *name)
int
pg_char_to_encoding(const char *name)
{
- pg_encname *p;
+ const pg_encname *p;
if (!name)
return -1;
@@ -545,7 +545,7 @@ pg_encoding_to_char(int encoding)
{
if (PG_VALID_ENCODING(encoding))
{
- pg_enc2name *p = pg_enc2name_tbl[encoding];
+ const pg_enc2name *p = pg_enc2name_tbl[encoding];
Assert(encoding == p-encoding);
return p-name;
diff --git a/src/backend/utils/mb/mbutils.c b/src/backend/utils/mb/mbutils.c
index 6d1cd8e..08440e9 100644
--- a/src/backend/utils/mb/mbutils.c
+++ b/src/backend/utils/mb/mbutils.c
@@ -55,9 +55,9 @@ static FmgrInfo *ToClientConvProc = NULL;
/*
* These variables track the currently-selected encodings.
*/
-static pg_enc2name *ClientEncoding = pg_enc2name_tbl[PG_SQL_ASCII];
-static pg_enc2name *DatabaseEncoding = pg_enc2name_tbl[PG_SQL_ASCII];
-static pg_enc2name *MessageEncoding = pg_enc2name_tbl[PG_SQL_ASCII];
+static const pg_enc2name *ClientEncoding = pg_enc2name_tbl[PG_SQL_ASCII];
+static const pg_enc2name *DatabaseEncoding = pg_enc2name_tbl[PG_SQL_ASCII];
+static const pg_enc2name *MessageEncoding = pg_enc2name_tbl[PG_SQL_ASCII];
/*
* During backend startup we can't set client encoding because we (a)
diff --git a/src/backend/utils/mb/wchar.c b/src/backend/utils/mb/wchar.c
index 45bc3c1..6d03a10 100644
--- a/src/backend/utils/mb/wchar.c
+++ b/src/backend/utils/mb/wchar.c
@@ -1720,7 +1720,7 @@ pg_eucjp_increment(unsigned char *charptr, int length)
* XXX must be sorted by the same order as enum pg_enc (in mb/pg_wchar.h)
*---
*/
-pg_wchar_tbl pg_wchar_table[] = {
+const pg_wchar_tbl
