Re: [HACKERS] Snapshot too old logging

On Tue, Nov 15, 2016 at 9:23 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Magnus Hagander wrote: > > On Tue, Nov 15, 2016 at 8:22 PM, Robert Haas <robertmh...@gmail.com> > wrote: > > > > > On Tue, Nov 15, 2016 at 2:21 PM, Kev

[HACKERS] Re: [COMMITTERS] pgsql: Build HTML documentation using XSLT stylesheets by default

This seems to have broken our website build a bit. If you check https://www.postgresql.org/docs/devel/static/index.html, you'll notice a bunch of bad characters. AFAICT this is because the output is now UTF8 and it used to be LATIN1. The current output actually has it in the html tags that it's

Re: [HACKERS] Snapshot too old logging

was modified since the referencing (old) > > snapshot was taken. We don't don't know in what way it was > > modified, so we must assume that it *might* have been pruned of > > rows that the snapshot should still be able to see. > > Oh, yeah. So maybe "may have already been r

Re: [HACKERS] Snapshot too old logging

On Tue, Nov 15, 2016 at 7:43 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Nov 15, 2016 at 1:30 PM, Magnus Hagander <mag...@hagander.net> > wrote: > > On Tue, Nov 15, 2016 at 7:27 PM, Robert Haas <robertmh...@gmail.com> > wrote: > >> &g

Re: [HACKERS] Snapshot too old logging

On Tue, Nov 15, 2016 at 7:27 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Nov 15, 2016 at 1:18 PM, Magnus Hagander <mag...@hagander.net> > wrote: > > Is there value in showing which snapshot as well? Something like: > > DETAIL: snapshot is too ol

Re: [HACKERS] Snapshot too old logging

On Tue, Nov 15, 2016 at 5:29 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Kevin Grittner <kgri...@gmail.com> writes: > > On Tue, Nov 15, 2016 at 3:38 AM, Magnus Hagander <mag...@hagander.net> > wrote: > >> Is there a reason why we don't log which relation trig

[HACKERS] jsonb_delete with arrays

of working through a real world usecases where we needed to delete 7 keys from jsonb data, it shows approximately a 9x speedup over calling the - operator multiple times. I'm guessing since we copy a lot less and don't have to re-traverse the structure. -- Magnus Hagander Me: http://www.hagander.net

Re: [HACKERS] Physical append-only tables

On Mon, Nov 14, 2016 at 9:43 PM, Greg Stark <st...@mit.edu> wrote: > On Sun, Nov 13, 2016 at 3:45 PM, Magnus Hagander <mag...@hagander.net> > wrote: > > For a scenario like this, would it make sense to have an option that > could > > be set on an individual tab

[HACKERS] Snapshot too old logging

it wouldn't work? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] Physical append-only tables

On Mon, Nov 14, 2016 at 3:39 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@hagander.net> writes: > > What I'm talking about is something that would be a lot simpler than > > auto-clustering. I'm not even talking about trying to detect if th

Re: [HACKERS] Physical append-only tables

On Mon, Nov 14, 2016 at 2:35 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Magnus Hagander wrote: > > > But then consider the same table. Except rows are typically updated once > or > > twice when they are new, and *then* go read only. And we also have a >

[HACKERS] Physical append-only tables

a overhead on large tables that are more or less never deleted from. I've run into a number of cases recently where this would've made the BRIN indexes on huge tables *much* more efficient. At least, it seems to me they would :) Or am I missing something that would make this not work? -- Magnus Haga

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

On Sat, Nov 12, 2016 at 4:03 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Fri, Nov 11, 2016 at 3:01 PM, Magnus Hagander <mag...@hagander.net> > wrote: > >> > Based on this optimization we might want to keep the text that says > >> > lar

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

On Fri, Nov 11, 2016 at 1:54 AM, Tsunakawa, Takayuki < tsunakawa.ta...@jp.fujitsu.com> wrote: > From: pgsql-hackers-ow...@postgresql.org > > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Magnus Hagander > Okay and I think partially it might be bec

