Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation
On Mon, Feb 10, 2014 at 10:02 AM, Amit Kapila amit.kapil...@gmail.com wrote: I think if we want to change LZ format, it will be bit more work and verification for decoding has to be done much more strenuously. I don't think it'll be that big of a deal. And anyway, the evidence here suggests that we still need more speed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] narwhal and PGDLLIMPORT
On 13/02/2014 00:17, Craig Ringer wrote: On 02/13/2014 12:39 AM, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2014-02-12 11:26:56 -0500, Tom Lane wrote: Hm. So if we're giving up on the idea of ever getting rid of PGDLLIMPORT, we ought to actually remove that, so that the Cygwin build works more like the other Windows builds? Hm, I don't see a big advantage in detecting the errors as It won't hugely increase the buildfarm coverage. But --auto-import seems to require marking the .text sections as writable, avoiding that seems to be a good idea if we don't need it anymore. Given the rather small number of Windows machines in the buildfarm, I'd really like them all to be on the same page about what's valid and what isn't. Having to wait ~24 hours to find out if they're all happy with something isn't my idea of a good time. In any case, as long as we have discrepancies between them, I'm not going to be entirely convinced that any of them are telling the full truth. I'm going to go remove that switch and see if brolga starts failing. If it does, I'll be satisfied that we understand the issues here. I wouldn't assume that _anything_ Cygwin does makes sense, or is consistent with anything else. Of course, I disagree ;-) Its attempts to produce UNIX-like behaviour on Windows cause some truly bizarre behaviour at times. unfortunately our baseground (Windows) is limiting us. It is not totally unfair to compare the level of weirdness of Cygwin to that of WINE, though they operate in completely different ways. I wouldn't suggest making any conclusions about the _other_ platforms based on Cygwin. My personal experience is that a UNIX-vanilla source build 99% right on recent cygwin. The problem with postgreql make/build system is that it tries to guess platform behavior and that is not fix in time. Porting a new platform to postgresql from scratch will be a very hard effort Automake/Autoconf makes it much more simple; as its aim is to test features not platforms. Cmake also makes it right, now. We teach it that cygwin is a unix platform not a win32 platform I am biased, of course. Marco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUG] Archive recovery failure on 9.3+.
Hello, I need PostgreSQL9.3 which fixed this problem. It didn't happen in PostgreSQL9.2, so I agree with your proposal which changes are done against 93_STABLE and master. Can you fix this in next release(9.3.3)? I was going to push to move this a bit, but... Wouldn't it be better to not archive the old segment, and instead switch to a new segment after writing the end-of-recovery checkpoint, so that the segment on the new timeline is archived sooner? It would be better to zero-fill and switch segments, yes. We should NEVER be in a position of archiving two different versions of the same segment. Ok, I think we're in agreement that that's the way to go for master. I've almost inclined to that but on some thoughts on the idea, comming to think of recovery upto target timeline, the old segment found to be necessary for the case. Without the old segment, we would be obliged to seek to the first segment of the *next* timeline (Is there any (simple) means to predict where is it?) to complete the task. Is it the right way we kick the older one out of archive? Now, what to do about back-branches? On one hand, I'd like to apply the same fix to all stable branches, as the current behavior is silly and always has been. On the other hand, we haven't heard any complaints about it, so we probably shouldn't fix what ain't broken. Perhaps we should apply it to 9.3, as that's where we have the acute problem the OP reported. Thoughts? In summary, I propose that we change master and REL9_3_STABLE to not archive the partial segment from previous timeline. Older branches will keep the current behavior. -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] narwhal and PGDLLIMPORT
(2014/02/13 8:21), Tom Lane wrote: Craig Ringer cr...@2ndquadrant.com writes: On 02/12/2014 02:31 PM, Inoue, Hiroshi wrote: Maybe this is one of the few use cases of dlltool. Because python doesn't ship with its MINGW import library, the Makefile uses dlltool to generate an import library from the python DLL. Wow. Has anyone been in touch with the Python package maintainers to see if they can fix that and bundle the .lib ? Indeed somebody should pester them about that, but it's not clear how much it'd help us even if they fixed it tomorrow. We're going to have to be able to build with existing Python distributions for a long time to come. Though the comment in src/pl/plpython/Makefile refers to it, I see libpython27.a in Python27. I can't find it in Python25. regards, Hiroshi Inoue -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] narwhal and PGDLLIMPORT
On 02/13/2014 02:42 PM, Marco Atzeri wrote: My personal experience is that a UNIX-vanilla source build 99% right on recent cygwin. Yeah, I freely admit my experience with _recent_ cygwin is not abundant. Things may well have improved. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
