Re: [HACKERS] "left shift of negative value" warnings
On 10/04/17 22:19, Andres Freund wrote: > I guess the motivation is that it's not entirely clear what happens with > the sign bit, when shifting. Indeed, certain one's complement CPUs even "outlived" C99 by a small margin, as it were: http://mainframe.typepad.com/blog/2012/10/sad-day-unisys-abandons-its-mainframe-processors.html And the respective ABI will be around for some time to come, apparently: https://www.theregister.co.uk/2016/03/31/free_x86_mainframes_for_all_virtual_mainframes_that_is :-) -- Markus Nullmeierhttp://www.g-vo.org German Astrophysical Virtual Observatory (GAVO) -- 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] WIP: Faster Expression Processing and Tuple Deforming (including JIT)
On 12/06/16 21:40, Andres Freund wrote: > On 2016-12-06 14:35:43 -0600, Nico Williams wrote: >> On Tue, Dec 06, 2016 at 12:27:51PM -0800, Andres Freund wrote: >>> On 2016-12-06 14:19:21 -0600, Nico Williams wrote: >>>>> I concur with your feeling that hand-rolled JIT is right out. But >>>> >>>> Yeah, that way lies maintenance madness. >>> >>> I'm not quite that sure about that. I had a lot of fun doing some >>> hand-rolled x86 JITing. Not that is a ward against me being mad. But >>> more seriously: Manually doing a JIT gives you a lot faster compilation >>> times, which makes JIT applicable in a lot more situations. >> >> What I meant is that each time there are new ISA extensions, or >> differences in how relevant/significant different implementations of the >> same ISA implement certain instructions, and/or every time you want to >> add a new architecture... someone has to do a lot of very low-level >> work. > > Yea, that's why I didn't pursue this path further. I *personally* think > it'd be perfectly fine to only support JITing on linux x86_64 and > aarch64 for now. And those I'd be willing to work on. But since I know > that's not project policy... Well, if this thread of thought about hand-crafted JIT should be taken up again by someone at some point in time, I guess it could be possible to reuse tools that are already out there, such as "DynASM" ( http://luajit.org/dynasm_features.html ) from the LuaJIT project (currently offers x86-64, x86-32, ARM-32, PPC-32, and MIPS-32). Maybe one could even recycle parts of the LuaJIT project itself ( http://luajit.org/luajit.html , http://article.gmane.org/gmane.comp.lang.lua.general/58908 ). -- Markus Nullmeierhttp://www.g-vo.org German Astrophysical Virtual Observatory (GAVO) -- 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] Incorrect overflow check condition for WAL segment size
On 11/08/16 18:12, Robert Haas wrote: > On Tue, Nov 8, 2016 at 1:01 AM, Michael Paquier <michael.paqu...@gmail.com> > wrote: >> On Tue, Nov 8, 2016 at 2:33 PM, Kuntal Ghosh <kuntalghosh.2...@gmail.com> >> wrote: >>> I've attached a patch to fix this. >> Good catch. Interesting copy-pasto from 88e9823. > Committed. Hmm, somehow this fix (60379f66c8 for master) does not seem to appear in the 9.5 and 9.6 branches, yet the latter both include commit 88e9823. -- Markus Nullmeierhttp://www.g-vo.org German Astrophysical Virtual Observatory (GAVO) -- 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] WIP: Access method extendability
On 03/31/16 17:29, Alexander Korotkov wrote: > New revision of patches is attached. > 1) API of generic xlog was changed: now there is no static variables, >GenericXLogStart() returns palloc'd struct. Attached are two trivial documentation editing fixes for this, as an incremental patch. -- Markus Nullmeierhttp://www.g-vo.org German Astrophysical Virtual Observatory (GAVO) diff --git a/doc/src/sgml/generic-wal.sgml b/doc/src/sgml/generic-wal.sgml index 6655f22..b3388ba 100644 --- a/doc/src/sgml/generic-wal.sgml +++ b/doc/src/sgml/generic-wal.sgml @@ -43,7 +43,7 @@ - GenericXLogAbort(state) finish construction of + GenericXLogFinish(state) finish construction of a generic xlog record. @@ -52,7 +52,7 @@ The xlog record construction can be canceled between any of the above - steps by calling GenericXLogAbort(). This will discard all + steps by calling GenericXLogAbort(state). This will discard all changes to the page image copies. -- 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] WIP: Access method extendability
Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> wrote:
> I heard no objections. There is revision of patch where generic WAL
> interface description was moved to documentation. This description
> contains improvements by Petr Jelinek, Alvaro Herrera and Markus Nullmeier
Attached are a few more small fixes as an incremental patch (typos / etc.).
--
Markus Nullmeierhttp://www.g-vo.org
German Astrophysical Virtual Observatory (GAVO)
diff --git a/doc/src/sgml/generic-wal.sgml b/doc/src/sgml/generic-wal.sgml
index a00c03c..d756e33 100644
--- a/doc/src/sgml/generic-wal.sgml
+++ b/doc/src/sgml/generic-wal.sgml
@@ -4,15 +4,15 @@
Generic WAL records
- Despite all built in access methods and WAL-logged modules have their own
- types of WAL records, there is also generic WAL record type which describes
+ Despite all built-in access methods and WAL-logged modules having their own
+ types of WAL records, there is also a generic WAL record type, which describes
changes to pages in a generic way. This is useful for extensions that
provide custom access methods, because they cannot register their own
WAL redo routines.
- API for contructing generic WAL records is defined in
+ The API for contructing generic WAL records is defined in
generic_xlog.h and implemented in generic_xlog.c.
Each generic WAL record must be constructed by following these steps:
diff --git a/src/backend/access/transam/generic_xlog.c b/src/backend/access/transam/generic_xlog.c
index 32c2648..1a720fa 100644
--- a/src/backend/access/transam/generic_xlog.c
+++ b/src/backend/access/transam/generic_xlog.c
@@ -19,7 +19,7 @@
#include "utils/memutils.h"
/*-
- * Internally, a delta between pages consists of set of fragments. Each
+ * Internally, a delta between pages consists of a set of fragments. Each
* fragment represents changes made in a given region of a page. A fragment
* is made up as follows:
*
@@ -29,7 +29,7 @@
*
* Unchanged regions of a page are not represented in its delta. As a
* result, a delta can be more compact than the full page image. But having
- * an unchanged region in the middle to two fragments that is smaller than
+ * an unchanged region in the middle of two fragments that is smaller than
* the fragment header (offset and length) does not pay off in terms of the
* overall size of the delta. For this reason, we break fragments only if
* the unchanged region is bigger than MATCH_THRESHOLD.
@@ -422,7 +422,7 @@ generic_redo(XLogReaderState *record)
Assert(record->max_block_id < MAX_GENERIC_XLOG_PAGES);
- /* Interate over blocks */
+ /* Iterate over blocks */
for (block_id = 0; block_id <= record->max_block_id; block_id++)
{
XLogRedoAction action;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