Re: [HACKERS] Do we need use more meaningful variables to replace 0 in catalog head files?

On Nov 11, 2016 00:53, "Jan de Visser" wrote: > > On 2016-11-09 10:47 AM, Tom Lane wrote: > >> Amit Langote writes: >>> >>> On Wed, Nov 9, 2016 at 11:47 PM, Tom Lane wrote: Hmm, that's from 2009. I thought I remembered

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

of > predicting > > when the same buffer will be dirtied repeatedly and only needs the final > > version of the data actually written to disk. > > > > Okay and I think partially it might be because we don't have writeback > optimization (done in 9.6) for Windows. However, still the broader > question stands that whether above data is sufficient to say that we > can recommend the settings of shared_buffers on Windows similar to > Linux? > > Based on this optimization we might want to keep the text that says large shared buffers on Windows aren't as effective perhaps, and just remove the sentence that explicitly says don't go over 512MB? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

[HACKERS] Make pg_basebackup -x stream the default

uot; thing by default is a good idea. The new option "-x none" is provided to turn this off and get the previous behavior back. I will add this to the next (January) commitfest. //Magnus -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ diff --gi

Re: [HACKERS] Streaming basebackups vs pg_stat_tmp

On Tue, Nov 8, 2016 at 1:28 PM, David Steele <da...@pgmasters.net> wrote: > Hi Magnus, > > On 11/7/16 2:07 PM, Magnus Hagander wrote: > >> On Sat, Oct 29, 2016 at 4:12 PM, Michael Paquier >> Indeed, giving the attached for REL9_6_STABLE. You could as well have

Re: [HACKERS] Streaming basebackups vs pg_stat_tmp

On Sat, Oct 29, 2016 at 4:12 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Fri, Oct 28, 2016 at 9:57 PM, David Steele <da...@pgmasters.net> wrote: > > On 10/28/16 3:49 PM, Magnus Hagander wrote: > > The change from 10 to 11 increases the tests that are sk

Re: [HACKERS] Streaming basebackups vs pg_stat_tmp

On Fri, Oct 28, 2016 at 2:44 PM, David Steele <da...@pgmasters.net> wrote: > On 10/28/16 11:53 AM, Magnus Hagander wrote: > >> In 9.6 and earlier, if you change pg_stat_tmp to be a symlink, >> basebackups no longer work. That's because we create symlink entry in >&

[HACKERS] Streaming basebackups vs pg_stat_tmp

nging back a (modified) version of the functoin _tarWriteDir() to the back branches. I'd appreciate a look-over before committing, but it works fine in my tests. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ diff --git a/src/backend/replication/basebackup.c b/s

Re: [HACKERS] pg_basebackup stream xlog to tar

On Tue, Oct 25, 2016 at 2:52 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Tue, Oct 25, 2016 at 7:12 PM, Magnus Hagander <mag...@hagander.net> > wrote: > > On Mon, Oct 24, 2016 at 7:46 AM, Michael Paquier < > michael.paqu...@gmail.com> > > wrot

Re: [HACKERS] pg_basebackup stream xlog to tar

On Mon, Oct 24, 2016 at 7:46 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Sun, Oct 23, 2016 at 10:28 PM, Magnus Hagander <mag...@hagander.net> > wrote: > > It also broke the tests and invalidated some documentation. But it was > easy > > enough

Re: [HACKERS] pg_basebackup stream xlog to tar

On Mon, Oct 17, 2016 at 7:37 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Sat, Oct 15, 2016 at 8:51 AM, Magnus Hagander <mag...@hagander.net> > wrote: > > Fixed. > > Ok, I had a extra look on the patch: > + The transactionn log fil

Re: [HACKERS] pg_basebackup stream xlog to tar

he tests and invalidated some documentation. But it was easy enough to fix. I've now applied this, so next time you get to do the merging :P Joking aside, please review and let me know if you can spot something I messed up in the final merge. Thanks for your repeated reviews! -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] Query cancel seems to be broken in master since Oct 17

