Re: [HACKERS] New pg_upgrade data directory inside old one?

Interesting - 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/

Re: [HACKERS] Refectoring of receivelog.c

On Mon, Feb 15, 2016 at 7:15 AM, Craig Ringer <cr...@2ndquadrant.com> wrote: > On 15 February 2016 at 04:48, Magnus Hagander <mag...@hagander.net> wrote: > >> I was working on adding the tar streaming functionality we talked about >> at the developer meeting to

[HACKERS] Refectoring of receivelog.c

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://www.redpill-linpro.com

Re: [HACKERS] Defaults for replication/backup

On Sun, Feb 14, 2016 at 2:00 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Sat, Feb 13, 2016 at 11:31 AM, Andres Freund <and...@anarazel.de> > wrote: > > On 2016-02-13 11:10:58 -0500, Tom Lane wrote: > >> Magnus Hagander <mag...@hagander.net> writes:

[HACKERS] Defaults for replication/backup

colors :P -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] Defaults for replication/backup

On Sat, Feb 13, 2016 at 2:39 PM, Andres Freund <and...@anarazel.de> 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: >

Re: [HACKERS] Defaults for replication/backup

e use PITR. The one that I see 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

Re: [HACKERS] Defaults for replication/backup

On Sat, Feb 13, 2016 at 4:52 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@hagander.net> writes: > > Yes, these changes will increase some of the default overhead. My > argument > > against that is that anybody who actually cares about that over

[HACKERS] pg_basebackup vs WAL fetching

m, 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/

[HACKERS] pl/pgsql exported functions

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/plpgsql/src/pl_comp.c

Re: [HACKERS] Updated backup APIs for non-exclusive backups

On Wed, Feb 10, 2016 at 4:38 PM, David Steele <da...@pgmasters.net> 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 back

Re: [HACKERS] Updated backup APIs for non-exclusive backups

On Wed, Feb 10, 2016 at 2:46 PM, Andres Freund <and...@anarazel.de> 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 su

[HACKERS] Updated backup APIs for non-exclusive backups

n 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.redpill-linpro.com/ *** a/doc/src/sgml/func.sgm

Re: [HACKERS] 2016-01 Commitfest

hopefully we're not letting 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/

Re: [HACKERS] pgcommitfest reply having corrupted subject line

On Fri, Feb 5, 2016 at 3:44 AM, Noah Misch <n...@leadboat.com> 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 <n...@leadboat.com> wrote: > > > The following message, which b

Re: [HACKERS] pgcommitfest reply having corrupted subject line

a206a170a99a7610cdbacc6b#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 oth

Re: [HACKERS] pg_lsn cast to/from int8

On Tue, Jan 26, 2016 at 4:58 PM, Craig Ringer <cr...@2ndquadrant.com> wrote: > On 26 January 2016 at 22:07, Magnus Hagander <mag...@hagander.net> wrote: > > >> In this case, mostly legacy compatibility. Making an app that works with >> versions that don't hav

Re: [HACKERS] Add links to commit fests to patch summary page

On Tue, Feb 2, 2016 at 1:35 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Magnus Hagander wrote: > > On Tue, Feb 2, 2016 at 2:46 AM, Jim Nasby <jim.na...@bluetreble.com> > wrote: > > > > > On 2/1/16 6:15 PM, Alvaro Herrera wrote: > > >

Re: [HACKERS] Add links to commit fests to patch summary page

On Tue, Feb 2, 2016 at 4:43 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> 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

Re: [HACKERS] Add links to commit fests to patch summary page

fest in the breadcrumbs at the 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 comme

Re: [HACKERS] Comment typos in source code: s/thats/that is/

On Thu, Jan 28, 2016 at 1:39 PM, Michael Paquier <michael.paqu...@gmail.com> 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/

Re: [HACKERS] Template for commit messages

On Mon, Feb 1, 2016 at 1:04 PM, Andres Freund <and...@anarazel.de> 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

Re: [HACKERS] Template for commit messages

