Hello.
At Mon, 4 Nov 2019 19:05:24 +0530, Ashok Kumar Tiwari
wrote in
> is it possible in postgres to create one physical replica for DR(data
> recovery purpose) and another one logical replica for reporting purpose
A physical replication standby cannot be a publisher. You will find
that
On Tue, 5 Nov 2019 at 11:05, George Neuner wrote:
>
> On Sun, 03 Nov 2019 16:15:23 -0500, Tom Lane
> >Why don't you just change the search path to empty before selecting?
>
>
> I'm guessing this is fine inside a transaction, but what if you're
> using a client that commits by statement? In that
On Sun, 03 Nov 2019 16:15:23 -0500, Tom Lane
wrote:
>Michael Shapiro writes:
>> It seems that the definition of a view from pg_catalog.pg_views does not
>> qualify the tables used in the view if the tables are in the current search
>> path.
>
>> Is it possible to either have the definition
On Mon, Nov 4, 2019 at 10:05 AM Szymon Lipiński wrote:
>
> Hey,
> I'm wondering if this isn't a bug somewhere in the parser. I had to add
> additional parenthesis around the regexp_split_to_array.
>
>
> $ with x as (select 'a b c' a)
> select
> regexp_split_to_array(a, ' ')
> from x;
>
>
Hey,
I'm wondering if this isn't a bug somewhere in the parser. I had to add
additional parenthesis around the regexp_split_to_array.
$ with x as (select 'a b c' a)
select
regexp_split_to_array(a, ' ')
from x;
regexp_split_to_array
---
{a,b,c}
(1 row)
$ with x as
>
> Never, unless you drop and recreate the table. Removing a dropped
> column would change the attnums of following columns, which we
> can't support because the tableoid+attnum is the only persistent
> identifier of a column.
>
> (From memory, operations like VACUUM FULL and CLUSTER will
Ravi Krishna writes:
>> VACUUM would not change the state of the dropped columns.
> When does it change?
Never, unless you drop and recreate the table. Removing a dropped
column would change the attnums of following columns, which we
can't support because the tableoid+attnum is the only
>> Just to confirm, we are talking about tables from where some cols were
>> deleted in the past, but
>> VACUUM FULL not run on that table, right ?
>
> VACUUM would not change the state of the dropped columns.
>
When does it change?
Ravi Krishna writes:
>> On Nov 3, 2019, at 11:03 PM, Steve Baldwin wrote:
>> Thanks very much for the explanation Tom !! You are correct - there are
>> dropped columns in the original.
> Just to confirm, we are talking about tables from where some cols were
> deleted in the past, but
>
Is that how PgAdmin does it? The views extracted by PgAdmin are fully
qualified
On Sun, Nov 3, 2019 at 3:15 PM Tom Lane wrote:
> Michael Shapiro writes:
> > It seems that the definition of a view from pg_catalog.pg_views does not
> > qualify the tables used in the view if the tables are
Hi all,
is it possible in postgres to create one physical replica for DR(data
recovery purpose) and another one logical replica for reporting purpose
master > physical standby (for DR Purpose)
|
|
|
|
logical replica for reporting purpose
-- or
> On Nov 3, 2019, at 11:03 PM, Steve Baldwin wrote:
>
> Thanks very much for the explanation Tom !! You are correct - there are
> dropped columns in the original.
Just to confirm, we are talking about tables from where some cols were deleted
in the past, but
VACUUM FULL not run on that
12 matches
Mail list logo