gt; > My guess is it's related to this: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=9e083fd4683294f41544e6d0d72f6e258ff3a77c That's certainly not intended to break things, but that was changed on Oct 17 and it relates to cancel keys. What platform does the postgres server run on? Ca

Re: [HACKERS] [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran

add this to pg_strong_random: > +1 for that approach. I really wouldn't want to see it fall back completely transparently in case something stops working. But if it's a non-default build option, that's not a problem, and it should make it possible to make it work on older platforms. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] pg_basebackup stream xlog to tar

On Tue, Oct 4, 2016 at 12:05 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > (Squashing two emails into one) > > On Fri, Sep 30, 2016 at 11:16 PM, Magnus Hagander <mag...@hagander.net> > wrote: > > And here's yet another version, now rebased on top of the

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On Fri, Oct 14, 2016 at 11:48 AM, Stephen Frost <sfr...@snowman.net> wrote: > * Magnus Hagander (mag...@hagander.net) wrote: > > On Fri, Oct 14, 2016 at 4:35 AM, Stephen Frost <sfr...@snowman.net> > wrote: > > > * Peter Eisentraut (peter.eisentr...@2ndquadrant.c

Re: [HACKERS] Renaming of pg_xlog and pg_clog

f we are even more clear that people should not be touching those directories in the first place. Those are just the tip of the iceberg. We do use the term xlog in a lot of places (almost as many as wal, but that's a different problem) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] Renaming of pg_xlog and pg_clog

te directory for *technical* reasons. I don't think moving files that are already supposed to be internal into a directory called internal is going to help much, an din particular not for xlog. If we don't rename it, the problem will remain. And for the "don't touch" part, if anythi

Re: [HACKERS] Is it time to kill support for very old servers?

ably change it in head for the future anyway, but that means we have to keep it around in libpq for quite a long while anyway. Unless the special purpose code becomes long and complicated, I think that's the best way to do it. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] WIP: Secure Transport support as OpenSSL alternative on macOS

ird one is probably going to be easier (but not easy). But let's make sure we keep in mind there should be more than just these two implementation when defining any external interfaces. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] Hash tables in dynamic shared memory

On Oct 5, 2016 1:23 AM, "Thomas Munro" wrote: > > On Wed, Oct 5, 2016 at 12:11 PM, Thomas Munro > wrote: > > On Wed, Oct 5, 2016 at 11:22 AM, Andres Freund wrote: > >>> Potential use cases for DHT include caches,

Re: [HACKERS] Is the last 9.1 release planned?

On Oct 5, 2016 5:42 AM, "Tsunakawa, Takayuki" < tsunakawa.ta...@jp.fujitsu.com> wrote: > > From: pgsql-hackers-ow...@postgresql.org > > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Jaime Casanova > > Well, no. We normally don't give special treatment to any minor release > > not even

Re: [HACKERS] pg_basebackup stream xlog to tar

On Thu, Sep 29, 2016 at 12:44 PM, Magnus Hagander <mag...@hagander.net> wrote: > On Mon, Sep 5, 2016 at 10:01 AM, Michael Paquier < > michael.paqu...@gmail.com> wrote: > >> On Sat, Sep 3, 2016 at 10:35 PM, Magnus Hagander <mag...@hagander.net> >> wrote: >

Re: [HACKERS] Small race in pg_xlogdump --follow

On Mon, Sep 26, 2016 at 3:59 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@hagander.net> writes: > > Oh, right, at the very last loop. I've never seen it need more than 1 > loop > > so I didn't manage to hit that codepath :) But yeah,

Re: [HACKERS] pg_basebackup stream xlog to tar

On Mon, Sep 5, 2016 at 10:01 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Sat, Sep 3, 2016 at 10:35 PM, Magnus Hagander <mag...@hagander.net> > wrote: > > Ugh. That would be nice to have, but I think that's outside the scope of > > this patch. > &

Re: [HACKERS] pg_basebackup stream xlog to tar

On Sep 28, 2016 19:11, "Robert Haas" wrote: > > On Mon, Sep 5, 2016 at 4:01 AM, Michael Paquier > wrote: > > [ review comments ] > > This thread has been sitting idle for more than 3 weeks, so I'm > marking it "Returned with Feedback" in the

Re: [HACKERS] Small race in pg_xlogdump --follow

On Mon, Sep 26, 2016 at 3:44 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@hagander.net> writes: > > Attached patch puts a retry loop around opening the file that retries > for 5 > > seconds (which is excessive, but should be safe) in case the

[HACKERS] Small race in pg_xlogdump --follow

(and still fails out for other error messages of course). Comments? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ diff --git a/src/bin/pg_xlogdump/pg_xlogdump.c b/src/bin/pg_xlogdump/pg_xlogdump.c index 02575eb..a0e0a0c 100644 --- a/src/bin/pg_xlogdump

Re: [HACKERS] CF app and patch series

p now ... > Yeah, that would require a bit more surgery. Not sure how to represent it though, if those patches are all typically sent in the same mailthread. Which I guess they are. Because then that thread would have to be attached to all of those sub-entries, which would kind of defeat the purpose? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] ICU integration

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/

Re: [HACKERS] Useless dependency assumption libxml2 -> libxslt in MSVC scripts

On Thu, Sep 8, 2016 at 2:53 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Thu, Sep 8, 2016 at 9:39 PM, Magnus Hagander <mag...@hagander.net> > wrote: > > Pretty sure this goes back to *our* XML support requiring both. As in you > > couldn't turn

Re: [HACKERS] Useless dependency assumption libxml2 -> libxslt in MSVC scripts

ore, and that check has just not been updated. Also 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/

Re: [HACKERS] pg_basebackup stream xlog to tar

On Thu, Sep 1, 2016 at 2:39 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Thu, Sep 1, 2016 at 5:13 PM, Magnus Hagander <mag...@hagander.net> > wrote: > > We don't seem to check for similar issues as the one just found in the > > existing tests though, d

Re: [HACKERS] pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)