or that (author != 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

[HACKERS] New committer

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/

[HACKERS] pg_lsn cast to/from int8

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/

Re: [HACKERS] pg_lsn cast to/from int8

On Tue, Jan 26, 2016 at 3:00 PM, Andres Freund <and...@anarazel.de> 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 o

Re: [HACKERS] Releasing in September

that I'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/

Re: [HACKERS] silent data loss with ext4 / all current versions

named backup file similarly). >> > > OK > > 2) In writeTimeLineHistoryFile, similarly we don't need to care >> much, in WalRcvFetchTimeLineHistoryFiles recovery would take again >> the same path >> > > OK > > >> Thoughts? >> >> &g

Re: [HACKERS] Releasing in September

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

Re: [HACKERS] Releasing in September

On Wed, Jan 20, 2016 at 6:18 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@hagander.net> writes: > > On Wed, Jan 20, 2016 at 5:19 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> I do not think commitfest length is the problem (though sure

Re: [HACKERS] Releasing in September

On Wed, Jan 20, 2016 at 5:19 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@hagander.net> writes: > > On Jan 20, 2016 5:03 PM, "Andres Freund" <and...@anarazel.de> wrote: > >> FWIW, looking at the last few commitfests, aside heroi

Re: [HACKERS] Releasing in September

away". > > 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/

Re: [HACKERS] Releasing in September

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

Re: [HACKERS] Comment typo in port/atomics/generic.h

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/

Re: [HACKERS] Close handle leak in SSPI auth

till leak it in a number of 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/

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

ple as well. That's not necessarily a bad thing. But thinking that having such an issue tracker is actually going to help *get rid of* the pointless part of things is a nice dream, but just a dream. The only advantage I can see of it is to increase the visibility of them. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] Why doesn't src/backend/port/win32/socket.c implement bind()?

ockets doesn't have the > equivalent of some of the socket API's. > > I think here we should add a win32 wrapper over bind and listen > API's which ensures TranslateSocketError() should be called for > error cases. > Yeah, that seems like a good idea. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

be easy to find old items. >> >> Bonus points if we attract some volunteer project managers that will >> keep tabs of all those kinds of things... >> > > /me waves hand > > There are quite a few contributing companies that likely have people that > co

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Fri, Jan 8, 2016 at 4:07 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@hagander.net> writes: > > On Thu, Jan 7, 2016 at 10:57 PM, Joshua D. Drake <j...@commandprompt.com> > >> There are quite a few contributing companies that likely ha

Re: [HACKERS] Duplicate 'use' for TestLib in 001_ssltests.pl

est/ssl/t/001_ssltests.pl > > @@ -2,7 +2,6 @@ use strict; > > use warnings; > > use PostgresNode; > > use TestLib; > > -use TestLib; > > use Test::More tests => 38; > > use ServerSetup; > > use File::Copy; > > Nice catch. Yes that's an

Re: [HACKERS] Comment typo in port/atomics/arch-x86.h

On Fri, Jan 8, 2016 at 7:37 AM, Tatsuro Yamada <yamada.tats...@lab.ntt.co.jp > wrote: > Hi, > > I found a typo in arch-x86.h. > The attached patch fixes a typo: s/468/486/g > > Applied, thanks. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

[HACKERS] Commitfest app

an hour, but I'll let you know when it's done as it might be a bit longer. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] Commitfest app

On Wed, Jan 6, 2016 at 4:50 PM, Magnus Hagander <mag...@hagander.net> wrote: > Hi! > > I'm about to start some upgrades on the machine running > commitfest.postgresql.org. The app itself won't change, but the > underlying OS and webserver will, so there will be some dis

Re: [HACKERS] commitfest html - wrong closing tag

On Sun, Jan 3, 2016 at 11:25 AM, Erik Rijkers <e...@xs4all.nl> wrote: > On 2016-01-03 10:06, Magnus Hagander wrote: > >> On Sun, Jan 3, 2016 at 9:26 AM, Erik Rijkers <e...@xs4all.nl> wrote: >> >>> an erroneous ''. It should be ''. >>> >>

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

