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
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
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(),
## 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
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
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
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
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
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
