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 e
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 alread
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 lo
On 12/01/2013 10:40 PM, Jeff Janes wrote:
On Wed, Nov 27, 2013 at 9:40 AM, Jeff Janes 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 lockid when it already
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 thin
On Mon, Dec 2, 2013 at 6:24 PM, Heikki Linnakangas
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 actually write the
> thing.
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 n
On 2013-12-02 18:45:37 +0900, Michael Paquier wrote:
> On Mon, Dec 2, 2013 at 6:24 PM, Heikki Linnakangas
> 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! T
Hi, Tom san,
From: "Tom Lane"
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 difficult,
so I
wish
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
Branch: REL9_3_STABLE [e3480438e] 2013-11-07 16:33:18 -0500
Branch: REL9_2_STABLE [64f5962fe] 2013-11-07 16:33:
Heikki Linnakangas 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 without any of this ext
On Mon, Dec 2, 2013 at 7:07 PM, Andres Freund 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, not
> if in general.
Ye
On Dec2, 2013, at 10:06 , 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 t
On Mon, Dec 2, 2013 at 4:56 AM, Tom Lane wrote:
> Andres Freund 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.
>
> > When do you plan to backpat
On 2013-12-02 12:10:32 +, Florian Pflug wrote:
> On Dec2, 2013, at 10:06 , 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
Hi Laurenz!
On 2 Dec 2013, at 19:27, 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. Si
Hi, Bruce san,
From: "Bruce Momjian"
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 unique output fo
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 pat
Stephen Frost 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, but not t
* 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 u
* 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 wh
Stephen Frost 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 can't just install w
On Mon, Dec 2, 2013 at 7:40 PM, Haribabu kommi
wrote:
> On 29 November 2013 03:05 Robert Haas wrote:
>> On Wed, Nov 27, 2013 at 9:31 AM, Amit Kapila
>> wrote:
>
> I tried modifying the existing patch to support the dynamic rollup as follows.
> For every 32 bytes mismatch between the old and new t
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Stephen Frost 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 hole.
>
> T
Andres Freund 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. But I agree that some
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 c
Andres Freund 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 still requires some manu
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Stephen Frost 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.
I'
On 12/02/2013 04:14 PM, Dimitri Fontaine wrote:
Stephen Frost 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 b
Stephen Frost 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 good to hear ab
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 implem
Stephen Frost 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 be going for- bu
Heikki Linnakangas 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 else to write files in t
Stephen Frost 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 just don't
Sergey Burladyan 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
--
Se
Tom Lane writes:
> Stephen Frost 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.
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Stephen Frost 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
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Stephen Frost 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
Stephen Frost 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 'CREATE EXTENSI
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Tom Lane 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
> team at R
* 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
On Sat, Nov 30, 2013 at 2:00 PM, Bruce Momjian 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 wrote:
>> > CHECK_STACK_DEPTH checks if errordata_stack_depth is negative.
>> > Move the dereference of &errordata[errordata_stack_depth
On Sat, Nov 30, 2013 at 9:01 PM, Bruce Momjian 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 wrote:
>> > Looking around the code Today, one of my helpful tools detected this dead
>> > code.
>> > As far as I can see, it is
Stephen Frost 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 what people are
On Mon, Dec 2, 2013 at 12:54 AM, Michael Paquier
wrote:
> On Thu, Nov 28, 2013 at 9:42 PM, Sawada Masahiko
> wrote:
>> I attached new version patch which have modify typos and added
>> documentation patch.
>> The documentation part of patch is implemented by Samrat Revagade.
> Thanks for the new
On Mon, Dec 2, 2013 at 9:49 AM, Asit Mahato 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 example.
>
>
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 co
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
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
On Mon, Dec 2, 2013 at 10:04 AM, Andrew Dunstan 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 be
> giving up cer
Andres Freund 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 not within the
On Mon, Dec 2, 2013 at 1:26 AM, Heikki Linnakangas
wrote:
> On 12/01/2013 10:40 PM, Jeff Janes wrote:
>
>> On Wed, Nov 27, 2013 at 9:40 AM, Jeff Janes wrote:
>>
>> The commit 04eee1fa9ee80dabf7 of this series causes a self-deadlock in
>>> the
>>> LWLock code during the operation below, with it t
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
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
> > > wrote:
> > > > David Johnston 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 new cluster, so what you are saying seems to be
> > > that a clu
On 2013-12-02 12:26:25 -0500, Tom Lane wrote:
> Andres Freund 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 commercial
> for da
Bruce Momjian 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
postgresql.crt contains mor
On Dec 2, 2013, at 6:14 AM, Dimitri Fontaine 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 for
building and in
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
On 2013-12-02 09:59:12 -0500, Tom Lane wrote:
> Andres Freund 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
On Mon, Dec 2, 2013 at 10:13 AM, Dimitri Fontaine
wrote:
> Heikki Linnakangas 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 mak
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
> >
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 te
On 02 Dec 2013, at 01:56, Tom Lane 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 ~4 GiB
of xlogs ha
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 s
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
Mika Eloranta writes:
> On 02 Dec 2013, at 01:56, Tom Lane 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
> str
On Mon, Dec 2, 2013 at 6:30 PM, Robert Haas 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. You're trying to
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 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
>certifi
On Mon, Dec 2, 2013 at 2:33 PM, Greg Stark wrote:
> On Mon, Dec 2, 2013 at 6:30 PM, Robert Haas 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 filesyste
Greg Stark writes:
> On Mon, Dec 2, 2013 at 6:30 PM, Robert Haas 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 filesystem and their contents
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 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 se
Bruce Momjian 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
>> postgresql.crt contains more than one certificate.
> I don't fully understand the issues but the discussion
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Stephen Frost 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,
> > bu
David,
* David E. Wheeler (da...@justatheory.com) wrote:
> On Dec 2, 2013, at 6:14 AM, Dimitri Fontaine 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 on
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 cha
On 2 December 2013 19:37, Alvaro Herrera 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
>> +schema_does_not_exist_skipping(List *objn
Stephen Frost 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 and
>> insta
Ian Pilcher 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* client certificate tha
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 lo
Stephen Frost 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 doesn't make it nece
On 12/02/2013 02:17 PM, Tom Lane wrote:
> Ian Pilcher 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 witho
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 does_not_exist_skipp
* 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 bette
On 12/02/2013 03:21 PM, Ian Pilcher wrote:
On 12/02/2013 02:17 PM, Tom Lane wrote:
Ian Pilcher 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 s
Ian Pilcher 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 present a chai
On Mon, Dec 2, 2013 at 3:02 PM, Dimitri Fontaine wrote:
> Greg Stark writes:
>> On Mon, Dec 2, 2013 at 6:30 PM, Robert Haas 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,
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
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Stephen Frost 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
Bruce Momjian 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 is whether O
On Mon, Dec 2, 2013 at 03:07:48PM -0500, Tom Lane wrote:
> Bruce Momjian 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
> >> postgresql.crt contains more than one
* Ian Pilcher (arequip...@gmail.com) wrote:
> On 12/02/2013 02:17 PM, Tom Lane wrote:
> > Ian Pilcher 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 clie
On 12/02/2013 03:44 PM, Tom Lane wrote:
Bruce Momjian 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 client has been sign
On Mon, Dec 2, 2013 at 03:44:18PM -0500, Tom Lane wrote:
> Bruce Momjian 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?
>
> Ye
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 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 wi
* 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 roo
* 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 writes:
> > >>Let me ask a simple question --- can
> > >>you put only the client cert on the client (postgresql.crt) and o
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
