flush is flush to file, which makes it persistent.
Anybody gives some official explanation?
Thanks.
Regards,
Jinhua Luo
f trigger on view could not be
set to "enable always" or "enable replica", because "alter table"
would error it's not a base table, e.g.
tmp=# alter table foobar2_view enable always trigger foobar2_view_trigger;
ERROR: "foobar2_view" is not a table or foreign table
Help please, thanks.
Regards,
Jinhua Luo
apshot.
Is it expected or it's a bug? Anyways, alter publication would not
affect the replication stream is unexpected.
Regards,
Jinhua Luo
splits the changes of the
new seen table into other transactions applied by sync worker, so it
breaks the original transaction stream?
Regards,
Jinhua Luo
https://www.postgresql.org/docs/current/static/postgres-fdw.html#id-1.11.7.43.12
As the doc said, the REPEATABLE READ isolation level is used to get
snapshot-consistent results.
But is it possible that postgres_fdw could get to know which remote
queries involved by each top outer command in the l
cessary to join two
or more co-located parent tables in complex queries. If not, the
postgresql instance on which the parent tables are placed (let's say
it's a coordinator node) would be likely the bottleneck.)
Tom Lane 于2018年9月18日周二 下午9:43写道：
>
> Jinhua Luo writes:
> > T
Normally, EXPLAIN do not include the commands by stored procedures,
e.g. aggregated function, trigger, correct?
So how to review the plan by those extensions?
If the view definition is too complex to be automatic updateable, then
how postgresql defines OLD in INSTEAD OF trigger? It cannot bind any
column on any table directly then, right?
Unless postgresql refresh view as table source before executing
trigger? Then it may filter (WHERE sub-clause of UPD
That is, if table `foo` and table `bar` are both tables on the same
remote server, then when I do `select * from foo, bar`, can it
delegate the whole query on the remote side, rather than fetching rows
from both servers one by one and do merging on the local side?
For example:
```
foo=> explain s
Hi All,
If I need to change the master address from which the slave
replicates, must I restart the postgresql? Or just reload is ok?
Because I found in the source codes that if not explicitly set (e.g.
via pg_replication_origin_session_setup), the
replorigin_session_origin included in the wal is InvalidRepOriginId,
correct?
Jinhua Luo 于2018年9月9日周日 下午10:16写道：
>
> Could I assume all local originated changes i
Could I assume all local originated changes is with InvalidRepOriginId?
Jinhua Luo 于2018年9月8日周六 下午5:41写道：
>
> Hi All,
>
> What's the local logical replication origin, which could be used to
> filter local changes in the replication slot?
>
> In other words, I'm
Hi All,
My topology is as shown below:
slave1 <--physical streaming protocol-master1 master2 -- physical streaming protocol
---> slave2
The master1 and slave1 are within DC1, while the others are within DC2.
The logical streaming replication is
Hi All,
What's the local logical replication origin, which could be used to
filter local changes in the replication slot?
In other words, I'm curious that what's the default replication
origin? Because normal DML locally does not set any origin explicitly,
correct?
14 matches
Mail list logo
