f it was, say, rejected? (so it would be copied to the new CF
but still marked rejected) Or is there a subset of behaviors you're looking
for?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
an do that. I'd suggest we either name it based on the current
tentative date for CF1 (september), or name it specificaly "9.7-first" or
something like that rather than just plain "future", to make it more clear.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Tue, Mar 1, 2016 at 10:12 AM, Alvaro Herrera
wrote:
> Magnus Hagander wrote:
> > On Tue, Mar 1, 2016 at 8:09 AM, Michael Paquier <
> michael.paqu...@gmail.com>
> > wrote:
> >
> > > Hi all,
> > >
> > > I guess that commit fest 2016-03 is
On Tue, Mar 1, 2016 at 3:40 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > On Tue, Mar 1, 2016 at 10:12 AM, Alvaro Herrera <
> alvhe...@2ndquadrant.com>
> > wrote:
> >> Magnus Hagander wrote:
> >>> Yeah, we can do that. I'd suggest we eit
On Tue, Mar 1, 2016 at 10:27 AM, Tom Lane wrote:
> Alvaro Herrera writes:
> > Magnus Hagander wrote:
> >> That said, we can certainly reconsider that. Would we always copy the
> value
> >> over? Even if it was, say, rejected? (so it would be copied to the new
>
On Wed, Mar 2, 2016 at 7:34 AM, Michael Paquier
wrote:
> On Wed, Mar 2, 2016 at 9:19 PM, Magnus Hagander
> wrote:
> > Needs Review -> Needs Review
> > Waiting on Author -> Refuse moving
> > Ready for committer -> Ready for Committer
> > Committed -> re
On Wed, Mar 2, 2016 at 5:07 PM, Marko Tiikkaja wrote:
> On 11/02/16 18:29, Magnus Hagander wrote:
>
>> Most of the pl/pgsql functions and variables are prefixed plpgsql_, so
>> they
>> don't risk conflicting with other shared libraries loaded.
>>
>>
d a lot of requests when it comes to replication),
and our response there has traditionally been "ssl compression"...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
ink. If
it's just the build system then it should be no problem, but I thought
Michael also suggested some API changes. If that's so, then it is going to
depend on how invasive those are. But that part should be done for HEAD
regardless, so it's definitely worth the effort to figure out exactly what
it involves.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Thu, Mar 3, 2016 at 6:34 PM, Andres Freund wrote:
> On 2016-03-03 18:31:03 +0100, Magnus Hagander wrote:
> > I think we want it at protocol level rather than pg_basebackup level.
>
> I think we may want both eventually, but I do agree that protocol level
> has a lot high
do it.
> In short, no worries, 100% happy that JPUG is taking initiative.
>
>
I also see no problem at all with this.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
po to me :)
>
> See attached patch (for 9.5 and HEAD).
>
>
Yeah, not only was it written twice, it was written twice twice :)
Applied! Thanks!
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
and these conditions flip the
> switch exactly then.
>
Well, it doesn't flip it based on the specifics "running on a CPU with
AVX2". But presumably turning of AVX2 if the CPU doesn't support it is a
no-op.
> Without that, I'd be worried that
> > this cure is worse than the disease because it breaks cases that
> > weren't broken before.
>
> Isn't that what the buildfarm is (among other things) for?
>
The buildfarm doesn't really have a big spread of Windows animals,
unfortunately.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Wed, Mar 9, 2016 at 4:36 PM, Christian Ullrich
wrote:
> * Magnus Hagander wrote:
>
> On Sat, Feb 13, 2016 at 4:45 PM, Christian Ullrich
>> wrote:
>>
>
> On February 13, 2016 4:10:34 PM Tom Lane wrote:
>>>
>>
> I'm also suspicious of the &q
the header and body
section of the patch, which seems wrong. I used the one from the actual
implementation (_M_AMD64) for the header includes as, and also merged the
#ifdef's together to a single #if in each section. Please verify!
Thanks for a very good analysis and patch, and for good explanations of the
details! :)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
y-paste coding.
>
> +1. Frustrating Citus's attempt to open-source their stuff is not in
> the project's interest.
>
>
Agreed. And it's not like we're very restrictive with this in a lot of
other parts of the code. While we shouldn't go out of our way fo
On Fri, Mar 11, 2016 at 9:40 AM, Daniel Gustafsson wrote:
> > On 15 Feb 2016, at 14:46, Magnus Hagander wrote:
> >
> > On Mon, Feb 15, 2016 at 7:15 AM, Craig Ringer <mailto:cr...@2ndquadrant.com>> wrote:
> > On 15 February 2016 at 04:48, Magnus Hagander &l
t_query_sampled = (random() < auto_explain_sample_ratio *
+ MAX_RANDOM_VALUE);
Not sure what the overhead is, but wouldn't it be better to include a check
for current_query_sampled>0 in the if part of that statement? Regardless
of performance, that feels cleaner to me. Or am I missing something?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
mpatible name if no
+ explicit user name is specified. If you use
+ libpq (e.g. through the ODBC driver), you should
+ leave this option disabled.
What's the actual usecase where it makes sense to change it? Seems that's
the more reasonable thing to document, with a reference to active directory
specifically (or is there also such a compatible name for local accounts?)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Fri, Mar 11, 2016 at 2:51 PM, Julien Rouhaud
wrote:
> On 11/03/2016 11:45, Magnus Hagander wrote:
> >
> > Coming back to the previous discussions about random() - AFAICT this
> > patch will introduce the random() call always (in explain_Execut
On Fri, Mar 11, 2016 at 3:03 PM, Magnus Hagander
wrote:
>
>
> On Fri, Mar 11, 2016 at 2:51 PM, Julien Rouhaud > wrote:
>
>> On 11/03/2016 11:45, Magnus Hagander wrote:
>> >
>> > Coming back to the previous discussions about random() - AFAICT this
>
On Sun, Mar 13, 2016 at 12:15 AM, Tomas Vondra wrote:
> On 03/11/2016 11:15 AM, Magnus Hagander wrote:
>
>>
>> ...
>
>>
>>
>> Pushed with updated comments and a named stsruct.
>>
>
> Pretty sure this memset call in pg_basebackup.c is inco
stake in the documentation :/
>
> Attached patch fixes both.
>
>
I also agree, and thanks for doing the work :) Applied!
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
issues in the patch. Please
> provide an updated patch soon or I will mark this "returned with feedback".
>
>
Hi!
Thanks for the note - I had missed Marco's response completely!
I'll take a look at it once Nordic PGDay is done!
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
e old and the new code in it.
I've attached an updated patch, which is rebased on current master and
includes the oid fix.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index ae93e69..cb1ea71
else has the cycles to do it in time for 9.6,
please do.
I have marked the patch as returned with feedback.
>
>
Yeah, unfortunately I think that's probably right. Let's focus on things
that have a better chance of making it.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Tue, Mar 22, 2016 at 5:08 PM, David Steele wrote:
>
> On 3/19/16 8:15 AM, Magnus Hagander wrote:
>
> > I've attached an updated patch, which is rebased on current master and
> > includes the oid fix.
>
> Before doing a thorough review of this patch there ar
On Tue, Mar 22, 2016 at 5:27 PM, David Steele wrote:
> On 3/22/16 12:14 PM, Magnus Hagander wrote:
> > On Tue, Mar 22, 2016 at 5:08 PM, David Steele > <mailto:da...@pgmasters.net>> wrote:
> >
> > On 3/19/16 8:15 AM, Magnus Hagander wrote:
> >
> >
; src/interfaces/ecpg/preproc/kwlookup.c ->
> ../../../../src/backend/parser/kwlookup.c
> src/bin/initdb/encnames.c -> ../../../src/backend/utils/mb/encnames.c
> src/interfaces/libpq/encnames.c -> ../../../src/backend/utils/mb/encnames.c
>
> which seem like they'd be bette
7;t think your summary is right.
pg_basebackup in tar mode can be sent to stdout, does not require a
directory. And the same for pg_dump in any mode except for directory. So we
can't just drive it off the mode, some more detailed checks are required.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Mon, Mar 28, 2016 at 3:12 PM, Andres Freund wrote:
> On 2016-03-28 11:35:57 +0200, Magnus Hagander wrote:
> > On Mon, Mar 28, 2016 at 3:11 AM, Michael Paquier <
> michael.paqu...@gmail.com>
> > wrote:
> >
> > > On Mon, Mar 28, 2016 at 8:30 AM, Andres Fre
On Tue, Mar 29, 2016 at 8:46 AM, Jim Nasby wrote:
> On 3/28/16 11:03 AM, Magnus Hagander wrote:
>
>>
>> That should work yeah. And given that we already use that check in other
>> places, it seems it should be perfectly safe. And as long as we only do
>> a WARN
On Tue, Mar 29, 2016 at 10:12 AM, Andres Freund wrote:
> On 2016-03-29 10:06:20 +0200, Magnus Hagander wrote:
> > On Tue, Mar 29, 2016 at 8:46 AM, Jim Nasby
> wrote:
> >
> > > On 3/28/16 11:03 AM, Magnus Hagander wrote:
> > >
> > >>
> > &
obably not, since it's running in a backend already at that point, not
>> in postmaster.
>>
>
> It seems like this patch should be set "ready for committer". Can one of
> the reviewers do that if appropriate?
>
I'll pick it up to do that as well as committing it.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Tue, Mar 29, 2016 at 4:36 PM, David Steele wrote:
> On 3/22/16 12:31 PM, Magnus Hagander wrote:
>
> On Tue, Mar 22, 2016 at 5:27 PM, David Steele > <mailto:da...@pgmasters.net>> wrote:
>>
> >
>
>> > Adding the stop time column should be a
On Tue, Mar 29, 2016 at 6:40 PM, Magnus Hagander
wrote:
>
>
> On Tue, Mar 29, 2016 at 4:36 PM, David Steele wrote:
>
>> On 3/22/16 12:31 PM, Magnus Hagander wrote:
>>
>> On Tue, Mar 22, 2016 at 5:27 PM, David Steele >> <mailto:da...@pgmasters.net>>
On Wed, Mar 30, 2016 at 4:10 AM, David Steele wrote:
> On 3/29/16 2:09 PM, Magnus Hagander wrote:
>
> > I had a chat with Heikki, and here's another suggestion:
> >
> > 1. We don't touch the current exclusive backups at all, as previously
> > discusse
On Wed, Mar 30, 2016 at 10:09 AM, Amit Kapila
wrote:
> On Tue, Mar 29, 2016 at 11:39 PM, Magnus Hagander
> wrote:
>
>> On Tue, Mar 29, 2016 at 6:40 PM, Magnus Hagander
>> wrote:
>>
>>> So - I can definitely see the argument for returning the stop wal
>>
=
> tap_tests => undef,# --enable-tap-tests
> tcl => undef,# --with-tls=
> Attached is a patch.
>
Aplied, thanks.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
the error paths in this case, but I don't
think we need to care about those -- since they are hard errors, the
process exits shortly thereafter anyway.
Applied and backpatched, thanks.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Fri, Jan 15, 2016 at 2:35 AM, Tatsuro Yamada <
yamada.tats...@lab.ntt.co.jp> wrote:
> Hi,
>
> I found a typo in generic.h
> The attached patch fixes it: s/tomic/atomic/g
>
Applied, thanks!
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Jan 20, 2016 5:03 PM, "Andres Freund" wrote:
>
> On 2016-01-20 10:55:07 -0500, Robert Haas wrote:
> > It's certainly true that we twiddled our thumbs quite a bit about
> > getting 9.5 ready to ship. However, the old process where nobody
> > could get anything committed for six months out of th
On Wed, Jan 20, 2016 at 5:19 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > On Jan 20, 2016 5:03 PM, "Andres Freund" wrote:
> >> FWIW, looking at the last few commitfests, aside heroic and
> >> unsustainable efforts by individual CF managers, I haven&#x
On Wed, Jan 20, 2016 at 6:18 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > On Wed, Jan 20, 2016 at 5:19 PM, Tom Lane wrote:
> >> I do not think commitfest length is the problem (though surely it's not
> >> working as intended). What happened with 9.5 is
On Jan 20, 2016 18:57, "Alvaro Herrera" wrote:
>
> Joshua D. Drake wrote:
>
> > 4. Submit a patch, review a patch.
> >
> > Don't review patches? Don't submit patches.
>
> Here's one area where the commitfest app could help the CFM. I would
> like to have a report that shows, for each person, the
>
>
Report added. You will find a new "Reports" button at the bottom of the CF
(as a CF admin) which has a link to it.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
very() we may finish with an
>> unnamed backup file similarly).
>>
>
> OK
>
> 2) In writeTimeLineHistoryFile, similarly we don't need to care
>> much, in WalRcvFetchTimeLineHistoryFiles recovery would take again
>> the same path
>>
>
&g
7;m all for giving it a try at least once. But so
far I don't recall seeing any actual propsal of that *directly*, more very
vague "there are things others could do". But if/when they do, I definitely
think it's worth trying.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Is there a reason we don't have casts between int8 and pg_lsn? AFAICT it
works fine if I create the cast manually... Is it because of
signed/unsigned if people have really really many transactions?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Tue, Jan 26, 2016 at 3:00 PM, Andres Freund wrote:
> On 2016-01-26 14:56:21 +0100, Magnus Hagander wrote:
> > Is there a reason we don't have casts between int8 and pg_lsn? AFAICT it
> > works fine if I create the cast manually... Is it because of
> > signed/unsi
!= committer in git),
but that changes how we work a bit more. I'd be happy to just clal it
"Author" rather than "Patch-by".
I also suggest a - in "Backpatch-through:" -- since all the others are
intentionally mad ewithout a space, I assume that's for easier
Hello!
The PostgreSQL core team would like to welcome Dean Rasheed as a new
committer for the PostgreSQL project.
Dean - welcome! Now let's see how quickly you can break the buildfarm!
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Thu, Jan 28, 2016 at 1:39 PM, Michael Paquier
wrote:
> Hi all,
>
> I found a couple of typos as per the $subject.
> A patch is attached.
>
Applied, thanks.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
the archives page, and
one could copy/paste that link into the commit message. That way we can
avoid the long messageids.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Mon, Feb 1, 2016 at 1:04 PM, Andres Freund wrote:
> On 2016-02-01 12:56:21 +0100, Magnus Hagander wrote:
> > Let's just assume that we can fix that part. As in, we can expose either
> an
> > internal db id or a short hash or something, from the archives server. We
&
e top of the page. Or am I misunderstanding completely?
> (You can actually construct the URL easily just by changing the
>> commitfest ID, which is the first number in the URL; for example 2016-01
>> is /8/).
>>
>
> *waits for someone to comment on how surrogate keys are bad*
>
But they're awesome when the developer is lazy! :) Patches welcome ;)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Tue, Jan 26, 2016 at 4:58 PM, Craig Ringer wrote:
> On 26 January 2016 at 22:07, Magnus Hagander wrote:
>
>
>> In this case, mostly legacy compatibility. Making an app that works with
>> versions that don't have pg_lsn have a nice path forward to the modern
>>
On Tue, Feb 2, 2016 at 1:35 PM, Alvaro Herrera
wrote:
> Magnus Hagander wrote:
> > On Tue, Feb 2, 2016 at 2:46 AM, Jim Nasby
> wrote:
> >
> > > On 2/1/16 6:15 PM, Alvaro Herrera wrote:
> > >
> > >> Jim Nasby wrote:
> > >>
> > >
On Tue, Feb 2, 2016 at 4:43 PM, Alvaro Herrera
wrote:
> Magnus Hagander wrote:
>
> > So from https://commitfest.postgresql.org/9/353/, you'd want links to
> > /8/353/, /7/353/, /6/353/?
>
> Right.
>
>
I'm not entirely sure what I'd use that for myself
acc6b#l355
the "subject" field in the db that we copy does not have the spaces... I
honestly have no idea where they are coming from :O I'm guessing it must be
something internally in the python libraries that create the MIME. Have you
seen this with any other messages, that you
On Fri, Feb 5, 2016 at 3:44 AM, Noah Misch wrote:
> On Thu, Feb 04, 2016 at 09:19:19AM +0100, Magnus Hagander wrote:
> > On Thu, Feb 4, 2016 at 7:26 AM, Noah Misch wrote:
> > > The following message, which bears "User-Agent: pgcommitfest",
> > >
> >
tting too many people
> down.
>
> I'm closing this commitfest now. We even have three weeks before the
> next one starts, so everybody can take a break for once! Yay!
Thanks for taking on the thankless task of pushing things along!
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
t section of the docs (also based on the
devmeeting). I will write up the docs once that is done (I assume it will
be soon enough, or I'll go do it regardless), but I wanted to get some
review in on the code while waiting.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.re
On Wed, Feb 10, 2016 at 2:46 PM, Andres Freund wrote:
> Hi,
>
> On 2016-02-10 13:46:05 +0100, Magnus Hagander wrote:
> > Per discussionat the developer meeting in Brussels, here's a patch that
> > makes some updates to the backup APIs, to support non-exclusive
On Wed, Feb 10, 2016 at 4:38 PM, David Steele wrote:
> On 2/10/16 7:46 AM, Magnus Hagander wrote:
> > Per discussion at the developer meeting in Brussels, here's a patch that
> > makes some updates to the backup APIs, to support non-exclusive backups
> > w
7;s only 2
variables and 2 functions.
AFAICT these are clearly meant to be internal. (the plugin variable is
accessed through find_rendezvous_variable)
Comments?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
*** a/src/pl/plpgsql/src/pl_comp.c
--- b/src/pl/p
X stream, as long as
pg_basebackup doesn't connect from the master until it has seen all it's
WAL.
Did I miss a thread somewhere saying this is not a good idea?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
n if I don't get to decide the colors :P
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Sat, Feb 13, 2016 at 2:39 PM, Andres Freund wrote:
> On 2016-02-13 22:37:33 +0900, Michael Paquier wrote:
> > On Sat, Feb 13, 2016 at 10:15 PM, Magnus Hagander wrote:
> > > So, I suggest the following changes to the defaults:
> > > wal_level=hot_stand
e is
> > archive_command and I am not sure how to deal with that.
>
> Since that requires additional setup anyway, I don't really see a
> comparable effect of such a move.
>
Also, you can reasonably do PITR without using
archive_command/archive_mode. Just use pg
On Sat, Feb 13, 2016 at 4:52 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > Yes, these changes will increase some of the default overhead. My
> argument
> > against that is that anybody who actually cares about that overhead is
> > going to be tuning their database *a
On Sun, Feb 14, 2016 at 2:00 AM, Robert Haas wrote:
> On Sat, Feb 13, 2016 at 11:31 AM, Andres Freund
> wrote:
> > On 2016-02-13 11:10:58 -0500, Tom Lane wrote:
> >> Magnus Hagander writes:
> >> > The big thing is, IIRC, that we turn off the optimizations in
&g
o work on the actual functionality I was working on to go on
top of this separately, but would appreciate a review of this part
independently. It's mostly mechanical, but there may definitely be mistakes
- or thinkos in the whole idea...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http
On Mon, Feb 15, 2016 at 7:15 AM, Craig Ringer wrote:
> On 15 February 2016 at 04:48, Magnus Hagander wrote:
>
>> I was working on adding the tar streaming functionality we talked about
>> at the developer meeting to pg_basebackup, and rapidly ran across the issue
>&
I definitely wouldn't have expected that either. And it
definitely seems like a foot-gun we should protect the users against.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
ast patch is from yesterday
>
> Attachment: plpython-enhanced-error-02.patch.gz
>
>
That's likely because it's not a patch. It's a python script. The tool
intentionally only looks for patches, to avoid triggering on things that
people put in their email signatures for example.
--
On Thu, Aug 18, 2016 at 7:06 AM, Michael Paquier
wrote:
> On Tue, Aug 16, 2016 at 6:22 PM, Magnus Hagander
> wrote:
> > I think what we want is basically the UNION ALL of all the different
> active
> > versions. If we just use the definitions from Win10, we will map
>
On Thu, Aug 18, 2016 at 3:26 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > On Thu, Aug 18, 2016 at 7:06 AM, Michael Paquier <
> michael.paqu...@gmail.com>
> > wrote:
> >> OK, so after re-running that on my Win10 station and a newly updated
> >> Win
On Thu, Aug 18, 2016 at 3:34 PM, Magnus Hagander
wrote:
>
>
> On Thu, Aug 18, 2016 at 3:30 PM, Tom Lane wrote:
>
>> Magnus Hagander writes:
>> > On Thu, Aug 18, 2016 at 3:26 PM, Tom Lane wrote:
>> >> If we got this done in the next couple weeks, any
On Thu, Aug 18, 2016 at 3:30 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > On Thu, Aug 18, 2016 at 3:26 PM, Tom Lane wrote:
> >> If we got this done in the next couple weeks, any resulting changes
> >> could go out in 9.6rc1. Given that we've not done this
blems with it now.
>
> As a similar topic, I wonder whether the following still holds true, after
> many improvements on shared buffer lock contention.
>
> https://www.postgresql.org/docs/devel/static/runtime-config-resource.html
>
> "The useful range for shared_buff
s well. But if we
change the default to something high and say "hey those of you who just run
it on a smaller system should recompile with a different --configure", we
are being *very* user-unfriendly. Or the other way around.
That doesn't mean we shouldn't change
configurable" as a way out. If we want it configurable *at all*, it
should be an initdb switch. If we are confident in our defaults, it doesn't
have to be.
I agree that #4 is best. I'm not sure it's worth the cost. I'm not worried
at all about the risk of master/slave sync thing, per previous statement.
But if it does have performance implications, per Andres suggestion, then
making it configurable at initdb time probably comes with a cost that's not
worth paying.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
t recompiling.
>
> I think you may be forgetting that "the base 3 WAL segments" is no
> longer the default configuration. checkpoint_segments=3 is history;
> we now have max_wal_size=1GB, which is a maximum of 64 WAL segments,
> not 3.
>
>
And obviously that'd be 16 files if we increase the wal segment size. So
the actual maximum size doesn't change, except you can currently set
max_wal_size to something lower than 64Mb. If we change, the minimum value
would become 64Mb, I assume.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
time as renaming these things makes a lot of sense, because it causes
breakage that tool-builders *have* to look at, and then they will hopefully
also notice the other change.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Aug 26, 2016 5:13 PM, "Joshua D. Drake" wrote:
>
> On 08/25/2016 07:39 PM, Michael Paquier wrote:
>>
>> Hi all,
>>
>> I am relaunching $subject as 10 development will begin soon. As far as
>> I know, there is agreement that we can do something here. Among the
>> different proposals I have found
On Aug 26, 2016 5:54 PM, "Peter Eisentraut" <
peter.eisentr...@2ndquadrant.com> wrote:
>
> On 8/25/16 10:39 PM, Michael Paquier wrote:
> > I am relaunching $subject as 10 development will begin soon. As far as
> > I know, there is agreement that we can do something here. Among the
> > different pro
or pg_xlog is a pretty common
> occurrence, and I don't think there's all that many tools that reference
> them. I think it's well worth renaming them.
>
Pretty sure every single backup tool or script out there is referencing
pg_xlog. If it's not, then it's broken...
p
cleaner but still somewhat meh way would be
int(float(server_version)). No need to mess around with regexps and extra
imports.
Long story short, I kind of agree that it might have been better to
> expose server_version_num rather than server_version in the beginning,
> but I'm not sure that it really helps anybody now, especially given
> our decision to simplify the version number format going forward.
>
Yeah, that's a strong point.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
e in a variable.
Finally, to make this work, the pring_tar_number() function is now exported
from port/tar.c along with the other ones already exported from there.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
diff --git a/doc/src/sgml/ref/pg_basebacku
On Thu, Sep 1, 2016 at 9:19 AM, Michael Paquier
wrote:
> On Thu, Sep 1, 2016 at 6:58 AM, Magnus Hagander
> wrote:
> > Attached patch adds support for -X stream to work with .tar and .tar.gz
> file
> > formats.
>
> Nice.
>
> > If tar mode is specified, a separ
On Thu, Sep 1, 2016 at 9:43 AM, Michael Paquier
wrote:
> On Thu, Sep 1, 2016 at 4:41 PM, Magnus Hagander
> wrote:
> > That's definitely not intended - it's supposed to be 16Mb. And it
> actually
> > writes 16Mb to the tarfile, it's the extraction that doe
On Aug 4, 2016 2:25 AM, "Michael Paquier" wrote:
>
> On Thu, Aug 4, 2016 at 12:09 AM, Fabrízio de Royes Mello
> wrote:
> > If there are no complains about my lack of experience in this field I
would
> > like do become the next CFM (am I the first brazilian??)
>
> That would be great. I am not sen
On Sep 1, 2016 17:44, "Fabrízio de Royes Mello"
wrote:
>
>
>
> On Thu, Sep 1, 2016 at 8:35 AM, Tom Lane wrote:
> >
> > Magnus Hagander writes:
> > >> On Thu, Aug 4, 2016 at 12:09 AM, Fabrízio de Royes Mello
> > >> wrote:
> > &
; segments to go missing.
>
>
Well, why do we provide a --nosync option for initdb? Wouldn't the argument
basically be the same?
I agree it kind of feels like overkill, but it would be consistent
overkill? :)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Sat, Sep 3, 2016 at 3:21 PM, Michael Paquier
wrote:
> On Sat, Sep 3, 2016 at 12:42 AM, Magnus Hagander
> wrote:
> > On Fri, Sep 2, 2016 at 8:50 AM, Michael Paquier <
> michael.paqu...@gmail.com>
> > wrote:
> >> On Fri, Sep 2, 2016 at 2:20 AM, Peter Eisentr
On Thu, Sep 1, 2016 at 2:39 PM, Michael Paquier
wrote:
> On Thu, Sep 1, 2016 at 5:13 PM, Magnus Hagander
> wrote:
> > We don't seem to check for similar issues as the one just found in the
> > existing tests though, do we? As in, we don't actually verify that the
>
so this was 10 years ago, so I'm of course not 100% sure, but I think it
was something like that...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Thu, Sep 8, 2016 at 2:53 PM, Michael Paquier
wrote:
> On Thu, Sep 8, 2016 at 9:39 PM, Magnus Hagander
> wrote:
> > Pretty sure this goes back to *our* XML support requiring both. As in you
> > couldn't turn on/off xslt independently, so the "xml requires xslt"
ackup onto a
different version of an operating system at least.
Sure, it would be even better if we could automatically *deal* with it. But
failing in a loud and obvious way is a *lot* better than silently returning
incorrect data...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
1 - 100 of 4991 matches
Mail list logo
