pgsql: Allow committing inside cursor loop

Allow committing inside cursor loop Previously, committing or aborting inside a cursor loop was prohibited because that would close and remove the cursor. To allow that, automatically convert such cursors to holdable cursors so they survive commits or rollbacks. Portals now have a new state

Re: pgsql: Optimize btree insertions for common case of increasing values

On Wed, Mar 28, 2018 at 11:56 AM, Peter Geoghegan wrote: >> Previously, we agreed that P_IGNORE() is required. So I assume no issues >> there. The other tests seem required too for us to conclusively decide to >> use the cached block. > > Actually, you're right that

Re: pgsql: Add documentation for the JIT feature.

On 28 March 2018 at 22:23, Andres Freund wrote: > Add documentation for the JIT feature. Very nice feature and most welcome but we should call it something other than just "JIT" JIT means Just In Time, which could be applied to many concepts and has been in use for many

pgsql: C comment: fix typo, log -> lag

C comment: fix typo, log -> lag Reported-by: atorikoshi Discussion: https://postgr.es/m/b61f2ab9-c0e0-d33d-ce3f-42a228025...@lab.ntt.co.jp Author: atorikoshi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a2894cce544d120199a1a90469073796d055bb60 Modified

pgsql: Fix mistakes in the just added JIT docs.

Fix mistakes in the just added JIT docs. Reported-By: Lukas Fittl Author: Andres Freund Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a0a08c1d85dae3c332e7d72a56df0636be9c5d0a Modified Files -- doc/src/sgml/config.sgml | 2 +- doc/src/sgml/jit.sgml

pgsql: Add documentation for the JIT feature.

Add documentation for the JIT feature. As promised in earlier commits, this adds documentation about the new build options, the new GUCs, about the planner logic when JIT is used, and the benefits of JIT in general. Also adds a more implementation oriented README. I'm sure we're going to want

pgsql: Add EXPLAIN support for JIT.

Add EXPLAIN support for JIT. This just shows a few details about JITing, e.g. how many functions have been JITed, and how long that took. To avoid noise in regression tests with functions sometimes being JITed in --with-llvm builds, disable display when COSTS OFF is specified. Author: Andres

pgsql: Use isinf builtin for clang, for performance.

Use isinf builtin for clang, for performance. When compiling with clang glibc's definition of isinf() ends up leading to and external libc function call. That's because there was a bug in the builtin in an old gcc version, and clang claims compatibility with an older version. That causes clang

pgsql: Fix handling of files that source server removes during pg_rewin

Fix handling of files that source server removes during pg_rewind is running. After processing the filemap to build the list of chunks that will be fetched from the source to rewing the target server, it is possible that a file which was previously processed is removed from the source. A simple

pgsql: Fix handling of files that source server removes during pg_rewin

Fix handling of files that source server removes during pg_rewind is running. After processing the filemap to build the list of chunks that will be fetched from the source to rewing the target server, it is possible that a file which was previously processed is removed from the source. A simple

pgsql: Fix handling of files that source server removes during pg_rewin

Fix handling of files that source server removes during pg_rewind is running. After processing the filemap to build the list of chunks that will be fetched from the source to rewing the target server, it is possible that a file which was previously processed is removed from the source. A simple

pgsql: Fix handling of files that source server removes during pg_rewin

Fix handling of files that source server removes during pg_rewind is running. After processing the filemap to build the list of chunks that will be fetched from the source to rewing the target server, it is possible that a file which was previously processed is removed from the source. A simple

Re: pgsql: Optimize btree insertions for common case of increasing values

On Wed, Mar 28, 2018 at 2:14 AM, Pavan Deolasee wrote: >> This code can allocate memory in a critical section, since >> RelationSetTargetBlock() can call smgropen(): > I think you're right. I propose that we call RelationSetTargetBlock right > after the critical section

pgsql: PL/pgSQL: Nested CALL with transactions

PL/pgSQL: Nested CALL with transactions So far, a nested CALL or DO in PL/pgSQL would not establish a context where transaction control statements were allowed. This fixes that by handling CALL and DO specially in PL/pgSQL, passing the atomic/nonatomic execution context through and doing the

pgsql: Fix actual and potential double-frees around tuplesort usage.

