Tom Dunstan wrote:
The Problem
-
One case that traditional SQL doesn't handle very well is when you have a
child entity which can be
attached to a number of different parent entities. Examples might be
comments, tags or file
attachments - we might have 20 different
On 12/02/2013 05:34 AM, Stephen Frost wrote:
* Jeff Davis (pg...@j-davis.com) wrote:
I see where you're coming from, but after some thought, and looking at
the patch, I think we really do want a catalog representation for (at
least some) extensions.
Perhaps I'm missing something- but we
On 12/02/2013 08:40 AM, Michael Paquier wrote:
The data replication bug causing data corruption on hot slaves found
lately (http://wiki.postgresql.org/wiki/Nov2013ReplicationIssue) is
causing a certain amount of damage among the users of Postgres, either
companies or individuals, and impacts a
On 12/01/2013 10:40 PM, Jeff Janes wrote:
On Wed, Nov 27, 2013 at 9:40 AM, Jeff Janes jeff.ja...@gmail.com wrote:
The commit 04eee1fa9ee80dabf7 of this series causes a self-deadlock in the
LWLock code during the operation below, with it trying to take
an LW_EXCLUSIVE on a high, even-numbered
On 2013-12-02 11:07:28 +0200, Heikki Linnakangas wrote:
Perhaps I'm missing something- but we already *have* a catalog
representation for every extension that's ever installed into a given
database. A representation that's a heck of a lot better than a big
text blob.
Right. I think Jeff
On Mon, Dec 2, 2013 at 6:24 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
+1. The need for such a test suite has been mentioned every single time that
a bug or new feature related to replication, PITR or hot standby has come
up. So yes please! The only thing missing is someone to
On 2013-12-02 08:57:01 +, Albe Laurenz wrote:
What strikes me is that since foreign key constraints are implemented
as triggers in PostgreSQL, this solution would probably not have many
performance benefits over a self-written trigger that implements the
same functionality. Since you need
On 2013-12-02 18:45:37 +0900, Michael Paquier wrote:
On Mon, Dec 2, 2013 at 6:24 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
+1. The need for such a test suite has been mentioned every single time that
a bug or new feature related to replication, PITR or hot standby has come
up.
Hi, Tom san,
From: Tom Lane t...@sss.pgh.pa.us
I've committed this with some editorialization (mostly, I used a case
statement not a constant array, because that's more like the other places
that switch on errnos in this file).
As I said, lack of %m string has been making troubleshooting
On 2013-12-02 19:36:01 +0900, MauMau wrote:
I'll be glad if you could back-port this. Personally, in practice, 9.1 and
later will be sufficient.
Already happened:
Author: Tom Lane t...@sss.pgh.pa.us
Branch: REL9_3_STABLE [e3480438e] 2013-11-07 16:33:18 -0500
Branch: REL9_2_STABLE [64f5962fe]
Heikki Linnakangas hlinnakan...@vmware.com writes:
Right. I think Jeff was thinking of a catalog representation for extensions
that haven't been installed yet, but are available in the system and could
be installed with CREATE EXTENSION foo. I wouldn't mind having a catalog
like that. Even
On Mon, Dec 2, 2013 at 7:07 PM, Andres Freund and...@2ndquadrant.com wrote:
Maybe that it shouldn't be part of the main regression schedule...
Yes, like isolation tests, it don't see those new tests in the main
flow as well.
+many from me as well. I think the big battle will be how to do it,
On Dec2, 2013, at 10:06 , Andres Freund and...@2ndquadrant.com wrote:
On 2013-12-02 08:57:01 +, Albe Laurenz wrote:
What strikes me is that since foreign key constraints are implemented
as triggers in PostgreSQL, this solution would probably not have many
performance benefits over a
On Mon, Dec 2, 2013 at 4:56 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-12-01 18:56:19 -0500, Tom Lane wrote:
I'd like to do any required editing on the notes at this stage,
before I start extracting relevant subsets for the older branches.
On 2013-12-02 12:10:32 +, Florian Pflug wrote:
On Dec2, 2013, at 10:06 , Andres Freund and...@2ndquadrant.com wrote:
On 2013-12-02 08:57:01 +, Albe Laurenz wrote:
What strikes me is that since foreign key constraints are implemented
as triggers in PostgreSQL, this solution would
Hi Laurenz!
On 2 Dec 2013, at 19:27, Albe Laurenz laurenz.a...@wien.gv.at wrote:
What strikes me is that since foreign key constraints are implemented
as triggers in PostgreSQL, this solution would probably not have many
performance benefits over a self-written trigger that implements the
Hi, Bruce san,
From: Bruce Momjian br...@momjian.us
On Tue, Aug 6, 2013 at 12:09:53PM -0400, Tom Lane wrote:
Yes. I don't see any reason to change it, either, as nobody has
complained that it's actually bad. If you feel a compulsion to
change the docs, do that.
OK, seems 'Postgres' is a
Hi,
I am reviewing your patch.
2013-10-10 15:32 keltezéssel, Antonin Houska írta:
On 10/09/2013 08:56 PM, Robert Haas wrote:
There seem to be several review comments made since you posted this
version. I'll mark this Waiting on Author in the CommitFest
application, since it seems that the
Stephen Frost sfr...@snowman.net writes:
Having a versioning notion (and whatever other meta data we, or an
extension author, feels is useful) for what are otherwise simple containers
(aka the schematic we already have..) makes sense and it would be great to
provide support around that,
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
Right. I think Jeff was thinking of a catalog representation for
extensions that haven't been installed yet, but are available in the
system and could be installed with CREATE EXTENSION foo.
I really don't particularly see value in this
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
There should be no difference between file-based extensions and
catalog-based extensions. It's just two different ways to install the same
extension. The extension author doesn't need to care about that, it's the
DBA that decides which
Stephen Frost sfr...@snowman.net writes:
What is the next step to allow an extension pulled down from pgxn to be
installed, unchanged, into a given database?
An extension packaging system.
Unchanged is not a goal, and not possible even today.
PGXN is a *source based* packaging system. You
On Mon, Dec 2, 2013 at 7:40 PM, Haribabu kommi
haribabu.ko...@huawei.com wrote:
On 29 November 2013 03:05 Robert Haas wrote:
On Wed, Nov 27, 2013 at 9:31 AM, Amit Kapila amit.kapil...@gmail.com
wrote:
I tried modifying the existing patch to support the dynamic rollup as follows.
For every 32
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Stephen Frost sfr...@snowman.net writes:
*That doesn't make this approach the right one*. If anything, I'm
afraid we've ended up building ourselves a rube goldberg machine because
of this constant struggle to fit a square peg into a round
Andres Freund and...@2ndquadrant.com writes:
Maybe that it shouldn't be part of the main regression schedule...
It *can't* be part of the main regression tests; those are supposed to
be runnable against an already-installed server, and fooling with that
server's configuration is off-limits too.
Hi all,
I am a newbie. I am unable to understand the to do statement given below.
Add full object name to the tag field. eg. for operators we need
'=(integer, integer)', instead of just '='.
please help me out with an example.
Thanks and Regards,
*Asit Mahato*
On 2013-12-02 09:41:39 -0500, Tom Lane wrote:
At the same time, I'm pretty skeptical that any simple regression-test
type facility would have caught the bugs we've fixed lately ...
Agreed, but it would make reorganizing stuff to be more robust more
realistic. At the moment for everything you
Andres Freund and...@2ndquadrant.com writes:
I think we also needs support for testing xid/multixid wraparound. It
currently isn't realistically testable because of the timeframes
involved.
When I've wanted to do that in the past, I've used pg_resetxlog to
adjust a cluster's counters. It
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Stephen Frost sfr...@snowman.net writes:
What is the next step to allow an extension pulled down from pgxn to be
installed, unchanged, into a given database?
An extension packaging system.
Unchanged is not a goal, and not possible even
On 12/02/2013 04:14 PM, Dimitri Fontaine wrote:
Stephen Frost sfr...@snowman.net writes:
What is the next step to allow an extension pulled down from pgxn to be
installed, unchanged, into a given database?
An extension packaging system.
Unchanged is not a goal, and not possible even today.
Stephen Frost sfr...@snowman.net writes:
Clearly we need the information from the extension package (the scripts
which are on the PG server's filesystem today, but need not be in the
future) but that doesn't mean we need to keep those text blobs in the
catalog.
So, I guess it would have been
On 12/02/2013 05:06 AM, Andres Freund wrote:
On 2013-12-02 08:57:01 +, Albe Laurenz wrote:
What strikes me is that since foreign key constraints are implemented
as triggers in PostgreSQL, this solution would probably not have many
performance benefits over a self-written trigger that
Stephen Frost sfr...@snowman.net writes:
Fine- so we need a step that goes from 'source' to 'built'. I don't see
that step being done in or by a PG backend process. Adding a new option
which can take a pgxn source and build a script from it which can be run
against PG via libpq is what I'd
Heikki Linnakangas hlinnakan...@vmware.com writes:
I fear we're wandering off the point again. So let me repeat: It must be
possible to install the same extension the way you do today, and using the
new mechanism.
The way you do today is running make install or apt-get install or
something
Stephen Frost sfr...@snowman.net writes:
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Then as soon as we are able to CREATE EXTENSION mystuff; without ever
pre-installing files on the file system as root, then we would like to
be able to do just that even with binary modules.
I really
Sergey Burladyan eshkin...@gmail.com writes:
Is it possible to fix my surname in changelog?
-Sergey Burladyn
+Sergey Burladyan
Oh, sorry about that! I can't do anything about the typo in the commit
log, but certainly we can get it right in the release notes.
regards,
Tom Lane t...@sss.pgh.pa.us writes:
Stephen Frost sfr...@snowman.net writes:
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Then as soon as we are able to CREATE EXTENSION mystuff; without ever
pre-installing files on the file system as root, then we would like to
be able to do just that
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Stephen Frost sfr...@snowman.net writes:
Clearly we need the information from the extension package (the scripts
which are on the PG server's filesystem today, but need not be in the
future) but that doesn't mean we need to keep those text
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Stephen Frost sfr...@snowman.net writes:
Fine- so we need a step that goes from 'source' to 'built'. I don't see
that step being done in or by a PG backend process. Adding a new option
which can take a pgxn source and build a script from
Stephen Frost sfr...@snowman.net writes:
On the other hand, I can appreciate the concern that we don't really
want a dump/restore to include the extension definition when it's
already on the filesystem. That said, it amazes me that we don't
include the version # of the extension in pg_dump's
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Tom Lane t...@sss.pgh.pa.us writes:
Yes, exactly. What's more, you're going to face huge push-back from
vendors who are concerned about security (which is most of them).
Last time I talked with vendors, they were working in the Open Shift
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
So when you pg_dump | pg_restore from 9.1 into 9.3, if pg_dump were to
be nitpicky about the version of hstore with the command
CREATE EXTENSION hstore VERSION '1.0';
What would happen is that pg_restore would fail.
That's just the
On Sat, Nov 30, 2013 at 2:00 PM, Bruce Momjian br...@momjian.us wrote:
On Wed, Mar 27, 2013 at 08:45:51AM -0400, Robert Haas wrote:
On Sat, Mar 23, 2013 at 6:38 PM, Xi Wang xi.w...@gmail.com wrote:
CHECK_STACK_DEPTH checks if errordata_stack_depth is negative.
Move the dereference of
On Sat, Nov 30, 2013 at 9:01 PM, Bruce Momjian br...@momjian.us wrote:
On Sun, Apr 7, 2013 at 12:14:29AM -0400, Robert Haas wrote:
On Thu, Apr 4, 2013 at 6:47 PM, Greg Jaskiewicz gryz...@me.com wrote:
Looking around the code Today, one of my helpful tools detected this dead
code.
As far
Stephen Frost sfr...@snowman.net writes:
I don't like the idea of having a pg_dump/restore mechanism that
intentionally tries to go out and install the latest version of whatever
extension was installed in the old DB by downloading it from PGXN,
building it, and then installing it... Is that
On Mon, Dec 2, 2013 at 12:54 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Thu, Nov 28, 2013 at 9:42 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
I attached new version patch which have modify typos and added
documentation patch.
The documentation part of patch is implemented
On Mon, Dec 2, 2013 at 9:49 AM, Asit Mahato rigid.a...@gmail.com wrote:
Hi all,
I am a newbie. I am unable to understand the to do statement given below.
Add full object name to the tag field. eg. for operators we need '=(integer,
integer)', instead of just '='.
please help me out with an
Tom Lane escribió:
When I've wanted to do that in the past, I've used pg_resetxlog to
adjust a cluster's counters. It still requires some manual hacking
though because pg_resetxlog isn't bright enough to create the new
pg_clog files needed when you move the xid counter a long way.
We could
On Sun, Dec 1, 2013 at 09:22:52AM +0100, Karsten Hilbert wrote:
On Sat, Nov 30, 2013 at 03:21:08PM -0800, Kevin Grittner wrote:
If your argument is that you want pg_upgrade to work even if the
user already turned on default_transaction_read_only in the *new*
cluster, I would humbly
On Mon, Dec 2, 2013 at 10:22:47PM +0900, MauMau wrote:
I'm sorry I didn't respond for a long time. I've come up with a suggestion.
The original reporter of this problem expected the output of the
date type in 'Postgres,DMY' style to be 17 Dec 1997, when the
output of the timestamp if Wed
On Mon, Dec 2, 2013 at 10:04 AM, Andrew Dunstan and...@dunslane.net wrote:
The only way I have thought of as an alternative to this proposal is to use
a partitioned table with different FK constraints for each child. That's
certainly doable, but not without a deal of work, and even then you'd
Andres Freund and...@2ndquadrant.com writes:
On 2013-12-01 18:56:19 -0500, Tom Lane wrote:
* is it useful to go into more detail than this about the data corruption
bugs? It's not clear to me that we can say more than vacuum and re-clone
your standbys as far as recovery actions go, at least
On Mon, Dec 2, 2013 at 1:26 AM, Heikki Linnakangas
hlinnakan...@vmware.comwrote:
On 12/01/2013 10:40 PM, Jeff Janes wrote:
On Wed, Nov 27, 2013 at 9:40 AM, Jeff Janes jeff.ja...@gmail.com wrote:
The commit 04eee1fa9ee80dabf7 of this series causes a self-deadlock in
the
LWLock code during
On Sat, Nov 30, 2013 at 12:10:19PM -0500, Bruce Momjian wrote:
Drat, you're quite right. I've always included the full certificate
chain in client certs but it's in no way required.
I guess that pretty much means maintaining the status quo and documenting
it better.
I have developed
On Fri, Nov 29, 2013 at 01:19:54PM -0500, Bruce Momjian wrote:
On Fri, Nov 29, 2013 at 01:05:20PM -0500, Bruce Momjian wrote:
On Fri, Nov 29, 2013 at 12:27:49AM -0500, Robert Haas wrote:
On Thu, Nov 28, 2013 at 11:04 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
David Johnston
On Mon, Dec 02, 2013 at 11:41:10AM -0500, Bruce Momjian wrote:
If there were databases or users with default_transaction_read_only
set in the old cluster, the pg_dumpall run will cause that property
to be set in the new cluster, so what you are saying seems to be
that a cluster can't
On 2013-12-02 12:26:25 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
I think it might be worth mentioning that (parts) of the data are
potentially recoverable without too much effort in all of the bugs.
I thought about that but was afraid that it'd come off like a
Bruce Momjian br...@momjian.us writes:
I have updated the patch, attached, to be clearer about the requirement
that intermediate certificates need a chain to root certificates.
I see that you removed the sentence
The root
certificate should be included in every case where
On Dec 2, 2013, at 6:14 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Whether you're targetting a file system template or a catalog template,
PGXN is not a complete solution, you still need to build the extension.
This is true today, but only because PostgreSQL provides the infrastructure
On Mon, Dec 2, 2013 at 06:57:53PM +0100, Karsten Hilbert wrote:
On Mon, Dec 02, 2013 at 11:41:10AM -0500, Bruce Momjian wrote:
If there were databases or users with default_transaction_read_only
set in the old cluster, the pg_dumpall run will cause that property
to be set in the
On 2013-12-02 09:59:12 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
I think we also needs support for testing xid/multixid wraparound. It
currently isn't realistically testable because of the timeframes
involved.
When I've wanted to do that in the past, I've used
On Mon, Dec 2, 2013 at 10:13 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
I fear we're wandering off the point again. So let me repeat: It must be
possible to install the same extension the way you do today, and using the
new mechanism.
On Mon, Dec 02, 2013 at 01:24:18PM -0500, Bruce Momjian wrote:
If there were databases or users with default_transaction_read_only
set in the old cluster, the pg_dumpall run will cause that property
to be set in the new cluster, so what you are saying seems to be
that a
On Sun, 2013-12-01 at 22:34 -0500, Stephen Frost wrote:
Perhaps I'm missing something- but we already *have* a catalog
representation for every extension that's ever installed into a given
database. A representation that's a heck of a lot better than a big
text blob.
I meant extension
On 02 Dec 2013, at 01:56, Tom Lane t...@sss.pgh.pa.us wrote:
* any other items that need to be corrected or expanded?
I think 2103430 (Fix parsing of xlog file name in pg_receivexlog) is worth
mentioning,
as all past pg_receivexlog 9.3.x versions fail to resume interrupted streaming
after
Tom,
The issue can be ameliorated by, after upgrading, vacuuming all tables
in all databases while having vacuum_freeze_table_age set to zero.
Why not say:
This issue can be ameliorated by, after upgrading, running a
database-wide VACUUM FREEZE.
Or is there a difference in this case? If so,
On 2013-12-02 10:51:28 -0800, Josh Berkus wrote:
Tom,
The issue can be ameliorated by, after upgrading, vacuuming all tables
in all databases while having vacuum_freeze_table_age set to zero.
Why not say:
This issue can be ameliorated by, after upgrading, running a
database-wide
Mika Eloranta m...@ohmu.fi writes:
On 02 Dec 2013, at 01:56, Tom Lane t...@sss.pgh.pa.us wrote:
* any other items that need to be corrected or expanded?
I think 2103430 (Fix parsing of xlog file name in pg_receivexlog) is worth
mentioning,
as all past pg_receivexlog 9.3.x versions fail to
On Mon, Dec 2, 2013 at 6:30 PM, Robert Haas robertmh...@gmail.com wrote:
OK, I'll bite. I've been trying to stay out of this thread, but I
really *don't* understand what this patch is about. Extensions, as
they exist today, are installed from the filesystem and their contents
are not dumped.
Dean Rasheed escribió:
+/*
+ * If a schema was explicitly specified, test if it exists. If it does not,
+ * report the schema as missing rather than the child object.
+ */
+static bool
+schema_does_not_exist_skipping(List *objname,
+
On Mon, Dec 2, 2013 at 12:59:41PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I have updated the patch, attached, to be clearer about the requirement
that intermediate certificates need a chain to root certificates.
I see that you removed the sentence
The root
On Mon, Dec 2, 2013 at 2:33 PM, Greg Stark st...@mit.edu wrote:
On Mon, Dec 2, 2013 at 6:30 PM, Robert Haas robertmh...@gmail.com wrote:
OK, I'll bite. I've been trying to stay out of this thread, but I
really *don't* understand what this patch is about. Extensions, as
they exist today, are
Greg Stark st...@mit.edu writes:
On Mon, Dec 2, 2013 at 6:30 PM, Robert Haas robertmh...@gmail.com wrote:
OK, I'll bite. I've been trying to stay out of this thread, but I
really *don't* understand what this patch is about. Extensions, as
Thanks!
they exist today, are installed from the
On 12/02/2013 02:45 PM, Bruce Momjian wrote:
On Mon, Dec 2, 2013 at 12:59:41PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I have updated the patch, attached, to be clearer about the requirement
that intermediate certificates need a chain to root certificates.
I see that
Bruce Momjian br...@momjian.us writes:
On Mon, Dec 2, 2013 at 12:59:41PM -0500, Tom Lane wrote:
I see that you removed the sentence
The root
certificate should be included in every case where
filenamepostgresql.crt/ contains more than one certificate.
I don't fully understand the issues
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Stephen Frost sfr...@snowman.net writes:
I don't like the idea of having a pg_dump/restore mechanism that
intentionally tries to go out and install the latest version of whatever
extension was installed in the old DB by downloading it from
David,
* David E. Wheeler (da...@justatheory.com) wrote:
On Dec 2, 2013, at 6:14 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Whether you're targetting a file system template or a catalog template,
PGXN is not a complete solution, you still need to build the extension.
This is
On 12/02/2013 02:01 PM, Andrew Dunstan wrote:
AIUI, you need a complete chain from one end to the other. So the cert
being checked can include the intermediate cert in what it sends, or it
can be in the root.crt at the other end, but one way or another, the
checking end needs a complete chain
On 2 December 2013 19:37, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Dean Rasheed escribió:
+/*
+ * If a schema was explicitly specified, test if it exists. If it does not,
+ * report the schema as missing rather than the child object.
+ */
+static bool
Stephen Frost sfr...@snowman.net writes:
* David E. Wheeler (da...@justatheory.com) wrote:
This is true today, but only because PostgreSQL provides the
infrastructure for building and installing extensions that entails `make
make install`. If Postgres provided some other method of building
Ian Pilcher arequip...@gmail.com writes:
Yes. And the problem is that there is no way to prevent OpenSSL from
accepting intermediate certificates supplied by the client. As a
result, the server cannot accept client certificates signed by one
intermediate CA without also accepting *any*
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
Problem solved! The only downside is that the use of this facility
would have to be restricted to superusers, but the current consensus
on this thread is that we should restrict *this* facility to
superusers also, so we're not really
Stephen Frost sfr...@snowman.net writes:
What I've been trying to point out is that there's absolutely zero need
for the 'extension template' part of this to make a pg_restore work for
an entirely-in-the-catalog extension. I realize that's how you've done
it with this patch set but that
On 12/02/2013 02:17 PM, Tom Lane wrote:
Ian Pilcher arequip...@gmail.com writes:
Yes. And the problem is that there is no way to prevent OpenSSL from
accepting intermediate certificates supplied by the client. As a
result, the server cannot accept client certificates signed by one
Dean Rasheed escribió:
I think that memory gets freed at the end of the DROP command, so I
don't think this is a concern. In any case, that RangeVar is only of
order 50 bytes. If we were concerned about memory leakage here, a
bigger concern would be the calling code in
* Jeff Davis (pg...@j-davis.com) wrote:
On Sun, 2013-12-01 at 22:34 -0500, Stephen Frost wrote:
Perhaps I'm missing something- but we already *have* a catalog
representation for every extension that's ever installed into a given
database. A representation that's a heck of a lot better than
On 12/02/2013 03:21 PM, Ian Pilcher wrote:
On 12/02/2013 02:17 PM, Tom Lane wrote:
Ian Pilcher arequip...@gmail.com writes:
Yes. And the problem is that there is no way to prevent OpenSSL from
accepting intermediate certificates supplied by the client. As a
result, the server cannot accept
Ian Pilcher arequip...@gmail.com writes:
On 12/02/2013 02:17 PM, Tom Lane wrote:
Isn't that sort of the point?
I'm not sure what you're asking. The desired behavior (IMO) would be to
accept client certificates signed by some intermediate CAs without
accepting any client certificate that can
On Mon, Dec 2, 2013 at 3:02 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Greg Stark st...@mit.edu writes:
On Mon, Dec 2, 2013 at 6:30 PM, Robert Haas robertmh...@gmail.com wrote:
OK, I'll bite. I've been trying to stay out of this thread, but I
really *don't* understand what this patch
On Mon, Dec 2, 2013 at 03:01:25PM -0500, Andrew Dunstan wrote:
I don't fully understand the issues but the discussion seens to indicate
this. Am I missing something? Should I run some tests?
AIUI, you need a complete chain from one end to the other. So the
cert being checked can include
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Stephen Frost sfr...@snowman.net writes:
What I've been trying to point out is that there's absolutely zero need
for the 'extension template' part of this to make a pg_restore work for
an entirely-in-the-catalog extension. I realize that's
Bruce Momjian br...@momjian.us writes:
Yes, this was my understanding. Let me ask a simple question --- can
you put only the client cert on the client (postgresql.crt) and only the
root cert on the server (root.crt), and will it work?
Yes, that's surely always worked.
I think Tom's question
On Mon, Dec 2, 2013 at 03:07:48PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Mon, Dec 2, 2013 at 12:59:41PM -0500, Tom Lane wrote:
I see that you removed the sentence
The root
certificate should be included in every case where
filenamepostgresql.crt/ contains
* Ian Pilcher (arequip...@gmail.com) wrote:
On 12/02/2013 02:17 PM, Tom Lane wrote:
Ian Pilcher arequip...@gmail.com writes:
Yes. And the problem is that there is no way to prevent OpenSSL from
accepting intermediate certificates supplied by the client. As a
result, the server cannot
On 12/02/2013 03:44 PM, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Let me ask a simple question --- can
you put only the client cert on the client (postgresql.crt) and only the
root cert on the server (root.crt), and will it work?
Yes, that's surely always worked.
Not if the
On Mon, Dec 2, 2013 at 03:44:18PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Yes, this was my understanding. Let me ask a simple question --- can
you put only the client cert on the client (postgresql.crt) and only the
root cert on the server (root.crt), and will it
On Mon, Dec 2, 2013 at 03:57:45PM -0500, Andrew Dunstan wrote:
On 12/02/2013 03:44 PM, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Let me ask a simple question --- can
you put only the client cert on the client (postgresql.crt) and only the
root cert on the server (root.crt),
* Bruce Momjian (br...@momjian.us) wrote:
Yes, this was my understanding. Let me ask a simple question --- can
you put only the client cert on the client (postgresql.crt) and only the
root cert on the server (root.crt), and will it work?
Only if the client cert is signed directly by the root
* Bruce Momjian (br...@momjian.us) wrote:
On Mon, Dec 2, 2013 at 03:57:45PM -0500, Andrew Dunstan wrote:
On 12/02/2013 03:44 PM, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Let me ask a simple question --- can
you put only the client cert on the client (postgresql.crt) and
On 12/02/2013 02:29 PM, Andrew Dunstan wrote:
Wouldn't that amount to only partially trusting the root? It seems kinda
odd. In any case, It's not something I think Postgres needs to solve.
I think that the fundamental problem is that authentication and
authorization are being conflated. From
1 - 100 of 151 matches
Mail list logo
