lp:postgresql

Created by Max Bowsher on 2011-01-03 and last modified on 2018-02-21
Get this branch:
bzr branch lp:postgresql

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
VCS imports
Project:
PostgreSQL
Status:
Development

Import details

Import Status: Reviewed

This branch is an import of the HEAD branch of the Git repository at git://git.postgresql.org/git/postgresql.git.

The next import is scheduled to run in 5 hours.

Last successful import was 8 minutes ago.

Import started 9 minutes ago on pear and finished 8 minutes ago taking 50 seconds — see the log
Import started 6 hours ago on pear and finished 6 hours ago taking 40 seconds — see the log
Import started 12 hours ago on russkaya and finished 12 hours ago taking 2 minutes — see the log
Import started 18 hours ago on pear and finished 18 hours ago taking 50 seconds — see the log
Import started on 2018-02-20 on pear and finished on 2018-02-20 taking 1 minute — see the log
Import started on 2018-02-20 on pear and finished on 2018-02-20 taking 50 seconds — see the log
Import started on 2018-02-20 on pear and finished on 2018-02-20 taking 50 seconds — see the log
Import started on 2018-02-19 on pear and finished on 2018-02-19 taking 50 seconds — see the log
Import started on 2018-02-19 on russkaya and finished on 2018-02-19 taking 1 minute — see the log
Import started on 2018-02-19 on russkaya and finished on 2018-02-19 taking 1 minute — see the log

Recent revisions

44304. By Andres Freund 14 hours ago

Blindly attempt to adapt sepgsql regression tests.

Commit bf6c614a2f2c58312b3be34a47e7fb7362e07bcb broke the sepgsql test
due to a new invocation of the function access hook during grouping
equal initialization.

The new behaviour seems at least as correct as the old one, so try
adapt the tests. As I've no working sepgsql setup here, this is just
going from buildfarm results.

Author: Andres Freund
Discussion: https://<email address hidden>

44303. By Andres Freund 17 hours ago

Use platform independent type for TupleTableSlot->tts_off.

Previously tts_off was, for unknown reasons, of type long. For one
that's unnecessary as tuples are restricted in length, for another
long would be a bad choice of type even if that weren't the case, as
it's not reliably wider than an int. Also HeapTupleHeader->t_len is a
uint32.

This is split off from a larger patch implementing JITed tuple
deforming. Seems like an independent improvement, as tiny as it is.

Author: Andres Freund

44302. By Peter Eisentraut 17 hours ago

Error message improvement

44301. By Tom Lane <email address hidden> on 2018-02-20

Fix pg_dump's logic for eliding sequence limits that match the defaults.

The previous coding here applied atoi() to strings that could represent
values too large to fit in an int. If the overflowed value happened to
match one of the cases it was looking for, it would drop that limit
value from the output, leading to incorrect restoration of the sequence.

Avoid the unsafe behavior, and also make the logic cleaner by explicitly
calculating the default min/max values for the appropriate kind of
sequence.

Reported and patched by Alexey Bashtanov, though I whacked his patch
around a bit. Back-patch to v10 where the faulty logic was added.

Discussion: https://<email address hidden>

44300. By Álvaro Herrera on 2018-02-20

Adjust ALTER TABLE docs on partitioned constraints

Move the "additional restrictions" comment to ALTER TABLE ADD
CONSTRAINT instead of ADD CONSTRAINT USING INDEX; and in the latter
instead indicate that partitioned tables are unsupported

Noted by David G. Johnston
Discussion: https://<email address hidden>

44299. By Magnus Hagander on 2018-02-20

Fix typo

Author: Masahiko Sawada

44298. By Álvaro Herrera on 2018-02-20

Fix crash in pg_replication_slot_advance

We were trying to use a LSN variable after releasing its containing slot
structure.

Reported by: tushar
Author: amul sul
Reviewed-by: Petr Jelinek, Masahiko Sawada
Discussion: https://<email address hidden>

44297. By Tom Lane <email address hidden> on 2018-02-19

Fix misbehavior of CTE-used-in-a-subplan during EPQ rechecks.

An updating query that reads a CTE within an InitPlan or SubPlan could get
incorrect results if it updates rows that are concurrently being modified.
This is caused by CteScanNext supposing that nothing inside its recursive
ExecProcNode call could change which read pointer is selected in the CTE's
shared tuplestore. While that's normally true because of scoping
considerations, it can break down if an EPQ plan tree gets built during the
call, because EvalPlanQualStart builds execution trees for all subplans
whether they're going to be used during the recheck or not. And it seems
like a pretty shaky assumption anyway, so let's just reselect our own read
pointer here.

Per bug #14870 from Andrei Gorita. This has been broken since CTEs were
implemented, so back-patch to all supported branches.

Discussion: https://<email address hidden>

44296. By Álvaro Herrera on 2018-02-19

Fix expected output

44295. By Álvaro Herrera on 2018-02-19

Allow UNIQUE indexes on partitioned tables

If we restrict unique constraints on partitioned tables so that they
must always include the partition key, then our standard approach to
unique indexes already works --- each unique key is forced to exist
within a single partition, so enforcing the unique restriction in each
index individually is enough to have it enforced globally. Therefore we
can implement unique indexes on partitions by simply removing a few
restrictions (and adding others.)

Discussion: https://<email address hidden>
Discussion: https://<email address hidden>
Reviewed-by: Simon Riggs, Jesper Pedersen, Peter Eisentraut, Jaime
 Casanova, Amit Langote

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
This branch contains Public information 
Everyone can see this information.

Subscribers

No subscribers.