e with the new code has been out for a while, but make sure we get it into the next set of minors? That'll give us at least some real world deployment to notice any issues with it? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] commitfest html - wrong closing tag

is indeed obviously wrong. Fixed and deployed. ( http://git.postgresql.org/gitweb/?p=pgcommitfest2.git;a=commitdiff;h=3d583f3fb0184b4858395a385438e4cb22080612 ) Is there a particular thing you're trying to parse the data out for? As in is there some data that we should already be providing in a

Re: [HACKERS] Maintenance on git.postgresql.org

On Tue, Dec 22, 2015 at 2:56 PM, Magnus Hagander <mag...@hagander.net> wrote: > I'm going to run some upgrade tasks on git.postgresql.org over the next > hour or two. Thus it's likely to drop off the net a few times and come > back, and things might work on and off. > > A

Re: [HACKERS] Remove Windows crash dump support?

hat has since improved considerably. >> >> The feature was also included in 9.4 >> > > Ahem. 9.1. This is what I get for multi-tasking between writing this and > packaging an extension for 9.4. > > In which version(s) of Windows was this improvement added? I think that's r

[HACKERS] Maintenance on git.postgresql.org

strange error messages :) Also, expect the web management interface to be offline a bit longer than the actual git server. This does *not* affect gitmaster, just git.postgresql.org. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] pg_stat_replication log positions vs base backups

On Wed, Dec 16, 2015 at 8:34 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Mon, Dec 14, 2015 at 8:59 AM, Michael Paquier > <michael.paqu...@gmail.com> wrote: > > On Mon, Dec 14, 2015 at 1:01 AM, Magnus Hagander <mag...@hagander.net> > wrote: > &

Re: [HACKERS] pg_stat_replication log positions vs base backups

On Fri, Nov 27, 2015 at 6:07 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Thu, Nov 26, 2015 at 10:53 PM, Magnus Hagander <mag...@hagander.net> > wrote: > > On Thu, Nov 26, 2015 at 1:03 PM, Michael Paquier < > michael.paqu...@gmail.com> > > wro

Re: [HACKERS] El Capitan Removes OpenSSL Headers

s > on some other Mac. > Presumably the folks who build Postgres.app and the EDB installers will take care of that for the big majority of people though, won't they? I agree it's something we should fix, but I'm not sure it's that urgent. It's no different from what Windows people h

Re: [HACKERS] New email address

s "we hope it works". (Yes, I have official responses from google paid support saying they only support scenarios where both sender and receiver is on gmail) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] Redefine default result from PQhost()?

On Thu, Nov 26, 2015 at 4:48 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@hagander.net> writes: > > On Wed, Nov 25, 2015 at 11:59 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> I think we should [ return DEFAULT_PGSOCKET_DIR not NULL ] >

Re: [HACKERS] New email address

on appear in Gmail but doesn't currently seem to > work. It's not clear if it will though since Gmail seems to think it's > associated with the sender -- i.e. that all emails are spam. > Do you have any examples of lists where it *does* work? LIke, could it be because our list-unsu

Re: [HACKERS] pg_stat_replication log positions vs base backups

On Thu, Nov 26, 2015 at 8:17 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > > > On Wed, Nov 25, 2015 at 11:08 PM, Magnus Hagander <mag...@hagander.net> > wrote: > >> On Wed, Nov 25, 2015 at 3:03 PM, Michael Paquier < >> michael.paqu...@gmail.co

Re: [HACKERS] Redefine default result from PQhost()?

al change, this would be for HEAD only. > > Comments? > I agree with this change in genera. But I wonder if there's a risk here that we break some applications isnt' it? It's clearly a backwards incompatible change, so wouldn't it require a bump of libpq version? And I'm not sure it's worth that on it's own... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] pg_stat_replication log positions vs base backups

