Re: pgsql: Move strtoint() to common

On 14 March 2018 at 08:10, Tom Lane wrote: > Peter Eisentraut writes: >> Move strtoint() to common > > Buildfarm seems to think this isn't quite baked for Windows. Yeah, "restrict" seems to be C99, and the Microsoft compilers don't quite know about that yet.

pgsql: Add Oracle like handling of char arrays.

Add Oracle like handling of char arrays. In some cases Oracle Pro*C handles char array differently than ECPG. This patch adds a Oracle compatibility mode to make ECPG behave like Pro*C. Patch by David Rader Branch -- master Details ---

pgsql: Fix double frees in ecpg.

Fix double frees in ecpg. Patch by Patrick Krecker Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8e3f3ab5b85a230e9a008c743402c3e5a43085a1 Modified Files -- src/interfaces/ecpg/preproc/ecpg.c | 5 - 1 file changed, 4

pgsql: Fix double frees in ecpg.

Fix double frees in ecpg. Patch by Patrick Krecker Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/09f4ca92bbe5a68b228d6a3251e4d2be31bb6377 Modified Files -- src/interfaces/ecpg/preproc/ecpg.c | 5 - 1 file changed, 4

pgsql: Fix double frees in ecpg.

Fix double frees in ecpg. Patch by Patrick Krecker Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/db2fc801f66a70969cbdd5673ed9d02025c70695 Modified Files -- src/interfaces/ecpg/preproc/ecpg.c | 5 - 1 file changed, 4

pgsql: Fix double frees in ecpg.

Fix double frees in ecpg. Patch by Patrick Krecker Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fcc15bf38100edf26b38c73a809579fc0e9ccc78 Modified Files -- src/interfaces/ecpg/preproc/ecpg.c | 5 - 1 file changed, 4

pgsql: Fix double frees in ecpg.

Fix double frees in ecpg. Patch by Patrick Krecker Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/837d4f739ccf16091d41649a9d22d7e911636a3b Modified Files -- src/interfaces/ecpg/preproc/ecpg.c | 5 - 1 file changed, 4

pgsql: Fix double frees in ecpg.

Fix double frees in ecpg. Patch by Patrick Krecker Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8559b40c5e3fb068d0dfd81d4a5a9f7411f2cbba Modified Files -- src/interfaces/ecpg/preproc/ecpg.c | 5 - 1 file changed, 4

pgsql: Add COSTS off to two EXPLAIN using tests.

Add COSTS off to two EXPLAIN using tests. Discussion: https://postgr.es/m/2018031023.i4sgkbl4oqtst...@alap3.anarazel.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4f63e85eb149792492a703f01a3a5b89bf5509a7 Modified Files --

pgsql: Expand AND/OR regression tests around NULL handling.

