> According to SSL_set_verify manpage, you are perhaps talking about
> SSL_VERIFY_NONE case? Which has suggestion that you should call
> SSL_get_verify_result if you want to know if cert was valid.
>
> But if SSL_VERIFY_PEER is used, this is not needed.
Oh, man I missed that detail.
Please a
Hi Marko,
Sorry to go offlist
>> I believe the "standard" way of achieving TLS1.0 and above is to use
>> the SSLv23_client_method() and then remove the SSL protocols with
>> SSL_OP_NO_SSLv2 and SSL_OP_NO_SSLv3. I have to use handwaiving around
>> "standard" because I don't believe its documen
if I don't dalloc parameters that allocated with palloc0 then will free the
allocated memory at the end of transaction?
On Wed, 2013-11-27 at 18:34 +0100, Dimitri Fontaine wrote:
> Stephen Frost writes:
> > We already have other 'template' objects in the system and I'm not
> > excited about the confusion. This also applies to 'CreateTemplate',
> > 'CreateTemplateTupleDesc', right down to 'template.h' and 'template
On Sat, Nov 30, 2013 at 03:46:06AM -0500, Jeffrey Walton wrote:
> >> I believe the "standard" way of achieving TLS1.0 and above is to use
> >> the SSLv23_client_method() and then remove the SSL protocols with
> >> SSL_OP_NO_SSLv2 and SSL_OP_NO_SSLv3. I have to use handwaiving around
> >> "standard"
On Sat, 2013-11-30 at 01:05 -0800, Jeff Davis wrote:
> Unless I'm missing something, I'd be inclined to just get rid of the
> concept of DEFAULT FULL VERSION just to keep the documentation simpler
> without losing any real functionality.
I found some explanation of the original reasoning in these
Sent from my iPad
> On 30-Nov-2013, at 14:30, mohsen soodkhah mohammadi
> wrote:
>
> if I don't dalloc parameters that allocated with palloc0 then will free the
> allocated memory at the end of transaction?
Yes, palloc allocates memory in contexts, and the memory allocated in these
context
On 27 November 2013 10:35 Fujii Masao wrote:
> On Wed, Nov 27, 2013 at 1:27 PM, Haribabu kommi
> wrote:
> > On 26 November 2013 23:11 Fujii Masao wrote:
> >> On Wed, Nov 20, 2013 at 7:43 PM, Haribabu kommi
> >> wrote:
> >> > I tried using of stat'ing in two directories, which is having a
> >> pro
Are you still working on this patch?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/30/2013 04:00 AM, mohsen soodkhah mohammadi wrote:
if I don't dalloc parameters that allocated with palloc0 then will
free the allocated memory at the end of transaction?
Please read src/backend/utils/mmgr/README
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
Alvaro Herrera writes:
> Okay, I have pushed all these patches, including the fixes suggested
> here and then some.
Not sure exactly which patch caused it, but I'm getting a warning
in 9.0 through 9.2:
multixact.c:1553: warning: no previous prototype for 'TrimMultiXact'
On Fri, 2013-11-29 at 22:15 -0300, Alvaro Herrera wrote:
> Okay, I have pushed all these patches, including the fixes suggested
> here and then some.
Something in these patches is causing a new compiler warning in the 9.2
branch:
multixact.c:1553:1: warning: no previous prototype for
‘TrimMultiXa
Hi Noah,
On 2013-11-30 00:40:06 -0500, Noah Misch wrote:
> > > On Wed, Nov 27, 2013 at 02:14:53PM +0100, Andres Freund wrote:
> > > > With regard to fixing things up, ISTM the best bet is heap_prune_chain()
> > > > so far. That's executed b vacuum and by opportunistic pruning and we
> > > > know w
On 2013-11-30 10:57:43 -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > Okay, I have pushed all these patches, including the fixes suggested
> > here and then some.
>
> Not sure exactly which patch caused it, but I'm getting a warning
> in 9.0 through 9.2:
>
> multixact.c:1553: warning: no pr
Andres Freund writes:
> I am not sure if it's a good idea to delay the release because of this,
> there are so many other critical issues that that seems like a bad
> tradeoff.
Indeed. We already said that this release was being done *now* because
of the replication bug, and I see no reason to c
On 2013-11-30 11:18:09 -0500, Tom Lane wrote:
> We've already taken a credibility hit from introducing a new
> bug into the last round of update releases; let's please not take a
> risk of doing that again.
On that front: I'd love for somebody else to look at the revised 9.3
freezing logic. It's w
On 2013-11-30 17:06:31 +0100, Andres Freund wrote:
> On 2013-11-30 10:57:43 -0500, Tom Lane wrote:
> > Alvaro Herrera writes:
> > > Okay, I have pushed all these patches, including the fixes suggested
> > > here and then some.
> >
> > Not sure exactly which patch caused it, but I'm getting a warn
On Sat, Nov 30, 2013 at 05:22:04PM +0100, Andres Freund wrote:
> On that front: I'd love for somebody else to look at the revised 9.3
> freezing logic.
Do you speak of the changes to xmax freezing arising from the FK lock
optimization?
--
Noah Misch
EnterpriseDB h
Kevin Grittner wrote:
> In going over this, I found pre-existing bugs when a tuple was both
> inserted and deleted by concurrent transactions, but fixing that is
> too invasive to consider for Monday's minor release lockdown. The
> attached seems very safe to me, and protects against some new
>
On 2013-11-30 11:18:09 -0500, Tom Lane wrote:
> Indeed. We already said that this release was being done *now* because
> of the replication bug, and I see no reason to change that.
FWIW, I think the two other data corrupting bugs, "incomplete freezing
due to truncation" (all branches) and freezin
Andres Freund writes:
> FWIW, I think the two other data corrupting bugs, "incomplete freezing
> due to truncation" (all branches) and freezing overall (in 9.3), are at
> least as bad because they take effect on the primary.
> Not saying that because of my involvement, but because I think they nee
On 2013-11-30 11:40:36 -0500, Noah Misch wrote:
> On Sat, Nov 30, 2013 at 05:22:04PM +0100, Andres Freund wrote:
> > On that front: I'd love for somebody else to look at the revised 9.3
> > freezing logic.
>
> Do you speak of the changes to xmax freezing arising from the FK lock
> optimization?
Y
On Thu, Mar 21, 2013 at 01:42:55PM +0800, Craig Ringer wrote:
> On 03/19/2013 09:46 PM, Stephen Frost wrote:
> > * Craig Ringer (cr...@2ndquadrant.com) wrote:
> >> As far as I'm concerned that's the immediate problem fixed. It may be
> >> worth adding a warning on startup if we find non-self-signed
On 2013-11-30 11:50:57 -0500, Tom Lane wrote:
> Andres Freund writes:
> > FWIW, I think the two other data corrupting bugs, "incomplete freezing
> > due to truncation" (all branches) and freezing overall (in 9.3), are at
> > least as bad because they take effect on the primary.
> > Not saying that
On Sat, Nov 30, 2013 at 05:00:58PM +0100, Andres Freund wrote:
> The problem with log_newpage_buffer() is that we'd quite possibly issue
> one such call per item on a page. And that might become quite
> expensive. Logging ~1.5MB per 8k page in the worst case sounds a bit
> scary.
I had in mind iss
On 2013-11-30 12:22:16 -0500, Noah Misch wrote:
> On Sat, Nov 30, 2013 at 05:00:58PM +0100, Andres Freund wrote:
> > The problem with log_newpage_buffer() is that we'd quite possibly issue
> > one such call per item on a page. And that might become quite
> > expensive. Logging ~1.5MB per 8k page in
In our fine manual, at
http://www.postgresql.org/docs/devel/static/typeconv-union-case.html
it's claimed that the nontrivial parts of UNION type resolution
work like this:
4. Choose the first non-unknown input type which is a preferred type in
that category, if there is one.
5. Otherwise, c
Andres Freund writes:
> On 2013-11-30 11:50:57 -0500, Tom Lane wrote:
>> I was planning to draft up the release notes today. Can you propose
>> text about the above?
> I can, but it will be a couple of hours before I can give it serious
> thought (starving and insanity being serious perils other
Tom Lane wrote:
> This came up because some of my Salesforce colleagues were griping about
> the fact that UNION isn't commutative. They argue that the type
> resolution behavior ought not be sensitive at all to the ordering of the
> inputs. I'm not sure we can achieve that in general, but the
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] after
> > the check to avoid out-of-bounds read.
>
> This
> I could not get TLSv1.1+ with that. But I'm working against
> Ubuntu 12.04 default OpenSSL. I'll try with other versions too.
That looks like a Ubuntu 12.04 limitation: http://postimg.org/image/3ju4fu0y1/
I would bet the 1.0.0 version of OpenSSL is less that 1.0.0h:
$ ldd /usr/lib/x86_64-linu
Bruce Momjian wrote:
> Once the patch is applied, I will be patching pg_upgrade by appending to
> PGOPTIONS, but that will only be for 9.4. The patch will be too risky
> and there are not enough problem reports to override that and warrant
> backpatching.
pg_dumpall patch applied, back to 8.4.
On Wed, 2013-11-27 at 18:34 +0100, Dimitri Fontaine wrote:
> The other main point that will change the current code is dealing with
> superusers and security concerns. Baring objections, I'm going to
> implement a variation of what I did propose in the thread:
>
> When a superuser CREATE EXTENSI
On Fri, 2013-11-29 at 09:06 +0100, Pavel Stehule wrote:
> attached patch implement unified behave for DROP IF EXISTS statements
> as was discussed
src/backend/catalog/namespace.c:1743: indent with spaces.
src/backend/commands/dropcmds.c:322: indent with spaces.
src/backend/commands/dropcmds.c:32
On Tue, 2013-11-26 at 01:37 +0200, Heikki Linnakangas wrote:
> I want to be able to download extension.zip from pgxn.org, and then
> install it on a server. I want to be able to install it the traditional
> way, by unzipping it to the filesystem, or via libpq by using this new
> feature.
I see
On Wed, 2013-11-27 at 18:34 +0100, Dimitri Fontaine wrote:
> I merged your patch in, rebased against master, fixed some more typos I
> found, and filled in the gaps you found in the docs. Version 17 of the
> patch is attached to that email, passes `make check`.
A couple more questions:
1. During
On Fri, Nov 22, 2013 at 01:55:10PM -0800, Kevin Grittner wrote:
> Kevin Grittner wrote:
>
> This covers pg_dumpall globals. Tested with a read-only postgres
> database and with default_transaction_read_only = on in the
> postgresql.conf file.
>
> It does nothing about pg_upgrade, which is sort
Jeff Davis writes:
> I think that Stephen was just talking about the naming. I would have
> expected the names to be something like "xtmpl" (which is the shortest
> abbreviation that came to my mind) rather than "tpl", for instance. Use
> of "template" is a bit ambiguous.
To be honest I'm not fol
Bruce Momjian writes:
> I have fixed pg_upgrade in git-head with the attached patch, which
> prepends default_transaction_read_only=false to PGOPTIONS.
What is the point of this, given that Kevin fixed pg_dumpall? Don't
those fixes take care of the issue?
If your argument is that you want pg_up
Jeff Davis writes:
>> When a superuser CREATE EXTENSION against a template that has been
>> provided by a non-privileged user, automatically SET ROLE to that user
>> before doing so, avoiding escalation privileges.
>
> That proposal is worded like a special case for superusers, and I don't
>
On Saturday, November 30, 2013, Dimitri Fontaine wrote:
>
> Also consider multi-tenancy installations. Certainly, you don't want any
> database owner to be able to review PL code from any other database
> owner in the same cluster when each database owner is another customer
>
I'm planning to do a
Jeff Davis writes:
> 1. During the initial development of extensions, there was discussion
> about ordered version numbers and dependencies on the version (e.g.
> requires foo >= 2.1). Outside the scope of this patch, of course, but is
> that something that we can still do later? Or are we buildin
Stephen Frost writes:
> Without that, all of the information about a given extension is already in
> the database in our dependency system. As you pointed out, there was
That's not entirely true. We would still be missing some information
from the extension control file.
> previously a notion of
Dimitri,
On Saturday, November 30, 2013, Dimitri Fontaine wrote:
>
> The current extension model is simple enough to reason about. A script
> must be provided in a template and is executed at CREATE EXTENSION time
> or at ALTER EXTENSION UPDATE time, and pg_dump only contains the CREATE
> EXTENSIO
Tom Lane wrote:
> Bruce Momjian writes:
>
>> I have fixed pg_upgrade in git-head with the attached patch,
>> which prepends default_transaction_read_only=false to PGOPTIONS.
>
> What is the point of this, given that Kevin fixed pg_dumpall?
> Don't those fixes take care of the issue?
>
> If your
I've produced another revision, attached. Changes:
* Fixes the compiler warnings on your environment.
* Normalizes query string with the shared lock held (not always, just
in case its needed). In master, this doesn't have to happen with a
shared lock held, so because of this, but also because of
Kevin Grittner writes:
> Tom Lane wrote:
>> What is the point of this, given that Kevin fixed pg_dumpall?
>> Don't those fixes take care of the issue?
> 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
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 command was
+terminated by a signal or an error by the shell (s
On 2013-11-30 11:50:57 -0500, Tom Lane wrote:
> Andres Freund writes:
> > FWIW, I think the two other data corrupting bugs, "incomplete freezing
> > due to truncation" (all branches) and freezing overall (in 9.3), are at
> > least as bad because they take effect on the primary.
> > Not saying that
On Sat, Nov 30, 2013 at 06:48:02PM -0500, Tom Lane wrote:
> Kevin Grittner writes:
> > Tom Lane wrote:
> >> What is the point of this, given that Kevin fixed pg_dumpall?
> >> Don't those fixes take care of the issue?
>
> > If there were databases or users with default_transaction_read_only
> >
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 actually unused call to strlen() in
> > formatting.c, float
On Sat, 2013-11-30 at 22:55 +0100, Dimitri Fontaine wrote:
> So we need the "default_major_version" capabilities, whatever the
> name we choose. Hence my inclusion of that feature in the Extension
> Template patch.
What we need is a means to install versions for which we don't have ful
Hello,
we found this issue year ago -
http://www.postgresql.org/message-id/cafj8prahvzupfbx+8ey-xhfwbo8bxvu_ynmbapsdj8w-ara...@mail.gmail.com
I try to simulate this error, but without success - so I prepared patch
that had to help with identification of this issue. Important part is
backport pro
On Sat, Nov 30, 2013 at 11:41 PM, Andrew Dunstan wrote:
> Please read src/backend/utils/mmgr/README
And that as well directly in the docs:
http://www.postgresql.org/docs/devel/static/xfunc-c.html#AEN53984
"The memory allocated by palloc will be freed automatically at the end
of each transaction, p
On Sat, 2013-11-30 at 23:03 +0100, Dimitri Fontaine wrote:
> Jeff Davis writes:
> >> When a superuser CREATE EXTENSION against a template that has been
> >> provided by a non-privileged user, automatically SET ROLE to that user
> >> before doing so, avoiding escalation privileges.
> >
> > Th
Hello
2013/12/1 Peter Geoghegan
> I've produced another revision, attached. Changes:
>
> * Fixes the compiler warnings on your environment.
>
> * Normalizes query string with the shared lock held (not always, just
> in case its needed). In master, this doesn't have to happen with a
> shared loc
On Sat, Nov 30, 2013 at 11:30 PM, Pavel Stehule wrote:
> After this fix it should be ready for commit
Whoops. I forgot to change that when I changed the name of the
parameter at the last minute. Sorry about that.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
2013/11/30 Peter Eisentraut
> trailing whitespace
fixed,
Peter, what application do you use for this check?
Regards
Pavel
commit 88e0a6b97968f88aaa1e3cef17fc2e6e2ca9f25d
Author: Pavel Stehule
Date: Fri Nov 29 11:10:07 2013 +0100
initial
diff --git a/src/backend/catalog/namespace.c b
58 matches
Mail list logo