On Sat, Sep 3, 2016 at 3:21 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Sat, Sep 3, 2016 at 12:42 AM, Magnus Hagander <mag...@hagander.net> > wrote: > > On Fri, Sep 2, 2016 at 8:50 AM, Michael Paquier < > michael.paqu...@gmail.com> > > wro

Re: [HACKERS] pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)

y, particularly for pg_receivexlog where a crash can cause > 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/

Re: [HACKERS] PostgreSQL 10 kick-off

On Sep 1, 2016 17:44, "Fabrízio de Royes Mello" <fabriziome...@gmail.com> wrote: > > > > On Thu, Sep 1, 2016 at 8:35 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > > > Magnus Hagander <mag...@hagander.net> writes: > > >> On Thu, Aug

Re: [HACKERS] PostgreSQL 10 kick-off

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

Re: [HACKERS] pg_basebackup stream xlog to tar

On Thu, Sep 1, 2016 at 9:43 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Thu, Sep 1, 2016 at 4:41 PM, Magnus Hagander <mag...@hagander.net> > wrote: > > That's definitely not intended - it's supposed to be 16Mb. And it > actually > > writes 16Mb to

Re: [HACKERS] pg_basebackup stream xlog to tar

On Thu, Sep 1, 2016 at 9:19 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Thu, Sep 1, 2016 at 6:58 AM, Magnus Hagander <mag...@hagander.net> > wrote: > > Attached patch adds support for -X stream to work with .tar and .tar.gz > file > > for

[HACKERS] pg_basebackup stream xlog to tar

. 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_basebackup.sgml b/doc/sr

Re: [HACKERS] [PATCH] Send numeric version to clients

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

Re: [HACKERS] Renaming of pg_xlog and pg_clog

en... pg_clog is a different story of course. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] Renaming of pg_xlog and pg_clog

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

