Re: [HACKERS] WAL dump tool
On Fri, May 8, 2009 at 3:43 AM, higepon wrote: > Hi. > Is the following todo item still necessary? > > Create dump tool for write-ahead logs for use in determining > transaction id for point-in-time recovery. > This is useful for checking PITR recovery. > > If so, I want to make it. > What is the expected output of the dump tool? > TransactionId, TimeLineID and ? > don't know if this project ever works http://pgfoundry.org/projects/xlogviewer but seems like is a start (it was made for 8.2 so you will have to adjust for 8.3 or even better 8.4) -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pg_migrator alpha 5 - truncates at 10 M rows
2009.05.09 pg_migrator alpha 5 results from PostgreSQL 8.3.7 to 8.4cvs Centos 5.2 x86_64 GNU/Linux pg_migrator ran without errors. Of 120 tables, all smaller tables have the correct rowcount, but all larger tables are 'truncated' at around 10 million rows. I haven't looked at table content. 8.38.4cvs | rowcount | rowcount | +---+--+ | 7708808 | 7708808 | | 10189986 | 9826926 | | 2598808 | 2598808 | | 6074119 | 6074119 | | 13563559 | 9830128 | | 13597969 | 9830114 | | 23507096 | 9829964 | | 15517779 | 9805163 | | 12618858 | 9829974 | | 11127521 | 9829902 | | 4728763 | 4728763 | | 4728763 | 4728763 | | 61193699 | 9173790 | | 1968328 | 1968328 | | 53213115 | 9823165 | | 31601320 | 9830060 | One complication: I hadn't noticed that there were 2 tables with a not yet installed datatype. These tables were simply not created by the pg_migrator-run. I don't know how this influenced the results, but I'll repeat it in the coming days. Erik Rijkers -- 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] strict version of version_stamp.pl
Joshua D. Drake wrote:
Hello,
Here is a diff of version_stamp.pl. It is not quite done as I can't
actually get it to run. No matter what I do it doesn't appear to be able
to open configure.in.
If someone could help me figure out where I am being stupid I would
appreciate it.
Maybe you aren't running it in the right directory (i.e. the directory
where configure.in exists)?
Anyway, I think what you want to achieve (without all the git crap) is
the attached.
cheers
andrew
Index: version_stamp.pl
===
RCS file: /cvsroot/pgsql/src/tools/version_stamp.pl,v
retrieving revision 1.2
diff -c -u -r1.2 version_stamp.pl
--- version_stamp.pl 1 Jan 2009 17:24:04 - 1.2
+++ version_stamp.pl 9 May 2009 01:02:48 -
@@ -20,15 +20,18 @@
# "devel", "betaN", "rcN".
#
+use strict;
+
# Major version is hard-wired into the script. We update it when we branch
# a new development version.
-$major1 = 8;
-$major2 = 4;
+my $major1 = 8;
+my $major2 = 4;
# Validate argument and compute derived variables
-$minor = shift;
+my $minor = shift;
defined($minor) || die "$0: missing required argument: minor-version\n";
+my ($dotneeded,$numericminor);
if ($minor =~ m/^\d+$/) {
$dotneeded = 1;
$numericminor = $minor;
@@ -46,19 +49,20 @@
}
# Create various required forms of the version number
-$majorversion = $major1 . "." . $major2;
+my $majorversion = $major1 . "." . $major2;
+my $fullversion;
if ($dotneeded) {
$fullversion = $majorversion . "." . $minor;
} else {
$fullversion = $majorversion . $minor;
}
-$numericversion = $majorversion . "." . $numericminor;
-$padnumericversion = sprintf("%d%02d%02d", $major1, $major2, $numericminor);
+my $numericversion = $majorversion . "." . $numericminor;
+my $padnumericversion = sprintf("%d%02d%02d", $major1, $major2, $numericminor);
# Get the autoconf version number for eventual nag message
# (this also ensures we're in the right directory)
-$aconfver = "";
+my $aconfver = "";
open(FILE, "configure.in") || die "could not read configure.in: $!\n";
while () {
if (m/^m4_if\(m4_defn\(\[m4_PACKAGE_VERSION\]\), \[(.*)\], \[\], \[m4_fatal/) {
@@ -71,7 +75,7 @@
# Update configure.in and other files that contain version numbers
-$fixedfiles = "";
+my $fixedfiles = "";
sed_file("configure.in",
"-e 's/AC_INIT(\\[PostgreSQL\\], \\[[0-9a-z.]*\\]/AC_INIT([PostgreSQL], [$fullversion]/'");
--
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] strict version of version_stamp.pl
On May 8, 2009, at 4:00 PM, Peter Eisentraut wrote: (You can't be serious that for reverting a WC file to the repository state you use "git checkout"?) Why not? The purpose of the operation is to get a file from the repository. It's not much different whether you do it the first or the second time. Yeah, this makes it difficult for me to remember, too. I'm constantly asking how to do this on #git. Best, David -- 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] strict version of version_stamp.pl
On Fri, May 8, 2009 at 5:50 PM, Tom Lane wrote: > "Joshua D. Drake" writes: >> Yes I apologize for that. Git reacted differently than I expected to a >> "git diff". I have since reposted a proper patch. > > mmm ... I've recently been forced into using git for another project, > and I find myself mystified as to why anyone would want to use it. > Seems like baroqueness and unexpected behaviors are all over the thing. I had that same reaction at first. It is definitely different than cvs or svn. The first time I tried to use it, I gave up. The second time I tried to use it, I gave up. The third time I tried to use it, I almost gave up. But now I love it. A couple of really nice things: In CVS or SVN, there is no easy way (AFAIK) to get the entire history of all changes to the repository. You can get the history of changes to a FILE, but not the history of changes, period. In git, you just run "git log". (Of course if you want to restrict the output to changes that modified a certain file, you just do "git log filename".) If you are trying to find the last time something related to mumble was changed, you can run "git log -Smumble", and it shows you every commit that adds or removes a line containing the string "mumble". This is pretty useful when trying to familiarize yourself with the history of a certain bit of code. There are also options to search by regex, etc. The branching and merging stuff is incredibly good and useful. It takes a bit of getting used to the commands, but it is so much easier than cvs or svn. Actually, svn isn't bad for MAKING branches (which was what initially persuaded me to use it), but it @$# sucks for merging them. It is just terrible. It may even be worse than CVS. Don't get me wrong: I used CVS very happily for more than 10 years, and it does what it does just fine, but git is so much more powerful that it's not even funny. I can't get over how much faster I can do things now that used to be a major headache. ...Robert -- 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] strict version of version_stamp.pl
On Fri, May 8, 2009 at 6:41 PM, Alvaro Herrera wrote: > Andres Freund wrote: >> Hi Alvaro, >> >> On 05/09/2009 12:26 AM, Alvaro Herrera wrote: Perhaps a more difficult problem is that there is no easy way to update a single file within a git repo. In cvs or svn, if I blow something up on a particular file and I just want to take a fresh look, I just rm;svn update. >>> Hmm, you should use "git revert" for that (same with SVN actually). >> Uh. Unfortunately not. git revert is for reverting the effects of an >> earlier commit, not a working copy difference. > > Thanks for the clarification :-) > > So how do you revert WC changes? At least I got the SVN part right -- > which is not surprising because that's the one I actually use. Oh, and > monotone uses 'revert' for the WC meaning too (the other one does not > really make much sense to me, but so does git as a whole) > > (You can't be serious that for reverting a WC file to the repository > state you use "git checkout"?) Yes, that's right. I found that a bit odd too, but it's really not bad once you get used to it. If you want to blow away ALL your changes, you can use "git reset --hard". If you want to remove all the untracked files from your working tree, you can use "git clean". ...Robert -- 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] Show method of index
> > Please add it to wiki.postgresql.org/wiki/CommitFestInProgress > Submitted under http://wiki.postgresql.org/wiki/CommitFest_2009-First#Clients Regards, Khee Chin. -- 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] strict version of version_stamp.pl
On Saturday 09 May 2009 01:41:20 Alvaro Herrera wrote: > (You can't be serious that for reverting a WC file to the repository > state you use "git checkout"?) Why not? The purpose of the operation is to get a file from the repository. It's not much different whether you do it the first or the second time. -- 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] strict version of version_stamp.pl
Andres Freund wrote: > Hi Alvaro, > > On 05/09/2009 12:26 AM, Alvaro Herrera wrote: >>> Perhaps a more difficult problem is that there is no easy way to update >>> a single file within a git repo. In cvs or svn, if I blow something up >>> on a particular file and I just want to take a fresh look, I just rm;svn >>> update. >> Hmm, you should use "git revert" for that (same with SVN actually). > Uh. Unfortunately not. git revert is for reverting the effects of an > earlier commit, not a working copy difference. Thanks for the clarification :-) So how do you revert WC changes? At least I got the SVN part right -- which is not surprising because that's the one I actually use. Oh, and monotone uses 'revert' for the WC meaning too (the other one does not really make much sense to me, but so does git as a whole) (You can't be serious that for reverting a WC file to the repository state you use "git checkout"?) -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] strict version of version_stamp.pl
Hi Alvaro, On 05/09/2009 12:26 AM, Alvaro Herrera wrote: Perhaps a more difficult problem is that there is no easy way to update a single file within a git repo. In cvs or svn, if I blow something up on a particular file and I just want to take a fresh look, I just rm;svn update. Hmm, you should use "git revert" for that (same with SVN actually). Uh. Unfortunately not. git revert is for reverting the effects of an earlier commit, not a working copy difference. Andres -- 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] strict version of version_stamp.pl
Hi Joshua, On 05/09/2009 12:22 AM, Joshua D. Drake wrote: Obviously, an unchecked cvs diff would have produced the same garbage. Any other problems? There are a number of conceptual differences. For example as a majority svn user, svn diff does not act the way git diff does. In that svn diff will only give me the difference within the current working directory. It will not go to the beginning of the tree and give me a diff. git diff . Although admittedly that takes some time getting used to. Perhaps a more difficult problem is that there is no easy way to update a single file within a git repo. In cvs or svn, if I blow something up on a particular file and I just want to take a fresh look, I just rm;svn update. git checkout HEAD [--] your_file Andres -- 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] strict version of version_stamp.pl
Joshua D. Drake wrote: > Perhaps a more difficult problem is that there is no easy way to update > a single file within a git repo. In cvs or svn, if I blow something up > on a particular file and I just want to take a fresh look, I just rm;svn > update. Hmm, you should use "git revert" for that (same with SVN actually). -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] strict version of version_stamp.pl
On Sat, 2009-05-09 at 01:18 +0300, Peter Eisentraut wrote: > On Saturday 09 May 2009 00:50:28 Tom Lane wrote: > > "Joshua D. Drake" writes: > > > Yes I apologize for that. Git reacted differently than I expected to a > > > "git diff". I have since reposted a proper patch. > > > > mmm ... I've recently been forced into using git for another project, > > and I find myself mystified as to why anyone would want to use it. > > Seems like baroqueness and unexpected behaviors are all over the thing. > > Obviously, an unchecked cvs diff would have produced the same garbage. Any > other problems? There are a number of conceptual differences. For example as a majority svn user, svn diff does not act the way git diff does. In that svn diff will only give me the difference within the current working directory. It will not go to the beginning of the tree and give me a diff. Perhaps a more difficult problem is that there is no easy way to update a single file within a git repo. In cvs or svn, if I blow something up on a particular file and I just want to take a fresh look, I just rm;svn update. Those are two things I can think of from my own working perspective that have been an adjustment. I would be curious to Tom's differences as well. Sincerely, Joshua D. Drake -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- 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] Show method of index
Khee Chin escribió: > > Hi, > > > I think that can be useful the command \di on psql show the method of > > index (hash, btree, ...) like: > > > test=# \di > >List of relations > > Schema | Name | Type | Owner| Table | Method > > +---+---+++ > > public | test_id_idx | index | postgresql | table1 | btree > > public | test_name_idx | index | postgresql | table1 | hash > > (2 rows) > > Attached is a simple patch which adds the above mentioned functionality to > psql. Please add it to wiki.postgresql.org/wiki/CommitFestInProgress -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] strict version of version_stamp.pl
On Saturday 09 May 2009 00:50:28 Tom Lane wrote: > "Joshua D. Drake" writes: > > Yes I apologize for that. Git reacted differently than I expected to a > > "git diff". I have since reposted a proper patch. > > mmm ... I've recently been forced into using git for another project, > and I find myself mystified as to why anyone would want to use it. > Seems like baroqueness and unexpected behaviors are all over the thing. Obviously, an unchecked cvs diff would have produced the same garbage. Any other problems? -- 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] Show method of index
> Hi, > I think that can be useful the command \di on psql show the method of > index (hash, btree, ...) like: > test=# \di >List of relations > Schema | Name | Type | Owner| Table | Method > +---+---+++ > public | test_id_idx | index | postgresql | table1 | btree > public | test_name_idx | index | postgresql | table1 | hash > (2 rows) Attached is a simple patch which adds the above mentioned functionality to psql. Regards, Khee Chin. index_patch Description: Binary data -- 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] Some 8.4 changes needed according to pg_migrator testing
Tom Lane wrote: > Bruce Momjian writes: > > Tom Lane wrote: > >> No, that sounds like it should be sufficient ... but you need to check > >> the template0 encodings match too, assuming that we make encoding and > >> locale work the same here. > > > OK, are you suggesting checking the pg_database.encoding for > > template0 for both servers because that information isn't in either > > pg_controldatas? > > Right. Compare old template0 encoding against new template0 encoding, > and old locale information from pg_controldata against new template0 > locale information. If these match then it will be safe to let > pg_dumpall omit the corresponding CREATE DATABASE parameters. OK, encoding check added to pg_migrator. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] SSL cert chains patch
Magnus asked me for this, when the subject came up on IRC. This is a
longstanding ignored issue, for example
http://archives.postgresql.org/message-id/slrnemslp5.2rcr.andrew+non...@atlantis.supernews.net
http://archives.postgresql.org/message-id/15d55918-fa9c-4e6a-ba15-bdc9142a6...@contegix.com
--
Andrew (irc:RhodiumToad)
Index: src/backend/libpq/be-secure.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/libpq/be-secure.c,v
retrieving revision 1.90
diff -c -r1.90 be-secure.c
*** src/backend/libpq/be-secure.c 28 Jan 2009 15:06:47 - 1.90
--- src/backend/libpq/be-secure.c 8 May 2009 21:30:43 -
***
*** 729,737
/*
* Load and verify certificate and private key
*/
! if (SSL_CTX_use_certificate_file(SSL_context,
! SERVER_CERT_FILE,
! SSL_FILETYPE_PEM) != 1)
ereport(FATAL,
(errcode(ERRCODE_CONFIG_FILE_ERROR),
errmsg("could not load server certificate file \"%s\": %s",
--- 729,736
/*
* Load and verify certificate and private key
*/
! if (SSL_CTX_use_certificate_chain_file(SSL_context,
! SERVER_CERT_FILE) != 1)
ereport(FATAL,
(errcode(ERRCODE_CONFIG_FILE_ERROR),
errmsg("could not load server certificate file \"%s\": %s",
--
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] Automatic client certificate selection support for libpq v1
In message <14727.1241816...@sss.pgh.pa.us>, Tom Lane writes: > It is of course possible to support both at the same time (at > compile-time, if nowhere else). Yes, I suppose we'd not wish to just drop openssl completely. I wonder how much code duplication would ensue from a compile-time choice of which library to use ... My only datapoint for you is curl, which is an application I happen to have discovered that can use either NSS and OpenSSL. Lines Words Chars Filename 2508 7890 74682 ssluse.c 1331 3708 36411 nss.c I imagine that you would more or less have to provide a different be-secure.c and fe-secure.c file for the two different libraries--whether as a separate file or via #ifdefs. It looks like there is a small amount of common code present (why *is* pg_block_sigpipe() in that file anyway?) -Seth Robertson in-pgsql-hack...@baka.org -- 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] strict version of version_stamp.pl
"Joshua D. Drake" writes: > Yes I apologize for that. Git reacted differently than I expected to a > "git diff". I have since reposted a proper patch. mmm ... I've recently been forced into using git for another project, and I find myself mystified as to why anyone would want to use it. Seems like baroqueness and unexpected behaviors are all over the thing. 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] strict version of version_stamp.pl
On Fri, 2009-05-08 at 17:44 -0400, Tom Lane wrote: > "Joshua D. Drake" writes: > > Here is a diff of version_stamp.pl. > > ... and nearly a megabyte of irrelevant junk. Please take a closer look at > what you're sending before you send it ... Never mind on this. I have obviously not re-honed my perl skills enough to handle this. Sorry for the noise. Joshua D. Drake > > regards, tom lane > -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- 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] strict version of version_stamp.pl
On Fri, 2009-05-08 at 17:44 -0400, Tom Lane wrote: > "Joshua D. Drake" writes: > > Here is a diff of version_stamp.pl. > > ... and nearly a megabyte of irrelevant junk. Please take a closer look at > what you're sending before you send it ... Yes I apologize for that. Git reacted differently than I expected to a "git diff". I have since reposted a proper patch. /me walks away in shame Sincerely, Joshua D. Drake > > regards, tom lane > -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- 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] strict version of version_stamp.pl
On Fri, 2009-05-08 at 14:16 -0700, Joshua D. Drake wrote:
> Hello,
>
> Here is a diff of version_stamp.pl. It is not quite done as I can't
> actually get it to run. No matter what I do it doesn't appear to be able
> to open configure.in.
>
> If someone could help me figure out where I am being stupid I would
> appreciate it.
Well you can all start by pointing out that I included a patch to
configure (which was wholly unintended). Sorry about that. Here is the
straight perl patch.
Sincerely,
Joshua D. Drake
--
PostgreSQL - XMPP: jdr...@jabber.postgresql.org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997
diff --git a/src/tools/version_stamp.pl b/src/tools/version_stamp.pl
index e99d2c3..686748e 100755
--- a/src/tools/version_stamp.pl
+++ b/src/tools/version_stamp.pl
@@ -5,7 +5,7 @@
#
# Copyright (c) 2008-2009, PostgreSQL Global Development Group
#
-# $PostgreSQL$
+# my $PostgreSQL my $
#
#
@@ -20,49 +20,55 @@
# "devel", "betaN", "rcN".
#
+# We do strict now
+use strict;
+
# Major version is hard-wired into the script. We update it when we branch
# a new development version.
-$major1 = 8;
-$major2 = 4;
+my $major1 = 8;
+my $major2 = 4;
# Validate argument and compute derived variables
-$minor = shift;
+my $minor = shift;
defined($minor) || die "$0: missing required argument: minor-version\n";
if ($minor =~ m/^\d+$/) {
-$dotneeded = 1;
-$numericminor = $minor;
+my $dotneeded = 1;
+my $numericminor = $minor;
} elsif ($minor eq "devel") {
-$dotneeded = 0;
-$numericminor = 0;
+my $dotneeded = 0;
+my $numericminor = 0;
} elsif ($minor =~ m/^beta\d+$/) {
-$dotneeded = 0;
-$numericminor = 0;
+my $dotneeded = 0;
+my $numericminor = 0;
} elsif ($minor =~ m/^rc\d+$/) {
-$dotneeded = 0;
-$numericminor = 0;
+my $dotneeded = 0;
+my $numericminor = 0;
} else {
die "$0: minor-version must be N, devel, betaN, or rcN\n";
}
# Create various required forms of the version number
-$majorversion = $major1 . "." . $major2;
-if ($dotneeded) {
-$fullversion = $majorversion . "." . $minor;
+my $majorversion = $major1 . "." . $major2;
+if (my $dotneeded) {
+my $fullversion = $majorversion . "." . $minor;
} else {
-$fullversion = $majorversion . $minor;
+my $fullversion = $majorversion . $minor;
}
-$numericversion = $majorversion . "." . $numericminor;
-$padnumericversion = sprintf("%d%02d%02d", $major1, $major2, $numericminor);
+
+my $numericminor = undef;
+my $numericversion = $majorversion . "." . $numericminor;
+my $padnumericversion = sprintf("%d%02d%02d", $major1, $major2, $numericminor);
# Get the autoconf version number for eventual nag message
# (this also ensures we're in the right directory)
-$aconfver = "";
-open(FILE, "configure.in") || die "could not read configure.in: $!\n";
+my $aconfver = "";
+my $configinfile = $2;
+open(FILE, "$configinfile") || die "could not read configure.in: $!\n";
while () {
if (m/^m4_if\(m4_defn\(\[m4_PACKAGE_VERSION\]\), \[(.*)\], \[\], \[m4_fatal/) {
-$aconfver = $1;
+$aconfver = $1;
last;
}
}
@@ -71,43 +77,32 @@ $aconfver ne "" || die "could not find autoconf version number in configure.in\n
# Update configure.in and other files that contain version numbers
-$fixedfiles = "";
+my $fixedfiles = "";
+my $fullversion = "";
-sed_file("configure.in",
- "-e 's/AC_INIT(\\[PostgreSQL\\], \\[[0-9a-z.]*\\]/AC_INIT([PostgreSQL], [$fullversion]/'");
+sed_file("$configinfile", "-e 's/AC_INIT(\\[PostgreSQL\\], \\[[0-9a-z.]*\\]/AC_INIT([PostgreSQL], [$fullversion]/'");
-sed_file("doc/bug.template",
- "-e 's/PostgreSQL version (example: PostgreSQL .*) *: PostgreSQL .*/PostgreSQL version (example: PostgreSQL $fullversion): PostgreSQL $fullversion/'");
+sed_file("doc/bug.template", "-e 's/PostgreSQL version (example: PostgreSQL .*) *: PostgreSQL .*/PostgreSQL version (example: PostgreSQL $fullversion): PostgreSQL $fullversion/'");
-sed_file("src/include/pg_config.h.win32",
- "-e 's/#define PACKAGE_STRING \"PostgreSQL .*\"/#define PACKAGE_STRING \"PostgreSQL $fullversion\"/' " .
- "-e 's/#define PACKAGE_VERSION \".*\"/#define PACKAGE_VERSION \"$fullversion\"/' " .
- "-e 's/#define PG_VERSION \".*\"/#define PG_VERSION \"$fullversion\"/' " .
- "-e 's/#define PG_VERSION_NUM .*/#define PG_VERSION_NUM $padnumericversion/'");
+sed_file("src/include/pg_config.h.win32", "-e 's/#define PACKAGE_STRING \"PostgreSQL .*\"/#define PACKAGE_STRING \"PostgreSQL $fullversion\"/' " . "-e 's/#define PACKAGE_VERSION \".*\"/#define PACKAGE_VERSION \" $fullversion\"/' " . "-e 's/#define PG_VERSION \".*\"/#define PG_VERSION \" $fullversion\"/' " . "-e 's/#define PG_VERSION_NUM .*/#define PG_VERSION_NUM $padnumericversion/'");
-sed_file("src/interfaces/libpq/libpq.rc.in",
- "-e 's/FILEVERS
Re: [HACKERS] strict version of version_stamp.pl
"Joshua D. Drake" writes: > Here is a diff of version_stamp.pl. ... and nearly a megabyte of irrelevant junk. Please take a closer look at what you're sending before you send it ... 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] Some 8.4 changes needed according to pg_migrator testing
Bruce Momjian writes: > Tom Lane wrote: >> No, that sounds like it should be sufficient ... but you need to check >> the template0 encodings match too, assuming that we make encoding and >> locale work the same here. > OK, are you suggesting checking the pg_database.encoding for > template0 for both servers because that information isn't in either > pg_controldatas? Right. Compare old template0 encoding against new template0 encoding, and old locale information from pg_controldata against new template0 locale information. If these match then it will be safe to let pg_dumpall omit the corresponding CREATE DATABASE parameters. 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] Some 8.4 changes needed according to pg_migrator testing
Tom Lane wrote: > Bruce Momjian writes: > > Tom Lane wrote: > >> One problem that just occurred to me is that this solution may not be > >> adequate for pg_migrator. It will need to check that the new database > >> has the same "default" settings (where "default" means "those of > >> template0") as the old installation did. I think that's probably doable > >> but we'll have to check. > > > I have already coded pg_migrator to get the 8.4 template0 locale and > > check for a match of that against pg_controldata of 8.3. Are you saying > > I need to spin through all the databases after they are created and > > check again? > > No, that sounds like it should be sufficient ... but you need to check > the template0 encodings match too, assuming that we make encoding and > locale work the same here. OK, are you suggesting checking the pg_database.encoding for template0 for both servers because that information isn't in either pg_controldatas? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] Automatic client certificate selection support for libpq v1
Seth Robertson writes: > In message <12314.1241809...@sss.pgh.pa.us>, Tom Lane writes: > BTW, I was reminded today that Fedora/Red Hat are hoping to standardize > all crypto-related functionality in their entire distro on the NSS > libraries: > I am not perfectly up to speed, but switching to NSS would solve this > (automatic client certificate selection) problem in the crypto > library, since NSS supports a client certificate database and > furthermore has a default callback function NSS_GetClientAuthData > which searches the certificate database for a suitable match. Interesting. > It also > supports OCSP (online certificate status protocol) which is an online > certificate revocation check (better than the current TODO item of > "Allow SSL CRL files to be re-read during configuration file reload, > rather than requiring a server restart"). > Well, I guess that openssl supports OCSP as well, but the support does > not seem as complete (no AIA support--revocation URL embedded in the > certificate--that I can see). Well, one of the arguments the Fedora crowd is making for NSS is that it's more feature-complete than the other crypto libraries, so this doesn't surprise me much. > It is of course possible to support both at the same time (at > compile-time, if nowhere else). Yes, I suppose we'd not wish to just drop openssl completely. I wonder how much code duplication would ensue from a compile-time choice of which library to use ... 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] Some 8.4 changes needed according to pg_migrator testing
Bruce Momjian writes: > Tom Lane wrote: >> One problem that just occurred to me is that this solution may not be >> adequate for pg_migrator. It will need to check that the new database >> has the same "default" settings (where "default" means "those of >> template0") as the old installation did. I think that's probably doable >> but we'll have to check. > I have already coded pg_migrator to get the 8.4 template0 locale and > check for a match of that against pg_controldata of 8.3. Are you saying > I need to spin through all the databases after they are created and > check again? No, that sounds like it should be sufficient ... but you need to check the template0 encodings match too, assuming that we make encoding and locale work the same here. 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] Some 8.4 changes needed according to pg_migrator testing
Tom Lane wrote: > One problem that just occurred to me is that this solution may not be > adequate for pg_migrator. It will need to check that the new database > has the same "default" settings (where "default" means "those of > template0") as the old installation did. I think that's probably doable > but we'll have to check. I have already coded pg_migrator to get the 8.4 template0 locale and check for a match of that against pg_controldata of 8.3. Are you saying I need to spin through all the databases after they are created and check again? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] Show method of index
Ricardo Bessa escribió: > Hi, > > I think that can be useful the command \di on psql show the method of > index (hash, btree, ...) like: > > test=# \di >List of relations > Schema | Name | Type | Owner| Table | Method > +---+---+++ > public | test_id_idx | index | postgresql | table1 | btree > public | test_name_idx | index | postgresql | table1 | hash > (2 rows) Well, you can see that with \d on the table, but IMHO this should be present on \di too, so +1. One gripe I had with \d and indexes the other day is that it sucks on functional indexes -- it just says "pg_expression_1". -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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] Automatic client certificate selection support for libpq v1
In message <12314.1241809...@sss.pgh.pa.us>, Tom Lane writes: Seth Robertson writes: > In message <8766.1241799...@sss.pgh.pa.us>, Tom Lane writes: >> Hmm, shouldn't we fix *that* rather than inventing a hack like this? > Basically doing this would probably become a project instead of a 5 > minute hack to support 80% of the functionality. I understand the > desire to limit the number of hacks in the source code, though. It's certainly possible that what you have done represents the best available engineering tradeoff. But at this point it's too late for 8.4 and so we have quite a bit of time to think about it. I'd like to at least consider alternative solutions before we choose this one. BTW, I was reminded today that Fedora/Red Hat are hoping to standardize all crypto-related functionality in their entire distro on the NSS libraries: I'm not sure that there would be benefits to us within the context of Postgres alone. Is anyone sufficiently up on the different crypto libraries to comment on that? I am not perfectly up to speed, but switching to NSS would solve this (automatic client certificate selection) problem in the crypto library, since NSS supports a client certificate database and furthermore has a default callback function NSS_GetClientAuthData which searches the certificate database for a suitable match. It also supports OCSP (online certificate status protocol) which is an online certificate revocation check (better than the current TODO item of "Allow SSL CRL files to be re-read during configuration file reload, rather than requiring a server restart"). Well, I guess that openssl supports OCSP as well, but the support does not seem as complete (no AIA support--revocation URL embedded in the certificate--that I can see). It is of course possible to support both at the same time (at compile-time, if nowhere else). -Seth Robertson in-pgsql-hack...@baka.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Show method of index
Hi, I think that can be useful the command \di on psql show the method of index (hash, btree, ...) like: test=# \di List of relations Schema | Name | Type | Owner| Table | Method +---+---+++ public | test_id_idx | index | postgresql | table1 | btree public | test_name_idx | index | postgresql | table1 | hash (2 rows) Or maybe only on \di+. test=# \di+ test_id_idx List of relations Schema |Name | Type | Owner| Table | Method | Size| Description +-+---+++++- public | test_id_idx | index | postgresql | table1 | btree | 8192 bytes | (1 row) If they wanna, i can submit the patch of this small change of psql. -- Ricardo Bessa
Re: [HACKERS] Patch to fix search_path defencies with pg_bench
Greg Smith writes: > On Thu, 7 May 2009, Tom Lane wrote: >> The tables will be created and used in schema 'a', and the effective >> search path depth will be the same. > The case to be concerned about here is where the search_path changes > between initialization and the pgbench run, which certainly isn't > impossible. That can leave you with a longer effective path to search. > Pretty unlikely to be a problem in the field though. Yeah. Also, there is another consideration here that hasn't been brought up AFAIR: the main point of running pgbench in-the-field is to find out whether your installation is properly tuned. If you've chosen a search_path setting that *did* have some unexpected performance issues, wouldn't you want pgbench to reveal that? It's peculiar to have pgbench forcing this one particular GUC setting and not any others. 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] [PATCH] Automatic client certificate selection support for libpq v1
Seth Robertson writes: > In message <8766.1241799...@sss.pgh.pa.us>, Tom Lane writes: >> Hmm, shouldn't we fix *that* rather than inventing a hack like this? > Basically doing this would probably become a project instead of a 5 > minute hack to support 80% of the functionality. I understand the > desire to limit the number of hacks in the source code, though. It's certainly possible that what you have done represents the best available engineering tradeoff. But at this point it's too late for 8.4 and so we have quite a bit of time to think about it. I'd like to at least consider alternative solutions before we choose this one. BTW, I was reminded today that Fedora/Red Hat are hoping to standardize all crypto-related functionality in their entire distro on the NSS libraries: http://fedoraproject.org/wiki/FedoraCryptoConsolidation This is a long way from fruition, but at some point we are going to be faced with using a compatibility wrapper that sort of emulates openssl (they are not even pretending it'll be 100% compatible). So I'm feeling a bit leery of wiring in any additional dependence on details of openssl functionality. I hesitate though to suggest that we think about porting ourselves to NSS --- I'm not sure that there would be benefits to us within the context of Postgres alone. Is anyone sufficiently up on the different crypto libraries to comment on that? 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] Patch to fix search_path defencies with pg_bench
On Thu, 7 May 2009, Tom Lane wrote: The tables will be created and used in schema 'a', and the effective search path depth will be the same. The case to be concerned about here is where the search_path changes between initialization and the pgbench run, which certainly isn't impossible. That can leave you with a longer effective path to search. Pretty unlikely to be a problem in the field though. -- * Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD -- 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] Some 8.4 changes needed according to pg_migrator testing
Alvaro Herrera writes: > Heikki Linnakangas wrote: >> If we go with that, we should probably make the notion of a default >> collation explicit. We could set pg_database.datcollate/datctype column >> to NULL to mean "use the cluster default". > I'm not sure how this would work. If I initdb with a certain > locale/encoding and then create a database with default locale/encoding, > how would a restore work on a cluster that has been initdb'd with a > different locale/encoding? If you don't dump the locale specification, > it could very well not match what the user intended. As Peter suggested, that's more or less the point. As long as we still have pg_dump output include the client_encoding setting, it is sensible to try to load a dump into a different default database encoding/locale; and in fact you can not guarantee that the new platform's locales behave exactly the same anyway. One problem that just occurred to me is that this solution may not be adequate for pg_migrator. It will need to check that the new database has the same "default" settings (where "default" means "those of template0") as the old installation did. I think that's probably doable but we'll have to check. 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] Some 8.4 changes needed according to pg_migrator testing
Heikki Linnakangas wrote: > If we go with that, we should probably make the notion of a default > collation explicit. We could set pg_database.datcollate/datctype column > to NULL to mean "use the cluster default". I'm not sure how this would work. If I initdb with a certain locale/encoding and then create a database with default locale/encoding, how would a restore work on a cluster that has been initdb'd with a different locale/encoding? If you don't dump the locale specification, it could very well not match what the user intended. > I don't find the idea of creating mapping tables of locale names very > appetizing. Looking at our encoding name mapping table, there's quite a > few different spellings of different encoding names alone, let alone all > locale names. Yeah, it doesn't seem pleasant that way. When I proposed it I was thinking that the mapping would be specified by the user. OTOH since it's only pg_dumpall output that's the problem, this idea is not be very useful because there will be no way for a tool to do the replacement. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] Some 8.4 changes needed according to pg_migrator testing
Peter Eisentraut writes: > On Friday 08 May 2009 19:09:51 Heikki Linnakangas wrote: >> How about only outputting the LC_COLLATE/CTYPE options for databases >> that use a non-default setting? > That was my latest thinking as well. Logically we should handle database encoding the same way, no? I'm not really satisfied with this as a long-term solution, but it may be the most we can hope to squeeze into 8.4. I'm willing to go make the pg_dumpall changes if there are not objections/better ideas. >> If we go with that, we should probably make the notion of a default >> collation explicit. We could set pg_database.datcollate/datctype column >> to NULL to mean "use the cluster default". I don't find that to be a good idea, mainly because there *is* no "cluster default" anymore. I think it's okay for pg_dumpall to treat the template0 settings as being the "default" for its purposes, but keep in mind that there is nothing much stopping a DBA from replacing template0 with another DB that has different settings. We can't have that break existing DBs. 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] [PATCH] Automatic client certificate selection support for libpq v1
In message <8766.1241799...@sss.pgh.pa.us>, Tom Lane writes: Seth Robertson writes: > I had a situation where I needed to connect to multiple postgresql > servers in a variety of programs written in a variety of languages, > including some which connected to multiple servers at the same time. > As some of you might know, you cannot usefully put multiple > certificates or keys in the postgresql.crt/.key files. Hmm, shouldn't we fix *that* rather than inventing a hack like this? I certainly agree that it would be ideal. My understanding is that OpenSSL does not really support certificate stores/wallets or other methods of automatically handling multiple certificates (see http://gagravarr.org/writing/openssl-certs/general.shtml and http://www.openssl.org/docs/ssl/SSL_CTX_use_certificate.html, the latter which says: "NOTES The internal certificate store of OpenSSL can hold two private key/certificate pairs at a time: one key/certificate of type RSA and one key/certificate of type DSA.") The http://www.openssl.org/docs/ssl/SSL_CTX_set_client_cert_cb.html document suggests that the callback function (which postgresql already uses) can be extended to search a private certificate store to select and return the proper certificate. However, it is not clear from this manual page how to get access to the information about the requested certificate--I can only presume the information was sent to the client. Following each certificate chain from the client certificates loaded back to see if any match would be pretty painful as well. Basically doing this would probably become a project instead of a 5 minute hack to support 80% of the functionality. I understand the desire to limit the number of hacks in the source code, though. -Seth Robertson in-pgsql-hack...@baka.org -- 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] Some 8.4 changes needed according to pg_migrator testing
On Friday 08 May 2009 19:09:51 Heikki Linnakangas wrote: > How about only outputting the LC_COLLATE/CTYPE options for databases > that use a non-default setting? In the common scenarios where you have > the same collation for the whole cluster it would work just like in > previous releases. If you dump and restore a database with default > locale to a cluster initialized with a different locale, the database is > restored with the default locale of the target cluster. But if you > explicitly set a database to use a different locale, that would be > preserved in dumps with the caveat that you'd have to change it manually > if you restore to a cluster on a different platform. That was my latest thinking as well. And it preserves the not-uncommon use case that you pg_dumpall and restore your database after having initdb'ed with a different locale/encoding in order to, say, switch to Unicode. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [PATCH] Automatic client certificate selection support for libpq v1
On Fri, May 8, 2009 at 12:10 PM, Tom Lane wrote: > Seth Robertson writes: >> I had a situation where I needed to connect to multiple postgresql >> servers in a variety of programs written in a variety of languages, >> including some which connected to multiple servers at the same time. >> As some of you might know, you cannot usefully put multiple >> certificates or keys in the postgresql.crt/.key files. > > Hmm, shouldn't we fix *that* rather than inventing a hack like this? Possibly a la SSH's authorized_keys or known_hosts formats? David -- 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] Automatic client certificate selection support for libpq v1
Seth Robertson writes: > I had a situation where I needed to connect to multiple postgresql > servers in a variety of programs written in a variety of languages, > including some which connected to multiple servers at the same time. > As some of you might know, you cannot usefully put multiple > certificates or keys in the postgresql.crt/.key files. Hmm, shouldn't we fix *that* rather than inventing a hack like this? 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] Some 8.4 changes needed according to pg_migrator testing
Tom Lane wrote: Peter Eisentraut writes: On Thursday 07 May 2009 20:54:37 Alvaro Herrera wrote: I don't think there's much we can do apart from telling the user not to move stuff across platforms that do not have equally named locales. The other part of the problem is that there is no guarantee that equally or similarly named locales behave the same. There will necessarily be a user- beware factor here, and perhaps blowing up when the locale name is not recognized is safer and alerts about this fact better than trying to make it match by force somehow. We have never before operated on the assumption that it's okay for pg_dump output to be locked to particular platforms, and I do not think we should start now. So we've got to do *something* about this. (Do you really want PG Windows users to be unable to port to a better platform?) I note also that the problem is in pg_dumpall not pg_dump, so pg_restore is not going to help us --- if someone has a problem his only recourse would be manual editing of a possibly-monstrous SQL script file. How about only outputting the LC_COLLATE/CTYPE options for databases that use a non-default setting? In the common scenarios where you have the same collation for the whole cluster it would work just like in previous releases. If you dump and restore a database with default locale to a cluster initialized with a different locale, the database is restored with the default locale of the target cluster. But if you explicitly set a database to use a different locale, that would be preserved in dumps with the caveat that you'd have to change it manually if you restore to a cluster on a different platform. If we go with that, we should probably make the notion of a default collation explicit. We could set pg_database.datcollate/datctype column to NULL to mean "use the cluster default". I don't find the idea of creating mapping tables of locale names very appetizing. Looking at our encoding name mapping table, there's quite a few different spellings of different encoding names alone, let alone all locale names. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [PATCH] Automatic client certificate selection support for libpq v1
I had a situation where I needed to connect to multiple postgresql
servers in a variety of programs written in a variety of languages,
including some which connected to multiple servers at the same time.
As some of you might know, you cannot usefully put multiple
certificates or keys in the postgresql.crt/.key files.
I was pleased to see that 8.4 had sslcert/sslkey support and if it was
in 8.3, I *might* have done the painful work to update all of the
programs to use host-conditional environmental variables. However,
since I had to modify my 8.3 postgresql anyway, I decided to go with
an automatic file-selection approach. Essentially, before trying the
default postgresql.crt (and thus only if the sslcert option is not set
in 8.4), it appends the conn->pgname to the filename and checks to see
if that file exists. It uses that host-specific file if it does,
otherwise it continues to use the previous default. As such, it is a
low-impact change.
One possible problem is that as written it does not handle aliases
cleanly. If the host-specific certificate is named
"postgresql.crt.db.example.com" you will be able to connect if you use
`psql -h db.example.com`. However, if you use `psql -h db` you will
not match the file on disk (and thus fall back to postgresql.crt which
presumably will not contain the correct certificate). This can be
manually ``solved'' by creating links or copies of the host specific
file to each needed alias. If there is demand, the complexity of the
patch could be increased by using DNS to try and discover a canonical
name for the host. Using the IP address is another option, but is
probably not preferred since it reduces flexibility.
I can provide an 8.3 patch if anyone desires.
-Seth Robertson
in-pgsql-hack...@baka.org
diff --git a/src/interfaces/libpq/fe-secure.c b/src/interfaces/libpq/fe-secure.c
index ee0a91e..9a16996 100644
--- a/src/interfaces/libpq/fe-secure.c
+++ b/src/interfaces/libpq/fe-secure.c
@@ -599,7 +599,21 @@ client_cert_cb(SSL *ssl, X509 **x509, EVP_PKEY **pkey)
if (conn->sslcert)
strncpy(fnbuf, conn->sslcert, sizeof(fnbuf));
else
- snprintf(fnbuf, sizeof(fnbuf), "%s/%s", homedir,
USER_CERT_FILE);
+ {
+ fnbuf[0] = 0;
+
+ /* Check to see if there is a destination specific client
certificate */
+ if (conn->pghost)
+ {
+ snprintf(fnbuf, sizeof(fnbuf), "%s/%s.%s", homedir,
USER_CERT_FILE, conn->pghost);
+ if (access(fnbuf, R_OK) < 0)
+ fnbuf[0] = 0; /* Cannot find one, try for
default certificate */
+ }
+
+ /* Use default certificate file name if there was no hostname
present, or host specific file did not exist */
+ if (!fnbuf[0])
+ snprintf(fnbuf, sizeof(fnbuf), "%s/%s", homedir,
USER_CERT_FILE);
+ }
/*
* OpenSSL <= 0.9.8 lacks error stack handling, which means it's likely
to
@@ -713,8 +727,20 @@ client_cert_cb(SSL *ssl, X509 **x509, EVP_PKEY **pkey)
}
else
{
- /* No PGSSLKEY specified, load default file */
- snprintf(fnbuf, sizeof(fnbuf), "%s/%s", homedir, USER_KEY_FILE);
+ /* No PGSSLKEY specified, load default or host specific default
file */
+ fnbuf[0] = 0;
+
+ /* Check to see if there is a destination specific client key */
+ if (conn->pghost)
+ {
+ snprintf(fnbuf, sizeof(fnbuf), "%s/%s.%s", homedir,
USER_KEY_FILE, conn->pghost);
+ if (access(fnbuf, R_OK) < 0)
+ fnbuf[0] = 0; /* Cannot find one, try for
default key */
+ }
+
+ /* Use default key file name if there was no hostname present,
or host specific file did not exist */
+ if (!fnbuf[0])
+ snprintf(fnbuf, sizeof(fnbuf), "%s/%s", homedir,
USER_KEY_FILE);
}
if (fnbuf[0] != '\0')
--
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] Serializable Isolation without blocking
On Fri, May 8, 2009 at 3:49 PM, Kevin Grittner wrote: > Greg Stark wrote: > >> Well I don't understand what storing locks in an index can >> accomplish if other queries might use other indexes or sequential >> scans to access the records and never see those locks. >> >> Or does this method only require that writers discover the locks and >> therefore only writers can ever fail due to serialization failures >> they cause? > > Well, readers don't need to find the SIREAD locks which readers set. > Conflicts between writers are handled the same as current PostgreSQL > techniques. Readers need to look for write locks, and writers need to > look for SIREAD locks. Well this is where I'm failing to follow. If readers need to be sure they'll find write locks then surely they can't be stored in indexes without losing any flexibility. You would need to be sure other readers will look at the same index you put the lock in -- so you either need to put the lock in every index, have other readers look in every index, or have a very limited predictable way of ensuring everyone will use the same index for any queries where that lock matters. -- greg -- 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] Serializable Isolation without blocking
Tom Lane wrote: > Greg Stark writes: >> ... Argh, sorry, as soon as I hit send I realized this is wrong. >> Writers already need to insert into every index, so that's not a >> problem. > > What about HOT? I think that a read would need to lock both the row or tuple (not sure exactly how that would work) and any index used to find the row or tuple (or detect its absence). If a table scan is used, the lock would be at the table level (keeping in mind that this is not a lock which ever blocks anything). An insert or an update which created a new conflicting tuple would hit the table or index lock. A HOT update would hit the row lock. I think -Kevin -- 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] Serializable Isolation without blocking
Greg Stark writes: > ... Argh, sorry, as soon as I hit send I realized this is wrong. Writers > already need to insert into every index, so that's not a problem. What about HOT? 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] Some 8.4 changes needed according to pg_migrator testing
Peter Eisentraut writes: > On Thursday 07 May 2009 20:54:37 Alvaro Herrera wrote: >> I don't think there's much we can do apart from telling the user not to >> move stuff across platforms that do not have equally named locales. > The other part of the problem is that there is no guarantee that equally or > similarly named locales behave the same. There will necessarily be a user- > beware factor here, and perhaps blowing up when the locale name is not > recognized is safer and alerts about this fact better than trying to make it > match by force somehow. We have never before operated on the assumption that it's okay for pg_dump output to be locked to particular platforms, and I do not think we should start now. So we've got to do *something* about this. (Do you really want PG Windows users to be unable to port to a better platform?) I note also that the problem is in pg_dumpall not pg_dump, so pg_restore is not going to help us --- if someone has a problem his only recourse would be manual editing of a possibly-monstrous SQL script file. 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] Serializable Isolation without blocking
On Fri, May 8, 2009 at 4:12 PM, Greg Stark wrote: > On Fri, May 8, 2009 at 3:49 PM, Kevin Grittner > wrote: >> Greg Stark wrote: >> >>> Well I don't understand what storing locks in an index can >>> accomplish if other queries might use other indexes or sequential >>> scans to access the records and never see those locks. >>> >>> Or does this method only require that writers discover the locks and >>> therefore only writers can ever fail due to serialization failures >>> they cause? >> >> Well, readers don't need to find the SIREAD locks which readers set. >> Conflicts between writers are handled the same as current PostgreSQL >> techniques. Readers need to look for write locks, and writers need to >> look for SIREAD locks. > > > Well this is where I'm failing to follow. If readers need to be sure > they'll find write locks then surely they can't be stored in indexes > without losing any flexibility. Argh, sorry, as soon as I hit send I realized this is wrong. Writers already need to insert into every index, so that's not a problem. The problem is if readers need to see other reader locks. If that's not true then I guess I'm all wet and I will wait until I read the paper. -- greg -- 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] Serializable Isolation without blocking
Greg Stark wrote: > Well I don't understand what storing locks in an index can > accomplish if other queries might use other indexes or sequential > scans to access the records and never see those locks. > > Or does this method only require that writers discover the locks and > therefore only writers can ever fail due to serialization failures > they cause? Well, readers don't need to find the SIREAD locks which readers set. Conflicts between writers are handled the same as current PostgreSQL techniques. Readers need to look for write locks, and writers need to look for SIREAD locks. Neither is blocked by the other, but finding a conflict sets both transactions with a directional "edge" boolean flag. (So we would need to track two booleans per transaction in addition to the new SIREAD locks.) When a transaction reaches a state where both "edge" booleans are set, one of the two transactions involved in setting that must be rolled back. The prototype implementation in the Berkeley DB preferred to roll back a "pivot" transaction (one with both edges set) where possible, so the failure would probably usually be on a transaction which modified data, but not necessarily -- if the writers involved have committed and the reader transaction might see an invalid database state, the reader would be rolled back. > I still haven't actually read the paper so I should probably bow out > from the conversation until I do. I was apparently already under > one misapprehension as Laurenz just claimed the paper does not show > how to prevent "phantoms" (phantom reads I assume?). Perhaps it's > not as ambitious as achieving true serializability after all? It does achieve true serializability in terms of the definitions I've read, although I've discovered at least one way in which its guarantees aren't as strong as traditional blocking techniques -- it doesn't guarantee that transactions at a level less strict than serializable will see a state which would exist between some serial execution of serializable transactions which modify the data, as the blocking schemes do. As I said in an earlier post, I'm OK with that, personally. We should probably document it as a difference, to alert someone converting, but the standard doesn't seem to require the behavior that traditional blocking approaches provide on this point. -Kevin -- 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] cs_CZ vs regression tests, part N+1
Zdenek Kotala wrote: Dne 24.04.09 07:17, Heikki Linnakangas napsal(a): This diff in tsearch2.out surprised me: @@ -2390,7 +2390,7 @@ Sea view wow foo bar qq http://www.google.com/foo.bar.html"; target="_blank">YES - ff-bg + ff-bg document.write(15); Any idea what's causing that? Hmm. I don't understand it. I'm not able to generate this again nad I don't have idea why it happend. It is definitely wrong. Shell I sent you new diff or do you fix it yourself? Committed, without that mystery change. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- 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] Serializable Isolation without blocking
"Albe Laurenz" wrote: > As far as I know, only the table rows that are found in the index > scan are examined for visibility. Which would be only one in my > example. S2PL locking schemes routinely use index range locks. > But in your attempt to sketch a way how true serializability could > be implemented, you went beyond the scope of the original paper, > which does not claim to tackle "phantoms". It doesn't put forward techniques to tackle that, apparently considering the issues to be so well-known and obvious as to not require more than a brief mention. They have a section titled "Phantoms": >> Throughout the discussion so far, we have followed typi- >> cal concurrency control theory and assumed that a transac- >> tion is a sequence of reads and writes on named data items. >> In general, a relational database engine must also deal with >> predicate operations (such as SQL *where* clauses). These >> mean that a concurrency control algorithm must also con- >> sider phantoms, where an item created or deleted in one >> transaction would change the result of a predicate operation >> in a concurrent transaction if the two transactions executed >> serially. The solution used in traditional two-phase locking >> is multigranularity locking, where a predicate operation >> takes intention locks on larger units, such as pages or ta- >> bles, to prevent insertion of records that might match the >> predicate. > As you mentioned in your first post, there will not be a free lunch. > What hurts concurrency in an implementation with blocking read locks > might also hurt concurrency in an implementation where transactions > are frequently aborted and have to be retried. Possibly; although the benchmarks published in the paper show much better throughput than traditional blocking techniques with long and high-conflict transactions. Eyeballing the graph (based on 20 concurrent sessions), blocking techniques got a 2% deadlock rate in this benchmark, snapshot isolation got a 2.6% update conflict rate, and the technique published in the paper got a 0.1% update conflict rate plus another 7.2% snapshot unsafe rate. Oddly, in spite of a serialization failure rate of 7.3% versus snapshot isolation's 2.6%, the performance of the new technique edged out snapshot isolation when the number of connections was 35 or higher. I assume that is because the rollbacks and restarts somehow reduced thrashing. The traditional serializable techniques started to drop below the non-blocking techniques at about 10 concurrent sessions, and performance kept dropping from that point while the non-blocking performance continued to rise all the way to 50. -Kevin -- 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] Serializable Isolation without blocking
On Fri, May 8, 2009 at 3:00 PM, Kevin Grittner wrote: > Greg Stark wrote: >> On Thu, May 7, 2009 at 11:08 PM, Kevin Grittner >> wrote: >>> I would assume that SELECT shown above would either resolve to a >>> table scan, in which case you would have to have an SIREAD lock at >>> the table level >> >> That sounds like we're back to the MSSQL/Sybase way of doing things > > Other than not blocking, I suppose. > >> where you have to understand the query plan to understand why you're >> getting spurious serialization failures. > > You have to know a lot more than that to solve serialization problems > in PostgreSQL with current techniques. Well you have to understand how Postgres locks work, but that's an invariant. You don't have to know how Postgres is going to plan your specific queries -- which you can't ever be sure of since it could change as the data changes. >> I don't think that's terribly appealing. Consider, for example, that >> we might not *want* to do an index scan just because there's an >> index. > > Someone more familiar than I with S2PL would be better able to > respond, but I *think* you just need to track this on whatever path > is actually chosen, not on all possible paths. Well I don't understand what storing locks in an index can accomplish if other queries might use other indexes or sequential scans to access the records and never see those locks. Or does this method only require that writers discover the locks and therefore only writers can ever fail due to serialization failures they cause? I still haven't actually read the paper so I should probably bow out from the conversation until I do. I was apparently already under one misapprehension as Laurenz just claimed the paper does not show how to prevent "phantoms" (phantom reads I assume?). Perhaps it's not as ambitious as achieving true serializability after all? -- greg -- 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] Serializable Isolation without blocking
On Fri, May 8, 2009 at 3:00 PM, Kevin Grittner wrote: > >> I've removed the broken email address for now -- please re-add the >> correct email address. > > I'll see what I can find. When I last corresponded with him, he was > still at the University of Sidney, working on his PhD by applying > these techniques to InnoDB. He specified that email address for > copying him when I opened the dialog. I don't think either of us > expected it to take this long for PostgreSQL to get to beta so that I > could do so. He said that when that was complete, he would be working > full-time for Oracle, so he's probably moved on to a new location and > this email address has gone stale. I'll see what I can track down. For what it's worth I don't think this address has gone stale, I think someone just got the email address messed up when adding it manually. The address that was in the headers before was: "Michael Cahill mjc"@it.usyd.edu.au Whereas I suspect the right address was: "Michael Cahill" m...@it.usyd.edu.au I'll add that on my followups, if others could do the same rif they're responding to a message where he isn't he should end up back on all the responses. -- greg -- 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] Serializable Isolation without blocking
Greg Stark wrote: > On Thu, May 7, 2009 at 11:08 PM, Kevin Grittner > wrote: >> I would assume that SELECT shown above would either resolve to a >> table scan, in which case you would have to have an SIREAD lock at >> the table level > > That sounds like we're back to the MSSQL/Sybase way of doing things Other than not blocking, I suppose. > where you have to understand the query plan to understand why you're > getting spurious serialization failures. You have to know a lot more than that to solve serialization problems in PostgreSQL with current techniques. > I don't think that's terribly appealing. Consider, for example, that > we might not *want* to do an index scan just because there's an > index. Someone more familiar than I with S2PL would be better able to respond, but I *think* you just need to track this on whatever path is actually chosen, not on all possible paths. > Or there could be multiple indexes on the function, we definitely > wouldn't want to have to check for range locks on every index. Agreed. And I don't think we have to. > We have to think outside of the box and get away from the > pre-existing implementations which have solutions which aren't > really applicable. Well, this paper is well outside the box in many respects, although it still does use well-worn techniques for some portions of the processing. If PostgreSQL developers can expand on that with their own innovations, fantastic! > If we were to look at doing predicate locks in any way they would > probably be stored in a whole new data structure, not related to the > indexes on the table. We would need some way to index them so that > we can look for conflicting locks efficiently independently from the > query plan and table access methods. That might burden this with much worse performance. I think that the reason most products *do* base it on the actual rows, blocks, or tables referenced is that it gives the needed behaviors with good performance. Like I said, if we want to combine the innovations in the paper with something clever and new in the predicate locking area, OK -- as long as that isn't the cause for sinking the part that can already be shown to work. > I've removed the broken email address for now -- please re-add the > correct email address. I'll see what I can find. When I last corresponded with him, he was still at the University of Sidney, working on his PhD by applying these techniques to InnoDB. He specified that email address for copying him when I opened the dialog. I don't think either of us expected it to take this long for PostgreSQL to get to beta so that I could do so. He said that when that was complete, he would be working full-time for Oracle, so he's probably moved on to a new location and this email address has gone stale. I'll see what I can track down. -Kevin -- 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] Some 8.4 changes needed according to pg_migrator testing
On Thursday 07 May 2009 20:54:37 Alvaro Herrera wrote: > I don't think there's much we can do apart from telling the user not to > move stuff across platforms that do not have equally named locales. The other part of the problem is that there is no guarantee that equally or similarly named locales behave the same. There will necessarily be a user- beware factor here, and perhaps blowing up when the locale name is not recognized is safer and alerts about this fact better than trying to make it match by force somehow. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] WAL dump tool
Hi. Is the following todo item still necessary? Create dump tool for write-ahead logs for use in determining transaction id for point-in-time recovery. This is useful for checking PITR recovery. If so, I want to make it. What is the expected output of the dump tool? TransactionId, TimeLineID and ? Best regards, - MINOWA Taro (Higepon) Cybozu Labs, Inc. http://www.monaos.org/ http://code.google.com/p/mosh-scheme/ -- 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] Extra cost of "lossy mode" Bitmap Scan plan
Hi. > fashion --- for instance, each page is read only once. Index scan will > result in a random sequence of accesses to the heap. (Of course, it > might have some order if the index is well correlated with the heap > order, but most of the time that's not true.) Thank you. I finally understand the difference. Cheers. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
