Fix comment related to calculation location of total_table_pages
As of commit c6e4133, the calculation happens in make_one_rel() and not
query_planner().
Author: Amit Langote
Discussion:
https://postgr.es/m/[email protected]
Branch
--
master
Details
---
Fix rare dsa_allocate() failures due to freepage.c corruption.
In a corner case, a btree page was allocated during a clean-up operation
that could cause the tracking of the largest contiguous span of free
space to get out of whack. That was supposed to be prevented by the use
of the "soft" flag t
Fix rare dsa_allocate() failures due to freepage.c corruption.
In a corner case, a btree page was allocated during a clean-up operation
that could cause the tracking of the largest contiguous span of free
space to get out of whack. That was supposed to be prevented by the use
of the "soft" flag t
Fix rare dsa_allocate() failures due to freepage.c corruption.
In a corner case, a btree page was allocated during a clean-up operation
that could cause the tracking of the largest contiguous span of free
space to get out of whack. That was supposed to be prevented by the use
of the "soft" flag t
Tag refs/tags/REL_11_2 was created.
Tag refs/tags/REL9_4_21 was created.
Tag refs/tags/REL_10_7 was created.
Tag refs/tags/REL9_6_12 was created.
Tag refs/tags/REL9_5_16 was created.
Clean up planner confusion between ncolumns and nkeycolumns.
We're only going to consider key columns when creating indexquals,
so there is no point in having the outer loops in indxpath.c iterate
further than nkeycolumns.
Doing so in match_pathkeys_to_index() is actually wrong, and would have
ca
Clean up planner confusion between ncolumns and nkeycolumns.
We're only going to consider key columns when creating indexquals,
so there is no point in having the outer loops in indxpath.c iterate
further than nkeycolumns.
Doing so in match_pathkeys_to_index() is actually wrong, and would have
ca
Relax overly strict assertion
Ever since its birth, ReorderBufferBuildTupleCidHash() has contained an
assertion that a catalog tuple cannot change Cmax after acquiring one. But
that's wrong: if a subtransaction executes DDL that affects that catalog
tuple, and later aborts and another DDL affects
Relax overly strict assertion
Ever since its birth, ReorderBufferBuildTupleCidHash() has contained an
assertion that a catalog tuple cannot change Cmax after acquiring one. But
that's wrong: if a subtransaction executes DDL that affects that catalog
tuple, and later aborts and another DDL affects
Relax overly strict assertion
Ever since its birth, ReorderBufferBuildTupleCidHash() has contained an
assertion that a catalog tuple cannot change Cmax after acquiring one. But
that's wrong: if a subtransaction executes DDL that affects that catalog
tuple, and later aborts and another DDL affects
Relax overly strict assertion
Ever since its birth, ReorderBufferBuildTupleCidHash() has contained an
assertion that a catalog tuple cannot change Cmax after acquiring one. But
that's wrong: if a subtransaction executes DDL that affects that catalog
tuple, and later aborts and another DDL affects
Relax overly strict assertion
Ever since its birth, ReorderBufferBuildTupleCidHash() has contained an
assertion that a catalog tuple cannot change Cmax after acquiring one. But
that's wrong: if a subtransaction executes DDL that affects that catalog
tuple, and later aborts and another DDL affects
Relax overly strict assertion
Ever since its birth, ReorderBufferBuildTupleCidHash() has contained an
assertion that a catalog tuple cannot change Cmax after acquiring one. But
that's wrong: if a subtransaction executes DDL that affects that catalog
tuple, and later aborts and another DDL affects
On 2019-Feb-13, Thomas Munro wrote:
> whelk, woodlouse and dory say:
>
> Generating src/interfaces/ecpg/pgtypeslib/pgtypeslib.def...
> Unknown option: i../../../src/include/
> Usage: perl -I [directory of Catalog.pm] Gen_fmgrtab.pl
> [--include-path/-i ] [path to pg_proc.dat]
>
> Options:
>
Blind attempt at fixing Windows build
Broken since fe33a196de.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/d357a16997a2e9dce0f56299c739b2b2584c4026
Modified Files
--
src/tools/msvc/Solution.pm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
On Wed, Feb 13, 2019 at 2:26 AM Alvaro Herrera wrote:
>
> Use Getopt::Long for catalog scripts
>
> Replace hand-rolled option parsing with the Getopt module. This is
> shorter and easier to read. In passing, make some cosmetic adjustments
> for consistency.
>
> Author: John Naylor
> Reviewed-by: D
Use Getopt::Long for catalog scripts
Replace hand-rolled option parsing with the Getopt module. This is
shorter and easier to read. In passing, make some cosmetic adjustments
for consistency.
Author: John Naylor
Reviewed-by: David Fetter
Discussion:
https://postgr.es/m/CACPNZCvRjepXh5b2N50njN+rO
21 matches
Mail list logo