Re: [HACKERS] Renaming of pg_xlog and pg_clog

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

Re: [HACKERS] Renaming of pg_xlog and pg_clog

he road. And doing it at the same 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/

Re: [HACKERS] increasing the default WAL segment size

out 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'

Re: [HACKERS] increasing the default WAL segment size

e switch so it's kinda 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/

Re: [HACKERS] increasing the default WAL segment size

we shouldn't change the default. We just need to be a lot more careful about what we change it to if it's ./configure to reset it. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] [RFC] Change the default of update_process_title to off

o > performance problems 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 r

Re: [HACKERS] Anyone want to update our Windows timezone map?

On Thu, Aug 18, 2016 at 3:30 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@hagander.net> writes: > > On Thu, Aug 18, 2016 at 3:26 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> If we got this done in the next couple weeks, any resulting

Re: [HACKERS] Anyone want to update our Windows timezone map?

On Thu, Aug 18, 2016 at 3:34 PM, Magnus Hagander <mag...@hagander.net> wrote: > > > On Thu, Aug 18, 2016 at 3:30 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Magnus Hagander <mag...@hagander.net> writes: >> > On Thu, Aug 18, 2016 at 3:26 PM, Tom Lan

Re: [HACKERS] Anyone want to update our Windows timezone map?

On Thu, Aug 18, 2016 at 3:26 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@hagander.net> writes: > > On Thu, Aug 18, 2016 at 7:06 AM, Michael Paquier < > michael.paqu...@gmail.com> > > wrote: > >> OK, so after re-running that on m

Re: [HACKERS] Anyone want to update our Windows timezone map?

On Thu, Aug 18, 2016 at 7:06 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Tue, Aug 16, 2016 at 6:22 PM, Magnus Hagander <mag...@hagander.net> > wrote: > > I think what we want is basically the UNION ALL of all the different > active > > versions. If

Re: [HACKERS] Use pread and pwrite instead of lseek + write and read

On Wed, Aug 17, 2016 at 12:41 PM, Dagfinn Ilmari Mannsåker < ilm...@ilmari.org> wrote: > Magnus Hagander <mag...@hagander.net> writes: > > [pread/pwrite] > > > Yeah, Windows does not have those API calls, but it shouldn't be rocket > > science to write a wrapp

Re: [HACKERS] Use pread and pwrite instead of lseek + write and read

so be interesting as a future improvement. That's clearly something different though, and out of scope for this one. But IIRC that functionality was actually added for the sake of SQLServer back in the days. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] [RFC] Change the default of update_process_title to off

On Tue, Aug 16, 2016 at 3:37 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Tue, Aug 16, 2016 at 5:53 AM, Magnus Hagander <mag...@hagander.net> > wrote: > >> What's our take on backpatching such changes?

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

On Tue, Aug 16, 2016 at 5:24 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@hagander.net> writes: > > On Aug 16, 2016 5:11 PM, "Tom Lane" <t...@sss.pgh.pa.us> wrote: > >> Dunno, it was still working the last time I us

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

On Aug 16, 2016 5:11 PM, "Tom Lane" <t...@sss.pgh.pa.us> wrote: > > Magnus Hagander <mag...@hagander.net> writes: > > On Aug 16, 2016 4:43 PM, "Tom Lane" <t...@sss.pgh.pa.us> wrote: > >> Rather, the problem arises when J. Ordinary User d

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

On Aug 16, 2016 4:43 PM, "Tom Lane" wrote: > > Peter Eisentraut writes: > > On 8/16/16 8:53 AM, Greg Stark wrote: > >> That's a system level change though. How would a normal user manage this? > > > Arguably, if you are a normal user, you

Re: [HACKERS] [RFC] Change the default of update_process_title to off

way at the time either. And back then, I guess there were just enough *other* things that were slow with pg-on-windows that it didn't become as obvious. So - +1 for changing the defaults as suggested. What's our take on backpatching such changes? Should this be 9.6 only, or back further? -- Ma