Fix actual and potential double-frees around tuplesort usage. tuplesort_gettupleslot() passed back tuples allocated in the tuplesort's own memory context, even when the caller was responsible to free them. This created a double-free hazard, because some callers might destroy the tuplesort object

pgsql: Fix actual and potential double-frees around tuplesort usage.

Fix actual and potential double-frees around tuplesort usage. tuplesort_gettupleslot() passed back tuples allocated in the tuplesort's own memory context, even when the caller was responsible to free them. This created a double-free hazard, because some callers might destroy the tuplesort object

pgsql: Fix actual and potential double-frees around tuplesort usage.

Fix actual and potential double-frees around tuplesort usage. tuplesort_gettupleslot() passed back tuples allocated in the tuplesort's own memory context, even when the caller was responsible to free them. This created a double-free hazard, because some callers might destroy the tuplesort object

pgsql: Store 2PC GID in commit/abort WAL recs for logical decoding

Store 2PC GID in commit/abort WAL recs for logical decoding Store GID of 2PC in commit/abort WAL records when wal_level = logical. This allows logical decoding to send the SAME gid to subscribers across restarts of logical replication. Track relica origin replay progress for 2PC. (Edited from

pgsql: Attempt to fix jsonb_plpython build on Windows

Attempt to fix jsonb_plpython build on Windows Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/75e95dd79ba22e18687a069d2ff2fd29afab5798 Modified Files -- src/tools/msvc/Install.pm | 1 + src/tools/msvc/Mkvcbuild.pm | 40

pgsql: Fix jsonb_plpython tests on older Python versions

Fix jsonb_plpython tests on older Python versions Rewrite one test to avoid a case where some Python versions have output format differences (Decimal('1') vs Decimal("1")). Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e81fc9b9dbf9d744dcc9fb210e4353a350be1e22

Re: pgsql: Transforms for jsonb to PL/Python

On 3/28/18 08:39, Peter Eisentraut wrote: > Transforms for jsonb to PL/Python Needs fixes for Windows build. I can give it a blind attempt, but help would be welcome. I'm looking into the regression test failures that appear to be minor output differences. -- Peter Eisentraut

pgsql: Transforms for jsonb to PL/Python

Transforms for jsonb to PL/Python Add a new contrib module jsonb_plpython that provide a transform between jsonb and PL/Python. jsonb values are converted to appropriate Python types such as dicts and lists, and vice versa. Author: Anthony Bykov Reviewed-by: Aleksander

Re: pgsql: Fast ALTER TABLE ADD COLUMN with a non-NULL default

(2018/03/28 13:25), Tom Lane wrote: Andres Freund writes: There's also a few of that annoying postgres_fdw thing. Some of my critters hit that regularly :(. We need to figure out what's going on there. I plan to work on this after the commitfest. Yeah, really. I've

Re: pgsql: Allow HOT updates for some expression indexes

On 28.03.2018 07:23, Simon Riggs wrote: On 27 March 2018 at 22:26, Tom Lane wrote: I wrote: The test script appears to imagine that pgstats outputs update instantaneously. Oh, wait, it's looking at pg_stat_xact, which is the *local*, unsent stats information. So your

pgsql: Make fast_default regression tests locale independent

Make fast_default regression tests locale independent Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a437551a228a5099c305d1376188d6926c043724 Modified Files -- src/test/regress/expected/fast_default.out | 2 +- src/test/regress/sql/fast_default.sql

Re: pgsql: Fast ALTER TABLE ADD COLUMN with a non-NULL default

On 2018-03-27 23:40:25 -0400, Tom Lane wrote: > Andres Freund writes: > > Note there appear to be some independent failures? > > It looks to me like the hard failures from this patch are all on your JIT > critters. There are a bunch of random failures from Simon's commit, >

Re: pgsql: Fast ALTER TABLE ADD COLUMN with a non-NULL default

On Wed, Mar 28, 2018 at 3:18 PM, Tom Lane wrote: > Andres Freund writes: >> The one I noticed was: >> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=treepie=2018-03-28%2002%3A43%3A00 >> ... >> which probably is just collation related and will

Re: pgsql: Optimize btree insertions for common case of increasing values

On Mon, Mar 26, 2018 at 5:10 AM, Andrew Dunstan wrote: > Optimize btree insertions for common case of increasing values > > Remember the last page of an index insert if it's the rightmost leaf > page. If the next entry belongs on and can fit in the remembered page, > insert