At Thu, 9 Sep 2021 14:52:25 +0900, Abhishek Bhola
wrote in
> I have found some questions about the same error, but didn't find any of
> them answering my problem.
>
> The setup is that I have two Postgres11 clusters (A and B) and they are
> making use of publication and subscription features to
Hi,
I have a publisher with around 30 tables. I have two types of subscribers.
Both types needs 25 "common" tables from the publisher plus 2-3 specific tables
for each type of subscriber.
For maintenance and monitoring reasons it is better for me to have both
subscribers point to the same pu
I have found some questions about the same error, but didn't find any of
them answering my problem.
The setup is that I have two Postgres11 clusters (A and B) and they are
making use of publication and subscription features to copy data from A to
B.
A (source DB- publication) --> B (t
YES!!! The chdir caused the error! Thanks very much for this help. BTW it
was worse than just "not a very good idea" to use chdir - After generating
the error, I would lose the ability to see things in my database until
restarting postgresql. All's okay now!
On Wed, Sep 8, 2021 at 8:56 PM Thomas M
On Thu, Sep 9, 2021 at 9:19 AM Celia McInnis wrote:
> Note that the file does exist:! (How do I know if it is looking under the
> correct directory? Other times I have done similar temporary table creations
> with no problems!):
PostgreSQL internally uses relative paths. It's probably not a ve
On Wednesday, September 8, 2021, Koen De Groote wrote:
> And initial setup is wrong. There should be no 'and a002=false' in the
> indexes.
>
>
>>> create index index_001 on my_table using btree (a001,a002,a003) where
>>> a001=true and a002=false;
>>>
>>> create index index_002 on my_table using b
And initial setup is wrong. There should be no 'and a002=false' in the
indexes.
On Wed, Sep 8, 2021 at 11:15 PM Koen De Groote wrote:
> Forgot to mention, this is on Postgres 11.2
>
> On Wed, Sep 8, 2021 at 11:04 PM Koen De Groote wrote:
>
>> Greetings all.
>>
>> Example table:
>>
>> CREATE TAB
Help - I don't know why I am getting this message, and I don't know how to
fix it. Any advice will be greatly appreciated.
Note that the file does exist:! (How do I know if it is looking under the
correct directory? Other times I have done similar temporary table
creations with no problems!):
*l
On Wednesday, September 8, 2021, Koen De Groote wrote:
> Forgot to mention, this is on Postgres 11.2
>
You should stop worrying about performance and indexes and instead focus
on system stability and security - i.e., upgrade to a supported version.
David J.
On Wednesday, September 8, 2021, Koen De Groote wrote:
>
>
> create index index_001 on my_table using btree (a001,a002,a003) where
> a001=true and a002=false;
>
> create index index_002 on my_table using btree (a003) where a001=true and
> a002=false;
>
> Now take this query:
>
> select * from my_
Forgot to mention, this is on Postgres 11.2
On Wed, Sep 8, 2021 at 11:04 PM Koen De Groote wrote:
> Greetings all.
>
> Example table:
>
> CREATE TABLE my_table (
> id serial PRIMARY KEY,
> a001 BOOLEAN default 't',
> a002 BOOLEAN default 'f',
> a003 BOOLEAN default 't',
> a00
Greetings all.
Example table:
CREATE TABLE my_table (
id serial PRIMARY KEY,
a001 BOOLEAN default 't',
a002 BOOLEAN default 'f',
a003 BOOLEAN default 't',
a004 BOOLEAN default 'f'
);
And these 2 indexes:
create index index_001 on my_table using btree (a001,a002,a003) where
a
Follow up to this. Turns out we had a table without a primary key which
halted the ongoing replication.
Reviewing this document in detail now.
https://pgdash.io/blog/postgres-replication-gotchas.html
- Miles Elam
We recently upgraded from v9.6 to v13 but are seeing some problems. It's on
AWS Aurora, so I won't ask to diagnose a heavily altered version. We're
hoping for better results with v12, but when we set up logical replication
from v13 to v12, while the initial data snapshot copies the data,
pg_stat_re
Alexander Kass writes:
> I've asked the user to perform `SELECT xmin, * from pg_attribute WHERE
> attrelid = 'pg_catalog.pg_database'::regclass` to check the
> attributes.
> The user has sent me that a couple of times: both times xmin is
> different, attrelid is different, both have a big value.
>
I've asked the user to perform `SELECT xmin, * from pg_attribute WHERE
attrelid = 'pg_catalog.pg_database'::regclass` to check the
attributes.
The user has sent me that a couple of times: both times xmin is
different, attrelid is different, both have a big value.
Does that mean that pg_database is
16 matches
Mail list logo