Re: [HACKERS] Anyone want to update our Windows timezone map?

at we want is basically the UNION ALL of all the different active versions. If we just use the definitions from Win10, we will map incorrectly on Win7. As long as they are not *conflicting*, we should just add them all. The UTC->GMT switch is mostly just annoying as it only hits the comments, right? I think we just accept that change and do a once-over patch that changes all those things. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] sslmode=require fallback

On Tue, Jul 19, 2016 at 10:57 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 7/19/16 3:32 PM, Magnus Hagander wrote: > > There are definitely cases where it's useful. I'm only arguing for > > changing the default. > > I don't understand why you

Re: [HACKERS] sslmode=require fallback

On Tue, Jul 19, 2016 at 9:24 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 7/19/16 10:00 AM, Magnus Hagander wrote: > > What could actually be useful there is to explicitly put hostnossl on > > the localhost entries. With the current de

Re: [HACKERS] sslmode=require fallback

cate these changes being made upstream in PostgreSQL iteslf. //Magnus > > Am 19. Juli 2016 16:00:05 MESZ, schrieb Magnus Hagander < > mag...@hagander.net>: >> >> >> >> On Sun, Jul 17, 2016 at 10:07 PM, Christoph Berg <m...@debian.org> wrote: >&

Re: [HACKERS] Updating our timezone code in the back branches

se to try to get 2016e into 9.6 ASAP, so we can get it into the next beta/rc (not the one on it's way now, but the one after that). -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] sslmode=require fallback

ults on the clients, that wouldn't break anything, and it would leave people without the performance issues that you run into in the default deployments. And for localhost it really does't make sense to encrypt -- for the local LAN segment that can be argued, but for localhost... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] Typos in logical decoding

wait for someone more familiar with that code to comment though :) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] pg_xlogdump follow into the future

On Thu, Jul 14, 2016 at 8:27 PM, Andres Freund <and...@anarazel.de> wrote: > On 2016-07-14 13:46:23 +0200, Magnus Hagander wrote: > > Currently, if you run pg_xlogdump with -f, you have to specify an end > > position in an existing file, or if you don't it will only follo

Re: [HACKERS] sslmode=require fallback

On Fri, Jul 15, 2016 at 5:10 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 7/13/16 4:11 PM, Robert Haas wrote: > > On Thu, Jun 16, 2016 at 3:42 AM, Magnus Hagander <mag...@hagander.net> > wrote: > >> You would think so. > >> >

Re: [HACKERS] sslmode=require fallback

