On Wed, Jan 2, 2013 at 3:17 PM, Magnus Hagander wrote:
> On Wed, Jan 2, 2013 at 3:15 PM, Noah Misch wrote:
>> On Wed, Jan 02, 2013 at 02:03:20PM +0100, Magnus Hagander wrote:
>>> On Wed, Jan 2, 2013 at 1:15 AM, Tom Lane wrote:
>>> > So +1 for changing it to "
On Sun, Dec 16, 2012 at 7:20 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Sat, Dec 15, 2012 at 2:24 PM, Erik Rijkers wrote:
>>> That would make such a truncation less frequent, and after all a truncated
>>> display is not
>>> particular useful.
>
and you don't have to deal with licensing hassles.
(Of course, the AMI method doesn't work all the way since you'd be
distributing Visual Studio, but if we can have a script that
auto-downloads-and-installs it as necessary we can get around that)
--
Magnus Hagander
Me
s. I've fixed this.
> It looks good to me, passes check and so forth.
>
> Attached is a v6 patch, with no tabs in docs and based
> off the latest head.
>
> I'm marking it ready for committer.
Thanks. Applied, with only some small whitespace changes.
--
Magnus Hagander
On Thu, Jan 17, 2013 at 11:09 AM, Dave Page wrote:
> On Thu, Jan 17, 2013 at 9:36 AM, Magnus Hagander wrote:
>> On Thu, Jan 17, 2013 at 2:35 AM, Tatsuo Ishii wrote:
>>>>>> This might be way more than we want to do, but there is an article
>>>>>>
hope someone pick this up and propose as a TODO item. In the
> mean time, I'm going to commit the patch without Windows support
> unless there's objection.
Perhaps we should actually hold off until someone committs to actually
getting it fixed in the next version? If we do have tha
ay it already exists, because I'm sure
committers pay slightly more attention to reviews by people who ahve
been doing it a lot and are known to process those things, than to new
entries. All that woudl bee needed was for those people to realize it
would be helpful for them to do a second-stag
On Jan 17, 2013 8:15 AM, "Abhijit Menon-Sen" wrote:
>
> At 2013-01-17 16:05:05 +0900, michael.paqu...@gmail.com wrote:
> >
> > Is it really necessary to create a new commit fest just to move the
> > items? Marking the patches that are considered as being too late for
> > 9.3 should be just returne
or it, and that's perhaps something
we need to discuss for the future.
> I would like to nominate Craig Ringer to be independent CF mgr for Jan2013 CF.
If he's willing to do that, then +1 from me.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.co
ter CF3. At this point I'd bet against releasing 9.3 during
> 2013.
Well, if we said that, why don't we just single out those patches, and
bounce them right now. Before people put more work into it.
We also talked about the one-patch-one-review. Did someone ever check
if that work
eatures. It's on http://wiki.postgresql.org/wiki/CommitFest. It
doesn't specifically say do this and don't do htat, but it says focus
on review and discussing things that will happen that far ahead is
definitely not focusing on review.
--
Magnus Hagander
Me: http://www.hagander.net/
W
be easy
enough to figure out at an early stage, too.
That said, it wouldn't hurt if we could make that error a little less
scary. Instead of saying "could not open file", could we find a way to
say "this is an unlogged table on a slave, it's not going to work"?
We c
I agree. But just as we had pg_standby for quite a while before we got
standby_mode=on, I believe we should have pg_retainxlog (or something
like it) until we have something more integrated.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hac
On Sat, Jan 5, 2013 at 3:11 PM, Magnus Hagander wrote:
> On Fri, Jan 4, 2013 at 7:13 PM, Peter Eisentraut wrote:
>> On 1/3/13 12:30 PM, Robert Haas wrote:
>>> On Thu, Jan 3, 2013 at 11:32 AM, Magnus Hagander
>>> wrote:
>>>> Any particular reaso
ment "Install.pm.patch".
>
> Could someone with access to Windows verify this patch?
Thta version doesn't even apply to 9.1 - only to master. And the
indent on master is really bad.
That said, function looks good, so I've cleaned i tup and applied.
--
Magnus Hagander
specified in pg_basebackup. Attached patch fixes this problem.
Ugh, my fault. Failure when merging my changes with those from Zoltan.
Applied, thanks.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
iple
connections? So not just as an external command, but also availbale as
a direct calback.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jan 9, 2013 at 1:47 PM, Andres Freund wrote:
> On 2013-01-09 13:34:12 +0100, Magnus Hagander wrote:
>> Am I the only one who finds this way of posting patches really annoying?
>
> Well, I unsurprisingly don't ;)
Yeah, that's not surprising :)
>> Here
> delete mode 100644 src/bin/pg_dump/dumpmem.c
> delete mode 100644 src/bin/pg_dump/dumpmem.h
> create mode 100644 src/include/port/palloc.h
> create mode 100644 src/port/palloc.c
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To ma
On Tue, Jan 8, 2013 at 10:23 PM, Peter Eisentraut wrote:
> On 1/8/13 4:32 AM, Magnus Hagander wrote:
>> How does it work if there are many rows in there? Say the result
>> contains 10,000 rows - will the string contain all of them? If so,
>> might it be worthwhile to cap the
le to cap the number of rows shown and then follow
with a "..." or something?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Sep 13, 2012 at 9:00 AM, Magnus Hagander wrote:
> On Thu, Sep 13, 2012 at 5:22 AM, Peter Eisentraut wrote:
>> On Wed, 2012-09-12 at 19:13 +0200, Magnus Hagander wrote:
>>> Just to be clear, what you're saying is we want to change the policy
>>> that sa
On Fri, Jun 29, 2012 at 4:39 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> Turned out to be a bit more work than I thought, since the current
>> parser reads pg_hba byte by byte, and not line by line. So I had to
>> change that. See attached, seems reasonable?
>
On Sat, Jan 5, 2013 at 3:41 PM, Magnus Hagander wrote:
> On Thu, Jan 3, 2013 at 1:33 PM, Boszormenyi Zoltan wrote:
>> 2013-01-02 11:54 keltezéssel, Boszormenyi Zoltan írta:
>>
>> 2013-01-02 10:37 keltezéssel, Boszormenyi Zoltan írta:
>>
>> 2013-01-02 10:12
On Thu, Jan 3, 2013 at 1:33 PM, Boszormenyi Zoltan wrote:
> 2013-01-02 11:54 keltezéssel, Boszormenyi Zoltan írta:
>
> 2013-01-02 10:37 keltezéssel, Boszormenyi Zoltan írta:
>
> 2013-01-02 10:12 keltezéssel, Magnus Hagander írta:
> Attached is the quotes-v2 patch, the funct
the user should probably go in src/port/ now
that we moved the tar header creation there a few days ago)
I would suggest we just drop the README file completely. I don't think
it adds any value at all.
Any objections to that path? :)
--
Magnus Hagander
Me: http://www.hagander.net/
Wor
On Fri, Jan 4, 2013 at 7:13 PM, Peter Eisentraut wrote:
> On 1/3/13 12:30 PM, Robert Haas wrote:
>> On Thu, Jan 3, 2013 at 11:32 AM, Magnus Hagander wrote:
>>> Any particular reason? It goes pretty tightly together with
>>> pg_receivexlog, which is why I'd pref
clearly possible and it's a trivial change. I was thinking about
> that actually, but then I placed the directory into "global" because
> that's where the "pgstat.stat" originally was.
Yeah, +1 for a separate directory not in global.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jan 3, 2013 at 3:13 PM, Robert Haas wrote:
> On Tue, Jan 1, 2013 at 10:10 AM, Magnus Hagander wrote:
>> So, it turns out the reason I got no feedback on this tool, was that I
>> forgot both to email about and to actually push the code to github :O
>> So this is
On Wed, Jan 2, 2013 at 5:44 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Jan 2, 2013 at 5:36 PM, Tom Lane wrote:
>>> Why are these very tar-specific functions being declared in such a
>>> globally visible spot as port.h? That seems like a bad idea on
On Wed, Jan 2, 2013 at 5:36 PM, Tom Lane wrote:
> Magnus Hagander writes:
>>> On Wed, Jan 2, 2013 at 4:14 AM, Andrew Dunstan wrote:
>>>> This seems to have broken plperl builds on Windows.
>
>> I'm not really sure what the best thing is to do here. We c
On Wed, Jan 2, 2013 at 3:15 PM, Noah Misch wrote:
> On Wed, Jan 02, 2013 at 02:03:20PM +0100, Magnus Hagander wrote:
>> On Wed, Jan 2, 2013 at 1:15 AM, Tom Lane wrote:
>> > So +1 for changing it to "DEFAULT" from me, too. There's no reason to
>> > thin
On Wed, Jan 2, 2013 at 1:15 AM, Tom Lane wrote:
>
> Noah Misch writes:
> > On Tue, Jan 01, 2013 at 04:29:35PM +0100, Magnus Hagander wrote:
> >> On Thu, Aug 30, 2012 at 11:41 PM, Bruce Momjian wrote:
> >>> Do we want to change our ssl_ciphers default to '
On Wed, Jan 2, 2013 at 9:59 AM, Boszormenyi Zoltan wrote:
> 2013-01-02 01:24 keltezéssel, Tom Lane írta:
>
> Boszormenyi Zoltan writes:
>>
>>> 2013-01-01 17:18 keltezéssel, Magnus Hagander írta:
>>>
>>>> That way we can get around the whole need f
On Tue, Jan 1, 2013 at 7:13 PM, Boszormenyi Zoltan wrote:
> 2013-01-01 18:25 keltezéssel, Magnus Hagander írta:
>
>
> On Fri, Nov 30, 2012 at 10:13 AM, Boszormenyi Zoltan wrote:
>
>> Hi,
>>
>> now that PQconninfo() was committed, I rebased the subsequent
>&g
for just leaving two copies of recovery.conf in there.
Comments/thoughts from others?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
d the whole need for changing memory allocation
across all the frontends, no? Like the attached.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
quotes.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Thu, Aug 30, 2012 at 11:41 PM, Bruce Momjian wrote:
> On Sun, Jun 17, 2012 at 11:45:54PM +0800, Magnus Hagander wrote:
> > On Sun, Jun 17, 2012 at 11:42 PM, Tom Lane wrote:
> > > Magnus Hagander writes:
> > >> Is there a reason why we don't have a param
ronment and submit it for the last commitfest.
(comments on the code itself are of course also welcome)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
raightforward though.
>
> I'd like to hear opinions on just staying with the IMO ugly minimal fix,
> or pursue instead making MaxBackends a macro plus some sort of cache to
> avoid repeated computation.
If my understanding per above is correct, then here's a +1 for the
n
o *the
specific files that you want to grant read on*. Which makes it
possible to actually make it secure. E.g. you *don't* have to give
full read to your entire database.
If you're comparing it to a blanket SECURITY DEFINER with no checks,
then yes, it's a simpler way to fire the cannon
On Dec 19, 2012 4:43 AM, "Josh Berkus" wrote:
>
> Hackers,
>
> Currently we can see each master's current replicas using
> pg_stat_replication. However, there is no way from a replica, that I
> know of, to figure out who its master is other than to look at
> recovery.conf.
>
> We should probably
line history file in the backup?
>
> +1. I was not aware that we weren't doing that --- it seems pretty
> foolish, especially since as you say they're tiny.
Yeah, +1. That should probably have been a part of the whole
"basebackup from slave" patch, so it can probably be c
On Sat, Dec 15, 2012 at 2:24 PM, Erik Rijkers wrote:
> On Sat, December 15, 2012 14:10, Magnus Hagander wrote:
>> On Sat, Dec 15, 2012 at 11:39 AM, Erik Rijkers wrote:
>>> from 9.3devel (this morning):
>>
>>
>>> The truncated name in parentheses only show
utils\fmgroids.h .
>
> "clean dist" is fine, since it deletes fmgrtab.c too, causing the whole
> thing to be re-generated.
>
> The attached patch fixes the issue.
Looks good to me. Applied and backpatched to 9.2 - the logic appears
slightly different before that.
--
Magn
ud
be changed :), but it's not a bug in itself - it's acting like
intended.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
rectory at the same time, we can hardly say that this is
> a case that should never arise in real life.
Makes sense, yeah. Of course, anything stuffed *inside* said subdir
will still be included, but that's violating that principle even more
:)
--
Magnus Hagander
Me: http://www.hagander.
On Mon, Dec 3, 2012 at 3:20 PM, Robert Haas wrote:
> On Fri, Nov 30, 2012 at 1:02 AM, Magnus Hagander wrote:
>> In the interest of moving things along, I'll remove these for now at
>> least, and commit the rest of the patch, so we can keep working on the
>> basebacku
On Dec 3, 2012 2:55 AM, "Andrew Dunstan" wrote:
>
>
> On 12/02/2012 07:50 PM, Magnus Hagander wrote:
>>
>> On Sat, Dec 1, 2012 at 6:56 PM, Tom Lane wrote:
>>>
>>> Magnus Hagander writes:
>>>>
>>>> Someone just reported
On Sat, Dec 1, 2012 at 6:56 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> Someone just reported a problem when they had created a new tablespace
>> inside the old data directory. I'm sure there can be other issues
>> caused by this as well, but this is mainl
creating a tablespace inside the main data directory, should we
perhaps disallow this in CREATE TABLESPACE? Or at least throw a
WARNING if one does it?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
etely incorrect - it depends on the queries
on the *master*, not on the complexity of the query on the slave. I
know a lot of scenarios where query cancels pretty much never happen
at all.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-
etty big gotcha.
+1. Having your reporting query time out *shows you* the problem.
Having the master bloat for you won't show the problem until later -
when it's much bigger, and it's much more pain to recover from.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Nov 28, 2012 at 7:01 AM, Magnus Hagander wrote:
>
> On Nov 28, 2012 1:54 AM, "Tom Lane" wrote:
>>
>> Alvaro Herrera writes:
>> > Peter Eisentraut wrote:
>> >> There is already the PQconninfoOption.dispchar field for this purpose.
>
On Nov 28, 2012 1:54 AM, "Tom Lane" wrote:
>
> Alvaro Herrera writes:
> > Peter Eisentraut wrote:
> >> There is already the PQconninfoOption.dispchar field for this purpose.
>
> > I had the impression that that field would go away with this patch, but
> > then again it might not be worth the comp
On Tue, Nov 27, 2012 at 10:13 PM, Peter Eisentraut wrote:
> On 11/22/12 6:44 AM, Magnus Hagander wrote:
>> I'm thinking it might be a better idea to just have PG_CONNINFO_NORMAL
>> and PG_CONNINFO_PASSWORD (which still make sense to separate),
>
> What is the us
On Mon, Nov 26, 2012 at 5:33 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> It's no longer possible to build pgadmin with libpq from git master:
>> /opt/pgsql/inst-pg/head/include/libpq-fe.h:551:8: error: ‘pg_int64’
>> does not name a type
>
> [ scratches head
9%40awork2.anarazel.de
>
> For some reason the web ui only shows one of the the attachements
> though...
Did you by any chance use git-send-email to send it?
That one is known to confuse how majordomo sticks it in the mbox files
that are then later used to generate the archives...
(Y
mitdiff&h=95d035e66d8e4371d35830d81f39face03cd4c45
AFAICT, this suddenly requires that any user of libpq has pg_int64
defined, which isn't likely to happen outside of postgres itself.
Or am I reading things wrong?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.c
On Mon, Nov 26, 2012 at 5:04 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> I noticed after a pg_upgrade on a system, that the same oid is used
>> both for a database and a user (repeated many times for different
>> combinations of databases and users). This is because
e makes it a lot more likely to happen. So I'm thinking
it shouldn't be a problem since the oid's are in different tables, but
are there any other parts of the system where this could cause an
actual problem?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpi
On Fri, Nov 23, 2012 at 6:30 AM, Fujii Masao wrote:
> On Thu, Nov 22, 2012 at 10:05 PM, Boszormenyi Zoltan wrote:
>> 2012-11-22 12:44 keltezéssel, Magnus Hagander írta:
>>>>>>>> Also, a question was buried in the other review which is - are we OK
>>>>
On Thu, Nov 22, 2012 at 10:16 AM, Boszormenyi Zoltan wrote:
> 2012-11-22 08:35 keltezéssel, Boszormenyi Zoltan írta:
>
>> 2012-11-21 22:15 keltezéssel, Magnus Hagander írta:
>>>
>>> On Wed, Nov 21, 2012 at 10:01 PM, Boszormenyi Zoltan
>>> wrote:
&
On Wed, Nov 21, 2012 at 10:01 PM, Boszormenyi Zoltan wrote:
> Hi,
>
> 2012-11-21 19:19 keltezéssel, Magnus Hagander írta:
>
>> I'm breaking this out into it's own thread, for my own sanity if
>> nothing else :) And it's an isolated feature after all.
>&
omplex code to deal with both?
Attached is both Zoltans latest patch (v16) and my slightly different approach.
Comments on which approach is best?
Test results from somebody who has the time to look at it? :)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.co
On Tue, Oct 23, 2012 at 5:08 PM, Magnus Hagander wrote:
>
> On Oct 23, 2012 4:52 PM, "Alvaro Herrera" wrote:
>>
>> Boszormenyi Zoltan escribió:
>>
>> > >>Also, the check for conflict between -R and -x/-X is now removed.
>> >
>> &
facility, but as another
way of doing it. And I'd expect it could be the "main way" for manual
changes, but tools would still need access to the other way of course.
We probably need to enhance pg_settings to tell the user *where* the
setting came from whe nit's set this wa
malisation stuff
> was committed.
What was the argument for rejecting it? Just that it required
hash_any() to be adapted?
Now that we have a very clear use case where this would help, perhaps
it's time to re-visit this proposal?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
fully into auto-tuning
> before getting more field feedback on how that works out is pretty
> aggressive.
+1.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
x27;ve even gotten started on an implementation at one point, though in
fairness I didn't get much past "git branch".
I definitely think it would be a useful thing.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list
On Wed, Nov 7, 2012 at 6:19 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Nov 7, 2012 at 5:53 PM, Tom Lane wrote:
>>> I'm not sure that the above approach works anyway --- for instance, the
>>> "current setting" might be a SET LOCAL resu
On Wed, Nov 7, 2012 at 5:53 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Nov 7, 2012 at 5:19 AM, Amit Kapila wrote:
>>> However there is one more point which I am not able to clearly make out is
>>> how to write into file that contains
>>> all con
On Wed, Nov 7, 2012 at 5:19 AM, Amit Kapila wrote:
> On Tuesday, November 06, 2012 11:30 PM Robert Haas wrote:
>> On Wed, Oct 31, 2012 at 8:17 AM, Magnus Hagander
>> wrote:
>> >> I'm not convinced we ever *had* a consensus on this. There were
>> >>
On Mon, Nov 5, 2012 at 10:21 PM, Andrew Dunstan wrote:
>
> On 11/05/2012 01:53 PM, Magnus Hagander wrote:
>
>
>> On Mon, Nov 5, 2012 at 7:50 PM, Andrew Dunstan > and...@dunslane.net>> wrote:
>>
>>
>> On 11/05/2012 12:13 PM, Magnus
On Mon, Nov 5, 2012 at 9:49 PM, Bruce Momjian wrote:
> On Mon, Nov 5, 2012 at 03:30:32PM -0500, Tom Lane wrote:
> > Magnus Hagander writes:
> > > On Mon, Nov 5, 2012 at 9:14 PM, Tom Lane wrote:
> > >> BTW, does pg_upgrade run pg_restore in --single-transaction mo
ake synchronous_commit moot, at least for that
> step.
>
It doesn't use pg_restore at all - it uses the dump from pg_dumpall, which
you can't reload with pg_restore.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Mon, Nov 5, 2012 at 7:50 PM, Andrew Dunstan wrote:
>
> On 11/05/2012 12:13 PM, Magnus Hagander wrote:
>
>>
>>
>>
>> http://www.pgbuildfarm.org/**cgi-bin/show_status.pl<http://www.pgbuildfarm.org/cgi-bin/show_status.pl>
>>
>> ...it
On Mon, Nov 5, 2012 at 6:10 PM, Robert Haas wrote:
> On Mon, Nov 5, 2012 at 9:57 AM, Stephen Frost wrote:
> > Magnus,
> >
> > * Magnus Hagander (mag...@hagander.net) wrote:
> >> I have no idea what platform that would be. Both the standard
> >> implem
On Mon, Oct 22, 2012 at 4:24 PM, Stephen Frost wrote:
> Magnus, all,
>
> * Magnus Hagander (mag...@hagander.net) wrote:
> > On Thu, Oct 18, 2012 at 5:59 PM, Robert Haas
> wrote:
> > > That seems like a sufficiently long deprecation window, but is gssapi
> >
That message just means it's stuck in moderation. You just have to wait for
a moderator to approve it (which I just did now)
/Magnus
On Nov 5, 2012 10:19 AM, "Pavel Stehule" wrote:
> Hello
>
> I cannot to send a patch to mailing list
>
> Regards
>
> Pavel Stehule
>
>
> -- Forwarded messa
On Fri, Nov 2, 2012 at 2:19 AM, Greg Smith wrote:
> On 10/31/12 12:17 PM, Magnus Hagander wrote:
>
> The idea at the time was to use the include *directory* functionality,
>> for say a "config.d" directory in pgdata. The builtin one would then
>> use a predictable
le don't build this stuff themselves.
Being able to automate it across many machines is bigger, but most
people solve that today with things like puppet and chef.
Being able to build a nice configuration interface into something like
pgadmin is something that a lot of people ask for - but that
On Oct 23, 2012 4:52 PM, "Alvaro Herrera" wrote:
>
> Boszormenyi Zoltan escribió:
>
> > >>Also, the check for conflict between -R and -x/-X is now removed.
> >
> > The documentation for option -R has changed to reflect this and
> > there is no different error code 2 now: it would make the behaviou
everyone, but we can do it in our own tools... Particularly since
we do print the SSL information already - we could just add a
"warning: cert not verified" or something like that to the same piece
of information.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://ww
On Thu, Oct 18, 2012 at 5:59 PM, Robert Haas wrote:
> On Thu, Oct 18, 2012 at 7:20 AM, Magnus Hagander wrote:
>> Since Simon stirred up a hornets nest suggesting deprecation of a
>> number of features, I figured I'd take it one step further and suggest
>> removal of
On Thu, Oct 18, 2012 at 1:32 PM, Simon Riggs wrote:
> On 18 October 2012 12:20, Magnus Hagander wrote:
>
>> 2. ident-over-unix-sockets was renamed to "peer" in 9.1, with the old
>> syntax deprecated but still mapping to the new one. Has it been there
>> long en
with the old
syntax deprecated but still mapping to the new one. Has it been there
long enough that we should start throwing an error for ident on unix?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
ave to read up on the details in order to get
secure whether it's on by default or not - that's why I think it's
hard to call it either right or wrong, but it's rather somewhere in
between.
They also enable things like encryption on all localhost connections.
I consider that pl
On Sat, Oct 13, 2012 at 9:12 PM, Bruce Momjian wrote:
> On Sat, Oct 13, 2012 at 09:10:05PM +0200, Magnus Hagander wrote:
>> >> > I think the idea of having the short descriptions in SQL and longer ones
>> >> > in SGML is not maintainable. One idea would be to cl
be to place SGML comment markers
> around text we want to extract from overly-long SGML descriptions.
> Descriptions without SGML comments would be extracted unchanged.
Not sure how convenient that is, but it would certainly work. And it
would be a lot better than cutting off at word or character limits or
anything like that.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
fortunately, not a chance I'll have a time to look at any
of that until after pgconf.eu. Sorry.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On Oct 6, 2012 3:00 AM, "Peter Eisentraut" wrote:
>
> src/backend/replication/Makefile calls bison with -d to create a
> repl_gram.h header file, but that is not used anywhere. Is this an
> oversight?
That's probably a copy/paste caused oversight. I don't recall any
particular reason for it.
/M
On Wed, Oct 3, 2012 at 10:37 AM, Boszormenyi Zoltan wrote:
> Hi,
>
> 2012-10-03 10:25 keltezéssel, Magnus Hagander írta:
>>
>> On Tue, Jul 3, 2012 at 9:47 PM, Peter Eisentraut wrote:
>>>
>>> On mĺn, 2012-07-02 at 01:10 +0900, Fujii Masao wrote:
>>
ork on the things discussed in this thread? I
notice the patch is sitting with "waiting on author" in the CF app -
so the second question is that if you are doing that, do you think it
will be done within the scope of the current CF?
--
Magnus Hagander
Me: http://www.hagander.net
P
On Oct 2, 2012 5:04 PM, "Euler Taveira" wrote:
>
> On 02-10-2012 10:15, Peter Geoghegan wrote:
> > There are other, similar tools that exist in proprietary databases.
> > They expose a hash value, which is subject to exactly the same caveats
> > as our own. They explicitly encourage the type of
> and that's a problem).
Looks good to me, +1.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Oct 1, 2012 at 4:10 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> Can we please expose the internal hash id of the statements in
>> pg_stat_statements?
>
>> I know there was discussions about it earlier, and it wasn't done with
>> an argument of i
ent (which can happen for example when a table is dropped and
recreated). And even without that, in order to do anything useful with
it, you end up hashing the query text anyway - so using the already
existing hash would be easier and more useful.
--
Magnus Hagander
Me: http://www.hagander.net/
eally, is
there? Which is why I think most people just don't use it.
pg_basebackup in tar format is a much more useful thing, of course...
So we could fix just pg_basebackup in backbranches (since we never
read anything, it shouldn't be that big a problem), and then do
pg_dump in HEAD only?
On Fri, Sep 28, 2012 at 12:45 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> Ah, yeah, that should also work I guess. But you could also just leave
>> the the data in the temporary tarfile the whole time. IIRC, you can
>> just cat one tarfile to the end of another o
1101 - 1200 of 4991 matches
Mail list logo