On Thu, Nov 26, 2015 at 1:03 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Thu, Nov 26, 2015 at 6:45 PM, Magnus Hagander wrote: > > I'm only talking about the actual value in pg_stat_replication here, not > > what we are using internally. These are two diffe

[HACKERS] pg_stat_replication log positions vs base backups

. Where we have output like: state| backup sent_location| 0/0 write_location | 2/76CE flush_location | 2/76CC replay_location | 2/76CBF938 I'm thinking those fields should probably all be NULL for state=backup? -- Magnus Hagander Me: http://www.hagander.net/ Work: http

Re: [HACKERS] pg_stat_replication log positions vs base backups

On Wed, Nov 25, 2015 at 10:19 AM, Magnus Hagander <mag...@hagander.net> wrote: > Are the values for the log locations really relevant for backup > connections? And if they are, we need to document it :) ISTM we are just > more or less leaking random data out there? > &

Re: [HACKERS] pg_stat_replication log positions vs base backups

On Wed, Nov 25, 2015 at 3:03 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > > > On Wed, Nov 25, 2015 at 7:18 PM, Magnus Hagander <mag...@hagander.net> > wrote: > >> >> On Wed, Nov 25, 2015 at 10:19 AM, Magnus Hagander <mag...@hagander.net>

Re: [HACKERS] New email address

On Tue, Nov 24, 2015 at 4:00 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > > Magnus Hagander wrote: > >> That's a direct effect of the dmarc policy change. Yahoo no longer > supports > >> their c

Re: [HACKERS] New email address

On Tue, Nov 24, 2015 at 12:58 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Magnus Hagander wrote: > > > That's a direct effect of the dmarc policy change. Yahoo no longer > supports > > their customers using mailing lists. They changed their policies for suc

Re: [HACKERS] New email address

On Nov 24, 2015 01:05, "Michael Paquier" wrote: > > On Tue, Nov 24, 2015 at 3:41 AM, Kevin Grittner wrote: > > Yahoo recently changed their DMARC policy, and after some > > investigation and a support case with Yahoo, it is now clear that > > their

Re: [HACKERS] Uh-oh: documentation PDF output no longer builds in HEAD

we may be closer > than we realized to exceeding the strings limit in the back branches too. > Impressive, indeed. When you say it's half the size - is that half the size of the preprocessed PDF or is it also after the stuff we do on the website PDFs using jpdftweak? IIRC that tweak is only there t

Re: [HACKERS] Uh-oh: documentation PDF output no longer builds in HEAD

On Tue, Nov 10, 2015 at 6:15 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@hagander.net> writes: > > When you say it's half the size - is that half the size of the > preprocessed > > PDF or is it also after the stuff we do on the website

Re: [HACKERS] Better name for PQsslAttributes()

hts? I'm leaning towards changing it now. Uh, just to be clear, we been in beta for a month now, beta1 was released Oct 8. We are not just about to enter it... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

ieved by pg_cancel_backend. > Not when the session is idle in transaction, only when it's actually doing something. IIRC one of the reasons is that when idle in transaction, the client is not expecting any response, and would get out of sync. I know this has been discussed a number of times, so

Re: [HACKERS] Avoid full page images in streaming replication?

On Oct 22, 2015 23:38, "Tom Lane" wrote: > > Jim Nasby writes: > > ISTM it should be possible to avoid sending full page writes to a > > streaming replica once the replica has reached a consistent state. I > > assume that the replica would still need

Re: [HACKERS] bugs and bug tracking

, because anything which causes horizontal >> scrolling makes me sad. >> >> > Perhaps we need some sort of tinyurl gadget? > We have one - postgr.es. Right now it's only really used by the API from planet postgres, but we could certainly make that possible. But that adds yet another step, doesn't it, making it take longer? And one more system dependency. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] Postgres service stops when I kill client backend on Windows

ss... > +1. It feels like we're setting our selves up for repeating this mistake at some later time :) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] Postgres service stops when I kill client backend on Windows

