swer. It is now clear to me why such behaviour
occurs.
Regards
On Sun, 10 Nov 2024, 20:07 Adrian Klaver, wrote:
> On 11/10/24 05:18, user wrote:
> > Hello,
> > Sorry for nagging, but I would really like to find some answers.
> > So, to reiterate. Experiment done as follows:
&
ass c on (relation = c.oid)
join pg_namespace nsp on (c.relnamespace = nsp.oid);
"""""
My questions are:
1. Why is postgres adding again a constraint? Can't it detect that foreign
key already exists? I want to avoid locking partitioned table for too l
reproduce it.
Regards
On Mon, 21 Oct 2024 at 20:31, Adrian Klaver
wrote:
>
>
> On 10/21/24 1:40 AM, user wrote:
> > ** forwarding to mailing list, forgot to add header
> >
> >
> > Thanks for answering.
> > I think one misunderstanding happened.
> > The parent
manually create it before I attach.
It is new when I run attach command without previous manual constraint
creation, but then the lock is not created.
On Sun, 20 Oct 2024, 18:23 Adrian Klaver, wrote:
> On 10/20/24 04:31, user wrote:
> > Hello,
> > I was reading all the tips that
Hello,
I was reading all the tips that could make the attach partition operation
seamless. https://www.postgresql.org/docs/current/ddl-partitioning.html
There is a mention about check constraint that could be places before the
attach process. But to minimise the time when AccessExclusive lock is he
Does anyone know a best practice when it comes to installing barman?
Would barman be on its own system or does it make sense to have it running
on a cascaded postgres server?
I'm just getting started with it so I'd like to see how others have
implemented its use in a variety of different implemen
CREATE TABLE public.test1 (
x1 integer NOT NULL,
x2 integer NOT NULL,
CONSTRAINT test1_pkey PRIMARY KEY (x1) INCLUDE(x2)
) PARTITION BY RANGE (x2);
This query works in 11.1 but fails in 11.3 with messages:
ERROR: insufficient columns in PRIMARY KEY constraint definition
DETAIL: PRIMA