Expand AND/OR regression tests around NULL handling. Previously there were no tests verifying that NULL handling in AND/OR was correct (i.e. that NULL rather than false is returned if expression doesn't return true). Author: Andres Freund Branch -- master Details ---

pgsql: Let Parallel Append over simple UNION ALL have partial subpaths.

Let Parallel Append over simple UNION ALL have partial subpaths. A simple UNION ALL gets flattened into an appendrel of subquery RTEs, but up until now it's been impossible for the appendrel to use the partial paths for the subqueries, so we can implement the appendrel as a Parallel Append but

Re: pgsql: Move strtoint() to common

Peter Eisentraut writes: > Move strtoint() to common Buildfarm seems to think this isn't quite baked for Windows. regards, tom lane

pgsql: When updating reltuples after ANALYZE, just extrapolate from our

When updating reltuples after ANALYZE, just extrapolate from our sample. The existing logic for updating pg_class.reltuples trusted the sampling results only for the pages ANALYZE actually visited, preferring to believe the previous tuple density estimate for all the unvisited pages. While

pgsql: When updating reltuples after ANALYZE, just extrapolate from our

When updating reltuples after ANALYZE, just extrapolate from our sample. The existing logic for updating pg_class.reltuples trusted the sampling results only for the pages ANALYZE actually visited, preferring to believe the previous tuple density estimate for all the unvisited pages. While

pgsql: When updating reltuples after ANALYZE, just extrapolate from our

When updating reltuples after ANALYZE, just extrapolate from our sample. The existing logic for updating pg_class.reltuples trusted the sampling results only for the pages ANALYZE actually visited, preferring to believe the previous tuple density estimate for all the unvisited pages. While

pgsql: When updating reltuples after ANALYZE, just extrapolate from our

When updating reltuples after ANALYZE, just extrapolate from our sample. The existing logic for updating pg_class.reltuples trusted the sampling results only for the pages ANALYZE actually visited, preferring to believe the previous tuple density estimate for all the unvisited pages. While

pgsql: When updating reltuples after ANALYZE, just extrapolate from our

When updating reltuples after ANALYZE, just extrapolate from our sample. The existing logic for updating pg_class.reltuples trusted the sampling results only for the pages ANALYZE actually visited, preferring to believe the previous tuple density estimate for all the unvisited pages. While

pgsql: When updating reltuples after ANALYZE, just extrapolate from our

When updating reltuples after ANALYZE, just extrapolate from our sample. The existing logic for updating pg_class.reltuples trusted the sampling results only for the pages ANALYZE actually visited, preferring to believe the previous tuple density estimate for all the unvisited pages. While

pgsql: Avoid holding AutovacuumScheduleLock while rechecking table stat

Avoid holding AutovacuumScheduleLock while rechecking table statistics. In databases with many tables, re-fetching the statistics takes some time, so that this behavior seriously decreases the available concurrency for multiple autovac workers. There's discussion afoot about more complete fixes,

pgsql: Avoid holding AutovacuumScheduleLock while rechecking table stat

Avoid holding AutovacuumScheduleLock while rechecking table statistics. In databases with many tables, re-fetching the statistics takes some time, so that this behavior seriously decreases the available concurrency for multiple autovac workers. There's discussion afoot about more complete fixes,

pgsql: Avoid holding AutovacuumScheduleLock while rechecking table stat

Avoid holding AutovacuumScheduleLock while rechecking table statistics. In databases with many tables, re-fetching the statistics takes some time, so that this behavior seriously decreases the available concurrency for multiple autovac workers. There's discussion afoot about more complete fixes,

pgsql: Avoid holding AutovacuumScheduleLock while rechecking table stat

Avoid holding AutovacuumScheduleLock while rechecking table statistics. In databases with many tables, re-fetching the statistics takes some time, so that this behavior seriously decreases the available concurrency for multiple autovac workers. There's discussion afoot about more complete fixes,

pgsql: Avoid holding AutovacuumScheduleLock while rechecking table stat

Avoid holding AutovacuumScheduleLock while rechecking table statistics. In databases with many tables, re-fetching the statistics takes some time, so that this behavior seriously decreases the available concurrency for multiple autovac workers. There's discussion afoot about more complete fixes,

pgsql: Set connection back to NULL after freeing it.

Set connection back to NULL after freeing it. Patch by Jeevan Ladhe Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fe65f5931942e6aa7ff0f185cd777eb8d635e3ae Modified Files -- src/interfaces/ecpg/preproc/output.c |

pgsql: Set connection back to NULL after freeing it.

Set connection back to NULL after freeing it. Patch by Jeevan Ladhe Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b32fad52e94307261471d05a79c70f8382d71657 Modified Files -- src/interfaces/ecpg/preproc/output.c | 3 +++

pgsql: Set connection back to NULL after freeing it.

Set connection back to NULL after freeing it. Patch by Jeevan Ladhe Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bd7eb6fe65b34963135851f06210d8e5fe048ef4 Modified Files -- src/interfaces/ecpg/preproc/output.c |

pgsql: Set connection back to NULL after freeing it.

Set connection back to NULL after freeing it. Patch by Jeevan Ladhe Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/44a36a8d9a6e7ba209253d694dd2ebf3e13f0b5d Modified Files -- src/interfaces/ecpg/preproc/output.c |

pgsql: Set connection back to NULL after freeing it.

Set connection back to NULL after freeing it. Patch by Jeevan Ladhe Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/042badc3778ade0f430049eb7dac03972e544e5a Modified Files -- src/interfaces/ecpg/preproc/output.c |

pgsql: Set connection back to NULL after freeing it.

Set connection back to NULL after freeing it. Patch by Jeevan Ladhe Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/95f0260218ba5882828c245710964c828da6fb26 Modified Files -- src/interfaces/ecpg/preproc/output.c |

pgsql: Move strtoint() to common

Move strtoint() to common Several places used similar code to convert a string to an int, so take the function that we already had and make it globally available. Reviewed-by: Michael Paquier Branch -- master Details ---

pgsql: Fix CREATE TABLE / LIKE with bigint identity column

Fix CREATE TABLE / LIKE with bigint identity column CREATE TABLE / LIKE with a bigint identity column would fail on platforms where long is 32 bits. Copying the sequence values used makeInteger(), which would truncate the 64-bit sequence data to 32 bits. To fix, use makeFloat() instead, like the