Fix default signature length for gist_ltree_ops
911e702077 implemented operator class parameters including the signature length
in ltree. Previously, the signature length for gist_ltree_ops was 8. Because
of bug 911e702077 the default signature length for gist_ltree_ops became 28 for
ltree 1.1 (
Fix default signature length for gist_ltree_ops
911e702077 implemented operator class parameters including the signature length
in ltree. Previously, the signature length for gist_ltree_ops was 8. Because
of bug 911e702077 the default signature length for gist_ltree_ops became 28 for
ltree 1.1 (
Fix default signature length for gist_ltree_ops
911e702077 implemented operator class parameters including the signature length
in ltree. Previously, the signature length for gist_ltree_ops was 8. Because
of bug 911e702077 the default signature length for gist_ltree_ops became 28 for
ltree 1.1 (
Hi Robert,
On Tue, Mar 15, 2022 at 05:33:12PM +, Robert Haas wrote:
> Allow extensions to add new backup targets.
>
> Commit 3500ccc39b0dadd1068a03938e4b8ff562587ccc allowed for base backup
> targets, meaning that we could do something with the backup other than
> send it to the client, but a
doc: Ensure intermediate path creation with mkdir
The mkdir command in the Installation from Source Short Version docs
didn't use the -p intermediate path creation parameter which likely
would cause the command to fail. At the time of writing, -p wasn't
universally available but it can now be rel
Suppress compiler warnings.
Michael Paquier
Discussion: http://postgr.es/m/yjgvq4zpdt6j1...@paquier.xyz
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/d0083c1d2a21f2e5c8f341891cca4fad5a616758
Modified Files
--
src/backend/replication/basebackup_target
On Wed, Mar 16, 2022 at 5:36 AM Michael Paquier wrote:
> I have noticed that this commit produces a warning when building with
> MSVC, as of the end of BaseBackupGetTargetHandle() when the target
> cannot be found. I guess that you'd better add a fake return NULL to
> keep such compilers quiet ab
On 3/15/22 23:42, Kyotaro Horiguchi wrote:
At Wed, 16 Mar 2022 11:13:53 +1300, Thomas Munro wrote
in
On Wed, Mar 16, 2022 at 10:28 AM Tom Lane wrote:
David Steele writes:
On 3/14/22 19:31, Thomas Munro wrote:
Fix pg_basebackup with in-place tablespaces.
Perhaps I'm being picky, but see
On Wed, Mar 16, 2022 at 09:52:41AM -0400, Robert Haas wrote:
> On Wed, Mar 16, 2022 at 5:36 AM Michael Paquier wrote:
> > I have noticed that this commit produces a warning when building with
> > MSVC, as of the end of BaseBackupGetTargetHandle() when the target
> > cannot be found. I guess that
Fix publish_as_relid with multiple publications
Commit 83fd4532a7 allowed publishing of changes via ancestors, for
publications defined with publish_via_partition_root. But the way
the ancestor was determined in get_rel_sync_entry() was incorrect,
simply updating the same variable. So with multipl
Fix publish_as_relid with multiple publications
Commit 83fd4532a7 allowed publishing of changes via ancestors, for
publications defined with publish_via_partition_root. But the way
the ancestor was determined in get_rel_sync_entry() was incorrect,
simply updating the same variable. So with multipl
Fix publish_as_relid with multiple publications
Commit 83fd4532a7 allowed publishing of changes via ancestors, for
publications defined with publish_via_partition_root. But the way
the ancestor was determined in get_rel_sync_entry() was incorrect,
simply updating the same variable. So with multipl
On Thu, Mar 17, 2022 at 3:29 AM David Steele wrote:
> Sure, but there is a behavioral change whether the GUC is enabled or
> not. Before, if there was clutter in pg_tblspc there would at least be a
> warning in the log. Now that logging does not happen.
If there's clutter that doesn't look like a
On 3/16/22 13:33, Thomas Munro wrote:
It seems that the warning at line 8313 is essentially dead code now. I
don't expect test code to have an impact on production systems, even if
the effect is minor.
It's not dead, it's how we'd report something like EACCES or EIO. Why
we only warn and pre
On Wed, Mar 16, 2022 at 09:52:41AM -0400, Robert Haas wrote:
> It sucks that I keep missing this point.
So do I. No worries. Thanks for fixing it!
--
Michael
signature.asc
Description: PGP signature
Fix pg_tablespace_location() with in-place tablespaces
Using this system function with an in-place tablespace (created when
allow_in_place_tablespaces is enabled by specifying an empty string as
location) caused a failure when using readlink(), as the tablespace is,
in this case, not a symbolic li
16 matches
Mail list logo