Karsten Hilbert wrote:
> Which is why my question still stands: does the above
> three-strikes operation safely take care of any collation
> issues that may currently exist in a database ?
For the indexes, yes, but theorically, all constraints involving collatable
types need a recheck.
F
Am Mon, Nov 14, 2022 at 05:42:16PM +0100 schrieb Daniel Verite:
> > Which is why my question still stands: does the above
> > three-strikes operation safely take care of any collation
> > issues that may currently exist in a database ?
>
> For the indexes, yes, but theorically, all constraints inv
What type of bug is this?
Unexpected error
What subsystems and features are affected?
Other
What happened?
We are running into a weird permissions error that possibly seems to be related
to Postgres, but it’s not clear what exactly is causing the issue. We run a
script which grants the permission
Hi all!
We have a setup with a master and plenty of logical replication slaves.
Master and slaves are 12.12-1.pgdg22.04+1 runnning on Ubuntu 22.04.
SELECT pg_size_pretty( pg_database_size('regdns') ); is from 25GB (fresh
installed slave) to 42GB (probably bloat)
Replication slaves VMs have be
klaus.mailingli...@pernau.at writes:
> On several servers we see the error message: PANIC: could not flush
> dirty data: Cannot allocate memory
What that's telling you is that fsync (or some equivalent OS call)
returned ENOMEM, which would seem to be a kernel-level deficiency.
Perhaps you could
## klaus.mailingli...@pernau.at (klaus.mailingli...@pernau.at):
> On several servers we see the error message: PANIC: could not flush
> dirty data: Cannot allocate memory
As far as I can see, that "could not flush dirty data" happens total
three times in the code - there are other places where
On Tue, Nov 15, 2022 at 10:54 AM Christoph Moench-Tegeder
wrote:
> ## klaus.mailingli...@pernau.at (klaus.mailingli...@pernau.at):
> > On several servers we see the error message: PANIC: could not flush
> > dirty data: Cannot allocate memory
> Of these three places, there's an sync_file_range(),
At Mon, 14 Nov 2022 00:09:36 +0800, 徐志宇徐 wrote in
> If the primary and standby have long replay_lag. I don't want to
> standby server promote.
>
> Is there any view or function which store the latest stream
> replication gap(replay_lag) between primary and standby ?
> Or it the
Thomas Munro writes:
> It has been argued before that we might have been over-zealous
> applying the PANIC promotion logic to sync_file_range(). It's used to
> start asynchronous writeback to make the later fsync() call fast, so
> it's "only a hint", but I have no idea if it could report a writeb
