Andres Freund writes:
> So, does anybody see a reason not to go for the trivial
> [ patch ]
I'd be happy to rely on the buildfarm's opinion here.
> Although I'm mildly tempted to rewrap the parameters, it's kinda odd how the
> trailing parameter on one line, has its value on the next line.
I'm
On 2021/10/10 1:25, Bharath Rupireddy wrote:
On Sat, Oct 9, 2021 at 9:42 PM Justin Pryzby wrote:
I doubt there's much confusion here - crashes are treated the same. I think
the fix would be to say "server crash" rather than backend crash.
IIUC, the "server crash" includes any backend, au
On Sat, Oct 09, 2021 at 04:34:46PM -0400, Tom Lane wrote:
> Hah ... your backpan link led me to realize the actual problem with
> Test::More. It got folded into Test::Simple at some point, and
> evidently cpanm isn't smart enough to handle a request for a back
> version in such cases. But this wo
On Thu, Oct 7, 2021 at 10:34 PM Peter Geoghegan wrote:
> This issue was brought to my attention by Nikolay Samokhvalov. He
> reached out privately about it. He mentioned one problematic case
> involving an ANALYZE lasting 45 minutes, or longer (per
> log_autovacuum_min_duration output for the auto
Hi,
The freebsd image I use for CI runs just failed because the package name for
openldap changed (it's now either openldap{24,25}-{client,server}, instead of
openldap-..}. I naively resolved that conflict by choosing the openldap25-*
packages. Which unfortunately turns out to break 001_auth.pl :(
Hah ... your backpan link led me to realize the actual problem with
Test::More. It got folded into Test::Simple at some point, and
evidently cpanm isn't smart enough to handle a request for a back
version in such cases. But this works:
$ cpanm install Test::Simple@0.87_01
...
$ perl -MTest::More
On Sat, Oct 09, 2021 at 03:44:17PM -0400, Tom Lane wrote:
> > By the way, I suspect 93fb39e introduced a regression in the recipe. (I
> > haven't tested, though.) Before commit 93fb39e, "cpanm install IPC::Run"
> > would update Test::More. As of 5.8.3, the core version of Test::More is new
> > e
Hi,
we have a replica product that access to wal files with logical replication.
After a reboot following a database fault we receive the following issue.
2021-10-08 16:07:31.829 CEST:127.0.0.1(49880):cdcadm@REPLICA:[12976]:
ERROR: unexpected duplicate for tablespace 16389, relfilenode 484036
B
Noah Misch writes:
> On Fri, Oct 08, 2021 at 12:03:41PM -0400, Tom Lane wrote:
>> You're not going to get far with "improving the recipe", because it's
>> just not possible. To check this, I installed perlbrew on a Fedora 34
> Your test result is evidence that "cpanm install Test::More@0.87" is
On Fri, Oct 08, 2021 at 12:03:41PM -0400, Tom Lane wrote:
> Daniel Gustafsson writes:
> > On 8 Oct 2021, at 06:24, Noah Misch wrote:
> >> That's obvious from "cpanm install IPC::Run". Surely if any other non-core
> >> module were allowed, the recipe would list it in a similar way.
>
> > The pro
I wrote:
> Shay Rojansky writes:
>> First, starts_with doesn't seem to use SP-GIST indexes, contrary to
>> the patch description (and also doesn't trigger a parallel seq scan) -
>> is this intentional?
> It seems like it didn't occur to anybody to tie starts_with() into
> the machinery for derive
When starts_with() and the equivalent ^@ operator were added, they
were plugged into the planner in only a rather half-baked way.
Selectivity estimation got taught about the operator, but the
other infrastructure associated with LIKE/regex matching wasn't
updated. This causes these operators to be
On Sat, Oct 9, 2021 at 9:42 PM Justin Pryzby wrote:
>
> I doubt there's much confusion here - crashes are treated the same. I think
> the fix would be to say "server crash" rather than backend crash.
IIUC, the "server crash" includes any backend, auxiliary process,
postmaster crash i.e. database
On Sat, Oct 09, 2021 at 09:18:24PM +0530, Bharath Rupireddy wrote:
> On Fri, Oct 8, 2021 at 4:27 PM Bharath Rupireddy
> wrote:
> >
> > Hi,
> >
> > The commit [1] for the feature "Remove temporary files after backend
> > crash" introduced following in the docs:
> > +
> > +When set t
On Fri, Oct 8, 2021 at 4:27 PM Bharath Rupireddy
wrote:
>
> Hi,
>
> The commit [1] for the feature "Remove temporary files after backend
> crash" introduced following in the docs:
> +
> +When set to on, which is the default,
> +PostgreSQL will automatically remove
> +
Shay Rojansky writes:
> In PostgreSQL 11, a starts_with function and a ^@ operators were added
> for string prefix checking, as an alternative to LIKE 'foo%' [1] [2].
> First, starts_with doesn't seem to use SP-GIST indexes, contrary to
> the patch description (and also doesn't trigger a parallel
On Fri, Oct 8, 2021 at 8:58 PM Fujii Masao wrote:
> >>> Thanks for the patch. Do we also need to do the change in
> >>> HandleMainLoopInterrupts, HandleCheckpointerInterrupts,
> >>> HandlePgArchInterrupts, HandleWalWriterInterrupts as we don't call
> >>> CHECK_FOR_INTERRUPTS() there?
> >
> >> Yeah
Hi,
Currently pg_log_backend_memory_contexts() doesn't log the memory
contexts of auxiliary processes such as bgwriter, checkpointer, wal
writer, archiver, startup process and wal receiver. It will be useful
to look at the memory contexts of these processes too, for debugging
purposes and better u
Hi,
It looks like auxiliary processes will not have a valid MyBackendId as
they don't call InitPostgres() and SharedInvalBackendInit() unlike
backends. But the startup process (which is an auxiliary process) in
hot standby mode seems to be different in the way that it does have a
valid MyBackendId
On Fri, 8 Oct 2021 at 21:21, Alvaro Herrera wrote:
>
> On 2021-Oct-08, Matthias van de Meent wrote:
>
> > That's a good point, but if we're extending this syntax to allow the
> > ability of including other types, then I'd instead extend the syntax
> > that of below, so that the type of the diction
On Sat, Oct 9, 2021 at 3:56 AM Bharath Rupireddy
wrote:
> > I would think that these would fall under "pg_read_all_stats", in
> > particular, which is explicitly documented as: Read all pg_stat_* views
> > and use various statistics related extensions, even those normally
> > visible only to super
Greetings hackers,
I'm seeing some odd behavior around string prefix searching -
hopefully I've missed something here (thanks to Nino Floris for
originally flagging this).
In PostgreSQL 11, a starts_with function and a ^@ operators were added
for string prefix checking, as an alternative to LIKE
22 matches
Mail list logo