t off (since it's on by default on debian/ubuntu) has fixed a customers entire performance issue and I could go back home again... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] pg_xlogdump bad error msg?

On Mon, Jul 11, 2016 at 5:20 PM, Andres Freund <and...@anarazel.de> wrote: > On 2016-07-11 13:36:37 +0200, Magnus Hagander wrote: > > When you don't specify a start segment to pg_xlogdump, you get: > > > > pg_xlogdump: no start log position given in range mode. >

[HACKERS] pg_xlogdump follow into the future

fy -f without an end pointer. I'd appreciate a review of that by someone who's done more work on the xlog stuff, but it seems trivial to me. Not sure I can argue it's a bugfix though, since the usecase simply did not work... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redp

Re: [HACKERS] remove checkpoint_warning

nings that tells them that they have to do this. And the argument about it getting lost amongst other log traffic to me is an argument for not turning on log_checkpoints by default. That generates a lot of log entries that most people don't care for, and in doing so hides other things in the log. It's excellent to have it once you need it, but it shouldn't be turned on by default. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] sslmode=require fallback

On Thu, Jun 23, 2016 at 1:50 AM, Bruce Momjian <br...@momjian.us> wrote: > On Thu, Jun 16, 2016 at 10:42:56AM +0200, Magnus Hagander wrote: > > However, if this is the expected behavior, the documentation > at https:// > > www.postgresql.org/docs/current/stat

Re: [HACKERS] [BUGS] BUG #14230: Wrong timeline returned by pg_stop_backup on a standby

On Mon, Jul 11, 2016 at 3:05 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Mon, Jul 11, 2016 at 7:01 PM, Magnus Hagander <mag...@hagander.net> > wrote: > > But isn't this also a pre-existing bug in 9.5? Or did we change something > > else that suddenly

[HACKERS] pg_xlogdump bad error msg?

When you don't specify a start segment to pg_xlogdump, you get: pg_xlogdump: no start log position given in range mode. What is "range mode", and is there any other mode for pg_xlogdump? Should it not just be "no start log position or segment given" or something like that?

Re: [HACKERS] [BUGS] BUG #14230: Wrong timeline returned by pg_stop_backup on a standby

ng the backup_label file. In > short, +1 for this fix. > > I am adding that in the list of open items, adding Magnus in CC whose > commit for non-exclusive backups is at the origin of this defect. > I agree this looks correct. But isn't this also a pre-existing bug in 9.5? Or did we c

Re: [HACKERS] [BUGS] BUG #14230: Wrong timeline returned by pg_stop_backup on a standby

On Jul 9, 2016 4:52 AM, "Noah Misch" wrote: > > On Thu, Jul 07, 2016 at 03:38:26PM +0900, Michael Paquier wrote: > > On Thu, Jul 7, 2016 at 12:57 AM, Marco Nenciarini > > wrote: > > > After further analysis, the issue is that we retrieve the

Re: [HACKERS] Showing parallel status in \df+

ally sane already use it with > the expanded display mode, and it may not matter adding more > information. > Thoughts about adding this piece of information? > > Seems like a good idea to me. It's going to be useful in debugging -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] Don't include MMAP DSM's transient files in basebackup

of-date comment in dsm.c. > > No arguments against the change. But I am wondering how you ran into > this - the mmap dsm backend really should pretty much never be used... > > Unfortunately I think that's still what happens by default if you use pg_upgradecluster on debian :( //M

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

d > 3) Disable the use of SCRAM when OpenSSL is not present in the build. > > Opinions? My heart goes for 2) because 1) is ugly, and 3) is not > appealing in terms of flexibility. > > I really dislike #3 - we want everybody to start using this... I'm not sure how common a build

[HACKERS] Re: [ADMIN] problems using pg_start_backup/pg_stop_backup and pg_basebackup at same time

; On Mon, Jun 20, 2016 at 10:15 AM, Alex Malek <magicag...@gmail.com> wrote: > >> >> Thanks for the response Magnus. >> I've replied inline below. >> >> On Mon, Jun 20, 2016 at 4:17 AM, Magnus Hagander <mag...@hagander.net> >> wrote: >> >>> On M

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On Fri, Jul 1, 2016 at 10:10 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Fri, Jul 1, 2016 at 5:02 PM, Magnus Hagander <mag...@hagander.net> > wrote: > > Debian testing is still on 1.0.2h. > > Debian experimental is on 1.1.0pre5. > > > >

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

here is no other way... Is Debian up to > date with 1.1.0 beta2 in its snapshot packages? > Debian testing is still on 1.0.2h. Debian experimental is on 1.1.0pre5. Not sure here beta2 enters the discussion, it's not mentioned anywhere on their site? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

and the recovery parameters are handled in a single structure, > which is the return result of the call. To reduce a bit the cruft in > xlog.c that would be nice anyway I guess. > There was also that (old) thread about making the recovery.conf parameters be general GUCs. I don't actually

Re: [HACKERS] pg_upgrade vs vacuum_cost_delay

On Thu, Jun 16, 2016 at 4:35 PM, Euler Taveira <eu...@timbira.com.br> wrote: > On 16-06-2016 09:05, Magnus Hagander wrote: > > Shouldn't pg_upgrade turn off vacuum cost delay when it vacuums the new > > cluster? Not talking about the post-analyze script, but when it runs &g

[HACKERS] pg_upgrade vs vacuum_cost_delay

as fast as possible. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

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