We've figured it out. Please ignore.
Regards.
On Fri, Apr 30, 2021 at 3:13 PM Patrik Novotny wrote:
> Hi,
>
> I need to reproduce the CVE-2020-25695 on PostgreSQL 9.2.24. I know this
> is not a supported version, however, it is important for us to have a
> reproducer for this
Hi,
I need to reproduce the CVE-2020-25695 on PostgreSQL 9.2.24. I know this is
not a supported version, however, it is important for us to have a
reproducer for this version as well.
The reproducer for supported versions[1] is based on REFRESH MATERIALIZED
VIEW which is not implemented until
>
>
> Yeah, that's what I was thinking as well -- dumping snapshot at
> regular intervals, so that on crash recovery we lose a "controlled
> amount" of recent starts instead of losing *everything*.
>
> I think in most situations a fairly long interval is OK -- if you have
> tables that take so
On Wed, Apr 21, 2021 at 5:05 PM Magnus Hagander wrote:
>
> > Right. I think the other question is how often does this happen in
> > practice - if your instance crashes often enough to make this an issue,
> > then there are probably bigger issues.
>
> Agreed.
>
> I think the bigger problem there
Hello PostgreSQL Hackers,
is it possible to preserve the PostgreSQL statistics on a server crash?
Steps to reproduce the behaviour:
1) Observe the statistics counters, take note
2) Crash the machine, e.g. with sysrq; perhaps kill -9 on postgresql will
already suffice
3) After recovery, observe
Hello all,
as to my recent findings, I'm not able to build postgresql 10.13
against libpq 12.1, as in that case, postgresql is missing changes
implemented in libpq 10.12 (and 12.2) [1]. So to rebase to postgresql
10.13 on a system with a separated libpq package shipped at version
12.1, I'm
On Thu, Nov 7, 2019 at 6:04 PM Christoph Berg wrote:
> How do other packagers handle that? Are you still supporting python2?
> Would it be ok to make plpythonu.control point at python3 in PG12 in
> Debian, even the upstream default is still python2?
Speaking for Fedora and RHEL, I'd say the best
confusion. I also attached the mentioned patch.
Regards,
On Tue, Sep 10, 2019 at 4:13 PM Tom Lane wrote:
>
> Patrik Novotny writes:
> > when the environment variable POSTGRESQL_UPGRADE_PGUPGRADE_OPTIONS is
> > used to specify options for pg_upgrade, options related to
> > u
Hi,
when the environment variable POSTGRESQL_UPGRADE_PGUPGRADE_OPTIONS is
used to specify options for pg_upgrade, options related to
unix_socket_directory/ies are being overridden by hardcoded options,
making it difficult to upgrade in some usecases.
The attached patch changes the order of those