s/taskkill.mspx?mfr=true It does. If you want a "gracefull kill" on Windows, you must use "pg_ctl kill" which can send an "emulated term-signal". -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] Postgres service stops when I kill client backend on Windows

On Sun, Oct 11, 2015 at 4:32 PM, Andrew Dunstan <and...@dunslane.net> wrote: > > > On 10/11/2015 05:58 AM, Magnus Hagander wrote: > >> >> >> On Sun, Oct 11, 2015 at 5:55 AM, Michael Paquier < >> michael.paqu...@gmail.com <mailto:michael.paqu...@g

Re: [HACKERS] Postgres service stops when I kill client backend on Windows

up :) We do get, AIUI, the SEC_COMMIT behaviour which commits the pages initially to make sure there is actually space for them. I don't believe that one specifically says anything about when you close it. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] bugs and bug tracking

On Wed, Oct 7, 2015 at 4:56 PM, Stephen Frost <sfr...@snowman.net> wrote: > > * Magnus Hagander (mag...@hagander.net) wrote: > > On Wed, Oct 7, 2015 at 4:40 PM, Stephen Frost <sfr...@snowman.net> > wrote: > > > * Nathan Wagner (nw...@hydaspes.if.org) wro

Re: [HACKERS] bugs and bug tracking

his is why we don't consider this a bug > --- > Oh, so debbugs actually breaks the reply-all workflow for *all* emails? That would mean that bug emails are now handled differently from regular emails on -hackers for example, wouldn't it? That seems like it's going to cause issues. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] bugs and bug tracking

a schedule. I don't recall exactly how often. However - Nathan, I'd suggest you don't focus too hard on that. As I said before if we go somewhere with this in the end, it should use the APIs to get the data, in which case they will be instant as Alvaro says. Some delay during testing should not be a

Re: [HACKERS] bugs and bug tracking

uld be > > far worse than the problem. > > Agreed; but adding a Reply-To: header seems quite reasonable. (Unless > gmail ignores that, which I wouldn't put past it ...) > It does not. I'm sure there's *some* MUA out there that does, but probably not the big ones. -- Ma

Re: [HACKERS] bugs and bug tracking

ole point is that those who prefer the email-only workflow should be able to keep that one. If someone doesn't want them, it's easy enough to filter them in the MUA. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] bugs and bug tracking

at's how it works :) Maybe we need a "question" form thta does the same thing but doesn't assign a bugid and just sends an email to -general instead? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] No Issue Tracker - Say it Ain't So!]

On Mon, Oct 5, 2015 at 2:08 AM, Nathan Wagner wrote: > On Sun, Oct 04, 2015 at 04:30:49PM -0700, Josh Berkus wrote: > > That would be the key part, wouldn't it? Nice that you have [code to > > store and parse email messages]. > > Yeah. It actually made most of the work

Re: [HACKERS] No Issue Tracker - Say it Ain't So!]

should fix it. Using something like submit...@postgresql.org. But we should also make it possible to assign a bug post-email. Someone might email -general with a bug report, and it's a lot more friendly to just assign ita bug than to say "hey take this thing you just wrote and re-

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

Extra Work. I think when a patch is directly related to a specific bug as reported through the webform, don't most committers already refer to that bug number? Maybe not every time, but at least most of the time? It's the many discussions that don't actually have a bug number and yet result in a patch that don't? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

banner up in the page header which > > says "this system is currently beta and not yet the canonical source for > > postgres bug information". That way, if it does become the canonical > > source, we won't go breaking everyone's links when we change the domain > > name. &

Re: [HACKERS] Fwd: [Snowball-discuss] New website

ling list > snowball-disc...@lists.tartarus.org > http://lists.tartarus.org/mailman/listinfo/snowball-discuss > > > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > > -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] Add support for RADIUS passwords longer than 16 octets

Looks good to me. Applied, thanks! As a note - psql truncates passwords at 100 characters when it reads it from the problem (in the connstr it's fine). Not sure we care enough to change that, though - I doubt it's a very common usecase for psql... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] commitfest does not see my real latest patch

