pgsql: Don't cast between GinNullCategory and bool

Don't cast between GinNullCategory and bool The original idea was that we could use an isNull-style bool array directly as a GinNullCategory array. However, the existing code already acknowledges that that doesn't really work, because of the possibility that bool as currently defined can have arb

Re: pgsql: Add parallel-aware hash joins.

On Sun, Dec 31, 2017 at 1:00 PM, Tom Lane wrote: >> Right. That's apparently unrelated and is the last build-farm issue >> on my list (so far). I had noticed that certain BF animals are prone >> to that particular failure, and they mostly have architectures that I >> don't have so a few things a

Re: pgsql: Add parallel-aware hash joins.

Thomas Munro writes: > On Sun, Dec 31, 2017 at 1:00 PM, Tom Lane wrote: >> "Size estimation error"? Why do you think it's that? We have exactly >> the same plan in both cases. > I mean that ExecChooseHashTableSize() estimates the hash table size like this: > inner_rel_bytes = ntuples * tup

pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY

Fix deadlock hazard in CREATE INDEX CONCURRENTLY Multiple sessions doing CREATE INDEX CONCURRENTLY simultaneously are supposed to be able to work in parallel, as evidenced by fixes in commit c3d09b3bd23f specifically to support this case. In reality, one of the sessions would be aborted by a mist

pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY

Fix deadlock hazard in CREATE INDEX CONCURRENTLY Multiple sessions doing CREATE INDEX CONCURRENTLY simultaneously are supposed to be able to work in parallel, as evidenced by fixes in commit c3d09b3bd23f specifically to support this case. In reality, one of the sessions would be aborted by a mist

pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY

Fix deadlock hazard in CREATE INDEX CONCURRENTLY Multiple sessions doing CREATE INDEX CONCURRENTLY simultaneously are supposed to be able to work in parallel, as evidenced by fixes in commit c3d09b3bd23f specifically to support this case. In reality, one of the sessions would be aborted by a mist

pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY

Fix deadlock hazard in CREATE INDEX CONCURRENTLY Multiple sessions doing CREATE INDEX CONCURRENTLY simultaneously are supposed to be able to work in parallel, as evidenced by fixes in commit c3d09b3bd23f specifically to support this case. In reality, one of the sessions would be aborted by a mist

pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY

Fix deadlock hazard in CREATE INDEX CONCURRENTLY Multiple sessions doing CREATE INDEX CONCURRENTLY simultaneously are supposed to be able to work in parallel, as evidenced by fixes in commit c3d09b3bd23f specifically to support this case. In reality, one of the sessions would be aborted by a mist

pgsql: Ensure proper alignment of tuples in HashMemoryChunkData buffers

Ensure proper alignment of tuples in HashMemoryChunkData buffers. The previous coding relied (without any documentation) on the data[] member of HashMemoryChunkData being at a MAXALIGN'ed offset. If it was not, the tuples would not be maxaligned either, leading to failures on alignment-picky mach

pgsql: Simplify representation of aggregate transition values a bit.

Simplify representation of aggregate transition values a bit. Previously aggregate transition values for hash and other forms of aggregation (i.e. sort and no group by) were represented differently. Hash based aggregation used a grouping set indexed array pointing to an array of transition values,

Re: pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY

Hi, On 2018-01-03 02:20:14 +, Alvaro Herrera wrote: > Fix deadlock hazard in CREATE INDEX CONCURRENTLY > > Multiple sessions doing CREATE INDEX CONCURRENTLY simultaneously are > supposed to be able to work in parallel, as evidenced by fixes in commit > c3d09b3bd23f specifically to support thi

pgsql: Update copyright for 2018

Update copyright for 2018 Backpatch-through: certain files through 9.3 Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/22f5e8924a44120465ef2934fe311d8b903f204a Modified Files -- COPYRIGHT | 2 +- doc/src/sgml/legal.sgml | 6 +++--- 2

pgsql: Update copyright for 2018

Update copyright for 2018 Backpatch-through: certain files through 9.3 Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9173695b616665592d3dc62a72ef5cbb859dca65 Modified Files -- COPYRIGHT | 2 +- doc/src/sgml/legal.sgml | 6 +++--- 2

pgsql: Update copyright for 2018

Update copyright for 2018 Backpatch-through: certain files through 9.3 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/724bceae4fde75faacdb900d0f165eac3b6fce4f Modified Files -- COPYRIGHT | 2 +- doc/src/sgml/legal.sgml | 6 +++--- 2

pgsql: Update copyright for 2018

Update copyright for 2018 Backpatch-through: certain files through 9.3 Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1a6429d455962191da78a61475b89b434643385e Modified Files -- COPYRIGHT | 2 +- doc/src/sgml/legal.sgml | 6 +++--- 2

pgsql: Update copyright for 2018

Update copyright for 2018 Backpatch-through: certain files through 9.3 Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/aa7d71be4b935cd959b19b1e112792981edcdc15 Modified Files -- COPYRIGHT | 2 +- doc/src/sgml/legal.sgml | 6 +++--- 2