Palle Girgensohn writes:
> 16 nov. 2019 kl. 23:06 skrev Thomas Munro :
>> Perhaps the best thing would be to revert this for the older
>> PostgreSQL releases so that people doing minor version upgrades are
>> inconvenienced by a system that can't start up after "pkg upgrade",
>> but do it for 12 s
On Sat, Nov 23, 2019 at 4:47 PM Tom Lane wrote:
> Note that you pay a fairly substantial performance penalty for deferring
> the check, which is why it isn't the default, even though the SQL spec
> says it ought to be.
>
Do you know what the worst case scenario is for the performance of
deferri
Jeff Janes writes:
> On Sat, Nov 23, 2019 at 4:47 PM Tom Lane wrote:
>> Note that you pay a fairly substantial performance penalty for deferring
>> the check, which is why it isn't the default, even though the SQL spec
>> says it ought to be.
> Do you know what the worst case scenario is for the
On Fri, Nov 22, 2019 at 01:20:59PM +, Zwettler Markus (OIZ) wrote:
> I came up with the following query which should return any apply lag in
> seconds.
>
> select coalesce(replay_delay, 0) replication_delay_in_sec
> from (
>select datname,
> (
> select ca
As a workaround, create a table with only one column and one value = `false`
and foreign to it.
On 22.11.2019 16:32, aleksey ksenzov wrote:
Latest time we faced several issues which wouldn't arise provided we have
possibility to use constants in foreign key constraints.
brief example where it