etwork issues have been fixed (people are working on it right now). So please give it some time (the job runs every couple of hours), and with luck it will sort itself out before too long. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] Proposal: Implement failover on libpq connect level.

pletely ignore the ttl by default (like, uh, java, which you may have run into - at least it used to do that), or enforces a lower minimum of longer than you want in order to decrease load, and things like that. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] Information of pg_stat_ssl visible to all users

On Sep 1, 2015 4:37 AM, "Michael Paquier" wrote: > > On Tue, Sep 1, 2015 at 4:23 AM, Peter Eisentraut wrote: > > On 8/31/15 9:13 AM, Andres Freund wrote: > >> I'm just saying that we should strive to behave at least somewhat > >> consistently, and

Re: [HACKERS] perlcritic

On Sep 1, 2015 6:25 AM, "Michael Paquier" wrote: > > On Tue, Sep 1, 2015 at 12:57 PM, Peter Eisentraut wrote: > > We now have 80+ Perl files in our tree, and it's growing. Some of those > > files were originally written for Perl 4, and the coding

Re: [HACKERS] Commitfest remaining "Needs Review" items

gt; Thanks! > > Ugh. Good to have it closed, but it seems we're still in continous-commitfest mode :( Anyway - that CF is closed, but we seem to not have *any* CF open at this point. Should we not make 2015-11 open? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] Information of pg_stat_ssl visible to all users

On Mon, Aug 31, 2015 at 2:17 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Mon, Aug 31, 2015 at 9:04 PM, Magnus Hagander <mag...@hagander.net> > wrote: > > > > > > On Sun, Aug 30, 2015 at 5:35 AM, Michael Paquier < > michael.paqu...@gmail.

Re: [HACKERS] Commitfest remaining "Needs Review" items

ption to display >> days in the CF app? >> > > +1 for making these dates more explicit > > Yeah. We actually *store* the dates in full, but it appears we don't actually show them anywhere I'll put on my list to display those - probably both on the index page and t

Re: [HACKERS] Information of pg_stat_ssl visible to all users

d > nodes with Postgres embedded, and at least to me that's a real concern. > How is it a concern that a CN field with a random username in it is visible, when showing the actual random username isn't? That's not very consistent... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] Information of pg_stat_ssl visible to all users

that line. Client certificates don't show anything other than the username, unless you explicitly choose to put sensitive information in the CN. But we don't limit the view of the username in pg_stat_activity, even though people do put sensitive things in there (such as the customer name in case o

Re: [HACKERS] Supporting fallback RADIUS server(s)

On Thu, Aug 20, 2015 at 12:55 PM, Marko Tiikkaja ma...@joh.to wrote: On 8/20/15 12:53 PM, Magnus Hagander wrote: We could change it to radius_servers and radius_ports, and deprecate but keep accepting the old parameters for a release or two. That's one option.. To make it easy, we make

Re: [HACKERS] Supporting fallback RADIUS server(s)

. And we could consider throwing a WARNING or at least a LOG when the old name is used, indicating that it's deprecated. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] Supporting fallback RADIUS server(s)

On Aug 20, 2015 4:16 PM, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Thu, Aug 20, 2015 at 2:36 AM, Marko Tiikkaja ma...@joh.to wrote: On 2015-08-20 02:29, Tom Lane wrote: Why add new GUCs for that? Can't we just redefine radiusserver as a list

Re: [HACKERS] allowing wal_level change at run time

On Wed, Aug 19, 2015 at 3:34 PM, Andres Freund and...@anarazel.de wrote: On 2015-08-19 10:49:46 +0200, Magnus Hagander wrote: What happens the first time? Meaning I'm on wal_level=minimal and take a base backup. Then when the replica first connects 10 minutes later, it needs WAL back

Re: [HACKERS] allowing wal_level change at run time

is done -- but then you can't drop it back down again or your base backup will be useless. Or am I missing something? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

<    1   2   3   4   5   6   7   8   9   10   >