On Tue, Dec 3, 2013 at 3:30 PM, Sawada Masahiko wrote:
> On Tue, Dec 3, 2013 at 12:02 PM, Michael Paquier
> wrote:
>>> Indeed, I forgot this code path. Completing for
>>> saving the state and xlog_redo for replay would be enough.
>> Wait a minute, I retract this argument. By using this method a m
On Mon, 2013-12-02 at 11:07 +0200, Heikki Linnakangas wrote:
> On 12/02/2013 05:34 AM, Stephen Frost wrote:
> >>2. When 9.4 gets released, we need some solid advice for extension
> >> authors. If they have a native shared library, I assume we just tell
> >> them to keep using the file-based tem
On Sun, 2013-12-01 at 15:48 +0100, Dimitri Fontaine wrote:
> Jeff Davis writes:
> > I don't see why we are trying to accommodate a case where the author
> > doesn't offer enough full SQL scripts and offers broken downgrade
> > scripts; or why that case is different from offering broken upgrade
> >
On Tue, Dec 3, 2013 at 12:02 PM, Michael Paquier
wrote:
> On Tue, Dec 3, 2013 at 11:57 AM, Michael Paquier
> wrote:
>> On Tue, Dec 3, 2013 at 1:08 AM, Robert Haas wrote:
>>> Forcing it to be done only an initdb-time is excessive. I think you
>>> can just make it PGC_POSTMASTER and have it parti
On Mon, Dec 02, 2013 at 04:30:05PM -0500, Peter Eisentraut wrote:
> A note to reviewers participating in the commit fests: When you send a
> review of a patch, reply to the email that contains the patch. Do no
> start a new email thread like "Review of 'Some Patch'". This is
> important for seve
On Sat, Nov 30, 2013 at 01:06:09AM +, Alvaro Herrera wrote:
> Fix a couple of bugs in MultiXactId freezing
>
> Both heap_freeze_tuple() and heap_tuple_needs_freeze() neglected to look
> into a multixact to check the members against cutoff_xid.
> ! /*
> !
On Mon, Dec 02, 2013 at 08:56:03PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > ... I propose merely changing the syntax to "TABLE FOR ROWS (...)".
>
> Ugh :-(. Verbose and not exactly intuitive, I think. I don't like
> any of the other options you listed much better. Still, the idea of
> u
On Tue, Dec 03, 2013 at 11:15:36AM +0800, Craig Ringer wrote:
> On 11/28/2013 03:24 AM, David Fetter wrote:
> > WITH, or SRF, or whatever, the point is that we need to be able to
> > specify what we're sending--probably single opaque strings delimited
> > just as we do other strings--and what we mi
On 3 Dec 2013, at 12:37, Tom Lane wrote:
> Tom Dunstan writes:
>> Well, with this patch, under the hood the FK query is doing (in the case of
>> RESTRICT):
>
>> SELECT 1 FROM ONLY "public"."comment" x WHERE (the id)
>> OPERATOR(pg_catalog.=) "parent_id" AND (parent_entity = 'event') FOR KEY
On 11/28/2013 03:24 AM, David Fetter wrote:
> WITH, or SRF, or whatever, the point is that we need to be able to
> specify what we're sending--probably single opaque strings delimited
> just as we do other strings--and what we might get back--errors only,
> rows, [sets of] refcursors are the ones I
On Tue, Dec 3, 2013 at 11:57 AM, Michael Paquier
wrote:
> On Tue, Dec 3, 2013 at 1:08 AM, Robert Haas wrote:
>> As long as it was set at
>> the time the master last entered read-write mode (which is what the
>> XLOG_PARAMETER_CHANGE stuff does) you should be fine, unless of course
>> I haven't ha
On Tue, Dec 3, 2013 at 1:08 AM, Robert Haas wrote:
> On Mon, Dec 2, 2013 at 12:54 AM, Michael Paquier
>> Considering that, it would make more sense to have this option
>> settable with initdb only and not changeable after initialization, in
>> the same fashion as checksums. Having a GUC that can b
On Mon, Dec 2, 2013 at 6:23 PM, Peter Eisentraut wrote:
> which I think addresses your point.
Fair enough. Marked "ready for committer".
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/m
On Mon, Dec 2, 2013 at 04:56:56PM -0500, Stephen Frost wrote:
> * Ian Pilcher (arequip...@gmail.com) wrote:
> > > In any case, the idea that this is somehow OpenSSL's fault and another
> > > implementation of the same protocol wouldn't have the same issue sounds
> > > pretty silly.
> >
> > Actual
On Sat, 2013-11-30 at 15:56 -0800, Peter Geoghegan wrote:
> On Sun, Nov 24, 2013 at 5:11 AM, Peter Eisentraut wrote:
> > How about this?
>
> Hmm. You say:
>
> +If the command returns a nonzero exit status then a warning log
> +message will be written. An exception is that if the
On 3 December 2013 12:12, Tom Lane wrote:
> "Problem"? It's not a bug that you get hstore 1.2 when you dump from 9.2
> and reload into 9.3; that's a feature. You wanted an upgrade, presumably,
> or you'd not have been going to 9.3 in the first place. The entire reason
> why the extension mechan
Tom Dunstan writes:
> Well, with this patch, under the hood the FK query is doing (in the case of
> RESTRICT):
> SELECT 1 FROM ONLY "public"."comment" x WHERE (the id) OPERATOR(pg_catalog.=)
> "parent_id" AND (parent_entity = 'event') FOR KEY SHARE OF x;
Hm. The RI trigger code goes to extrem
Noah Misch writes:
> That's how I read it, too. My hypothesis is that the standard adopted TABLE()
> to rubber-stamp Oracle's traditional name for UNNEST().
Hmm ... plausible.
> ... I propose merely changing the syntax to "TABLE FOR ROWS (...)".
Ugh :-(. Verbose and not exactly intuitive, I t
On 11/28/2013 09:15 AM, Tom Dunstan wrote:
> Feature Proposal: Selective foreign keys.
> -
> Allow foreign keys to have where clauses.
I haven't caught up on the discussion yet, but: if you can swing this,
it'd also be very useful for RLS, providing
Tom Dunstan writes:
> On 3 December 2013 02:02, Dimitri Fontaine wrote:
>> 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
On 3 December 2013 02:02, Dimitri Fontaine wrote:
> 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 th
On 3 Dec 2013, at 03:37, Robert Haas wrote:
> I also like this feature. It would be really neat if a FOREIGN KEY
> constraint with a WHERE clause could use a *partial* index on the
> foreign table provided that the index would be guaranteed to be predOK
> for all versions of the foreign key che
On Thu, Nov 21, 2013 at 12:22:57PM -0500, Tom Lane wrote:
> Andrew Gierth writes:
> > If there isn't a reasonable syntax alternative to TABLE(...) for the
> > multiple functions case, then frankly I think we should go ahead and
> > burn compatibility with a spec feature which appears to be of nega
On 12/02/2013 02:12 PM, Brar Piening wrote:
> Hackers,
> the attached patch enables Microsoft Visual Studio 2013 as additional
> build environment.
> After some tweaking (VS now has got its own rint and a few macro
> definitions that were previously missing) the build runs without errors
> or warni
On Sun, 2013-12-01 at 17:40 -0500, Tom Lane wrote:
> Piotr Marcinczyk writes:
> > I would like to implement item from TODO list: "Improve TIMESTAMP WITH
> > TIME ZONE subtraction to be DST-aware".
>
> > To compute interval properly, we need time zone. Currently in timestamp
> > we don't have time
* Andrew Dunstan (and...@dunslane.net) wrote:
> But it does need to be signed by a trusted signatory. At least in my
> test script (pretty ugly, but shown below for completeness), the
> Intermediate CA cert is signed with the Root cert rather than being
> self-signed as the Root cert is, and so if
On 3 Dec 2013, at 01:34, Andrew Dunstan wrote:
> We wanted to apply FK constraints to a very large table, but grandfather in
> certain cases that didn't meet the constraint. That could have been done very
> simply using this feature.
Yeah, references to old data is the other obvious case for
On 12/02/2013 04:17 PM, Tom Lane wrote:
Bruce Momjian writes:
Sorry, I should have said:
Tom is saying that for his openssl version, a client that passed
an intermediate certificate had to supply a certificate _matching_
something in the remote root.crt, not just signed
Hackers,
the attached patch enables Microsoft Visual Studio 2013 as additional
build environment.
After some tweaking (VS now has got its own rint and a few macro
definitions that were previously missing) the build runs without errors
or warnings and the product passes the regression tests.
I
On Mon, Dec 2, 2013 at 1:30 PM, Peter Eisentraut wrote:
> A note to reviewers participating in the commit fests: When you send a
> review of a patch, reply to the email that contains the patch. Do no
> start a new email thread like "Review of 'Some Patch'". This is
> important for several reaso
On 12/1/13, 2:32 AM, Pavel Stehule wrote:
> trailing whitespace
>
>
> fixed,
>
> Peter, what application do you use for this check?
git diff --check
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailp
* Ian Pilcher (arequip...@gmail.com) wrote:
> > In any case, the idea that this is somehow OpenSSL's fault and another
> > implementation of the same protocol wouldn't have the same issue sounds
> > pretty silly.
>
> Actually other implementations do this. In fact, a flag was added to
> OpenSSL f
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Stephen Frost writes:
> > I'm not convinced we really need to solve that problem, but one way to
> > solve it 'cleanly' would be to seperate the two types of extensions,
> > perhaps by calling them by different names or inventing a namespace for
* Ian Pilcher (arequip...@gmail.com) wrote:
> On 12/02/2013 03:15 PM, Stephen Frost wrote:
> > That isn't at *all* accurate. Authorization is handled by pg_ident and
> > PG's role and grant system. We are only using OpenSSL's trust of the
> > certificate for authentication.
>
> OK, how do I conf
On 11/19/13, 11:30 PM, Peter Geoghegan wrote:
>>> +1 from me.
>> >
>> >
>> > That's +1 for *not* including this?
> Right.
I agree with not including this.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailp
On Mon, Dec 2, 2013 at 03:19:43PM -0600, Ian Pilcher wrote:
> On 12/02/2013 02:32 PM, Tom Lane wrote:
> > Ian Pilcher writes:
> >> 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 cl
Stephen Frost writes:
> I'm not convinced we really need to solve that problem, but one way to
> solve it 'cleanly' would be to seperate the two types of extensions,
> perhaps by calling them by different names or inventing a namespace for
> extensions.
My understanding is that this line of thoug
A note to reviewers participating in the commit fests: When you send a
review of a patch, reply to the email that contains the patch. Do no
start a new email thread like "Review of 'Some Patch'". This is
important for several reasons:
- It maintains the integrity of the email archives. The com
Ian Pilcher writes:
> BTW, you can't just "list the certs of the intermediate CAs you do
> trust"; you have to put the root CA certificate into root.crt in order
> for OpenSSL to build a complete chain,
I believe you are mistaken. OpenSSL just wants a chain to one of the
certs you've told it to
On Mon, Dec 2, 2013 at 04:17:57PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Sorry, I should have said:
>
> > Tom is saying that for his openssl version, a client that passed
> > an intermediate certificate had to supply a certificate _matching_
> > something in the remote ro
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Bruce Momjian writes:
> > At least I think that was the issue, rather than requiring the client to
> > supply a "root" certificate, meaning the client can supply an
> > intermediate or root certificicate, as long as it appears in the
> > root.crt file on th
On 12/02/2013 04:17 PM, Tom Lane wrote:
Bruce Momjian writes:
Sorry, I should have said:
Tom is saying that for his openssl version, a client that passed
an intermediate certificate had to supply a certificate _matching_
something in the remote root.crt, not just signed
Robert Haas writes:
> Speaking only for myself, I think the thing I most disliked about that
> proposal was the syntax. I'd rather see each extension member dumped
> separately, and then later dump the extension itself as CREATE
> EXTENSION ... WITH NO CONTENTS or similar followed by ALTER EXTENS
On 12/02/2013 03:15 PM, Stephen Frost wrote:
> That isn't at *all* accurate. Authorization is handled by pg_ident and
> PG's role and grant system. We are only using OpenSSL's trust of the
> certificate for authentication.
OK, how do I configure Postgres to only allow connections when the
client
On 12/02/2013 02:32 PM, Tom Lane wrote:
> Ian Pilcher writes:
>> 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 chain back to the
>> trusted root.
* Bruce Momjian (br...@momjian.us) wrote:
> Sorry, I should have said:
>
> Tom is saying that for his openssl version, a client that passed
> an intermediate certificate had to supply a certificate _matching_
> something in the remote root.crt, not just signed by it.
>
> At leas
Bruce Momjian writes:
> Sorry, I should have said:
> Tom is saying that for his openssl version, a client that passed
> an intermediate certificate had to supply a certificate _matching_
> something in the remote root.crt, not just signed by it.
> At least I think that was the
* Robert Haas (robertmh...@gmail.com) wrote:
> Speaking only for myself, I think the thing I most disliked about that
> proposal was the syntax. I'd rather see each extension member dumped
> separately, and then later dump the extension itself as CREATE
> EXTENSION ... WITH NO CONTENTS or similar
On Mon, Dec 2, 2013 at 04:12:13PM -0500, Stephen Frost wrote:
> * 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 ---
* Ian Pilcher (arequip...@gmail.com) wrote:
> 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 authen
On Mon, Dec 2, 2013 at 3:17 PM, Dimitri Fontaine 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'
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
* 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
* 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
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
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 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
* 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 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
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
* 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
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
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,
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 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
* 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
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
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
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
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
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
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
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
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
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
* 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
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
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
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
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
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 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
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 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
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 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
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 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 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 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 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 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
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 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
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 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 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 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
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
1 - 100 of 151 matches
Mail list logo
