Hi,
On 2023-05-15 14:20:24 +0900, Michael Paquier wrote:
> On Thu, May 11, 2023 at 01:28:40PM +0900, Michael Paquier wrote:
> > On Tue, May 09, 2023 at 09:48:24AM -0700, Andres Freund wrote:
> >> On 2023-05-08 12:11:17 -0700, Andres Freund wrote:
> >>> I can reproduc
Hi,
On 2023-05-15 15:30:28 -0700, Andres Freund wrote:
> As soon as either the pg_ctl for the start, or the whole bash invocation, has
> stdin redirected, the problem vanishes.
For a moment I thought this could be related to InheritStdHandles() - but no,
it doesn't make a difference.
T
Hi,
On 2023-05-15 13:13:26 -0700, Andres Freund wrote:
> It wouldn't really - the echo $? inside the system() would report the
> error. Which it doesn't - note the "0" in the second output.
Ah. Interesting. Part of the issue is perl (or msys?) swalling some error
details.
Hi,
On 2023-05-15 16:01:39 -0400, Andrew Dunstan wrote:
> On 2023-05-15 Mo 15:38, Andres Freund wrote:
> > Hi,
> >
> > On 2023-05-05 07:08:39 -0400, Andrew Dunstan wrote:
> > > If you want to play I can arrange access.
> > Andrew did - thanks!
> >
>
uff that InheritstdHandles()
does?
Andrew, is it ok if modify pg_ctl.c and rebuild? I don't know how "detached"
from the actual buildfarm animal the system you gave me access to is...
Greetings,
Andres Freund
ww.postgresql.org/message-id/flat/77a86b3a-c4a8-5f5d-69b9-d70bbf2e9...@gmail.com
>
> Looking forward to your feedback,
Without an explanation for why this change is needed for [1], it's hard to
give useful feedback...
Greetings,
Andres Freund
Hi,
On May 12, 2023 11:36:23 AM PDT, Thomas Munro wrote:
>Just a thought: should RelationCopyStorageUsingBuffer(), the new code
>used by CREATE DATABASE with the default strategy WAL_LOG, use the
>newer interface so that it creates fully allocated files instead of
>sparse ones?
I played with
Hi,
On May 11, 2023 2:37:00 AM PDT, Peter Eisentraut
wrote:
>On 10.05.23 20:10, Andres Freund wrote:
>>> Moreover, the text "except the relation can be extended by multiple blocks
>>> at once and the added blocks will be filled with zeroes" doesn't make much
ust does it by writing data.
The FileFallocate() path in smgrzeroextend() tries to avoid writing data if
extending by sufficient blocks - not having dirty data in the kernel page
cache can substantially reduce the IO usage.
Whereas the FileZero() path just optimizes the number of syscalls (and cache
misses etc).
Greetings,
Andres Freund
Hi,
On 2023-05-10 17:44:07 +0200, Peter Eisentraut wrote:
> On 12.03.23 00:41, Andres Freund wrote:
> > Hi,
> >
> > On 2023-03-11 15:34:55 -0800, Mark Dilger wrote:
> > > > On Mar 11, 2023, at 3:22 PM, Andres Freund wrote:
> > > >
> > &
Hi,
On 2023-05-09 13:38:24 -0700, Jeff Davis wrote:
> On Tue, 2023-05-09 at 12:02 -0700, Andres Freund wrote:
> > I don't think the approach of not having any sort of "registry" of
> > whether
> > anybody is waiting for the replay position to be updated is
&
he reason why the context matters is that some reloptions are disallowed to
> change after creating
> the table, while some reloptions are allowed.
What kind of reloption are you thinking of here?
Greetings,
Andres Freund
Hi,
Unfortunately I have found the following commit to have caused a performance
regression:
commit e101dfac3a53c20bfbf1ca85d30a368c2954facf
Author: Andres Freund
Date: 2023-04-08 00:24:24 -0700
For cascading replication, wake physical and logical walsenders separately
Physical
Hi,
On 2023-05-08 12:11:17 -0700, Andres Freund wrote:
> Hi,
>
> On 2023-05-08 16:00:01 +0300, Alexander Lakhin wrote:
> > This difference is confirmed by multiple test runs. `git bisect` for this
> > regression pointed at f193883fc.
>
> I can reproduce a significant
if 'invalid because creating' and
> 'invalid because dropping' were distinguished).
I'm bit hesitant to do so for now. Once it's a bit more settled, maybe?
Although I wonder if there's something better suited to the task than
autovacuum.
Greetings,
Andres Freund
and at segment
> boundaries.
I've pondered that as well. But I don't think it's great - it's not exactly
intuitive that stats reporting gets far less common if you use a 1GB
wal_segment_size.
Greetings,
Andres Freund
Hi,
On 2023-04-25 10:28:58 -0700, Andres Freund wrote:
> On 2023-04-25 11:42:43 -0400, Robert Haas wrote:
> > On Mon, Apr 24, 2023 at 8:03 PM Andres Freund wrote:
> > > What we've discussed somewhere in the past is to always truncate N+1 when
> > > creating the first p
; SEGSIZE it'll
only truncate , not .N. And boom, a disconnected
segment.
(I'll post a separate email about an evolved proposal about fixing this set of
issues)
Greetings,
Andres Freund
Hi,
On 2023-05-05 07:08:39 -0400, Andrew Dunstan wrote:
> On 2023-05-04 Th 19:54, Andres Freund wrote:
> > Hm. I can't reproduce this in my test win10 VM, unfortunately. What OS / OS
> > version is the host? Any chance to get systeminfo.exe output or something
> > like
but haven't we gone further and even
backpatched things like spinlock support for new arches in the past?
Greetings,
Andres Freund
ed. We also now need to do permission checking etc.
I don't think that's the entirety of the regression...
Greetings,
Andres Freund
e low, but 16
has two low results.
Greetings,
Andres Freund
Hi,
On 2023-05-03 09:20:28 -0400, Andrew Dunstan wrote:
> On 2023-04-27 Th 18:18, Andres Freund wrote:
> > On 2023-04-26 09:59:05 -0400, Andrew Dunstan wrote:
> > > Still running into this, and I am rather stumped. This is a blocker for
> > > buildfarm support fo
l use the normal backend logic, and thus also trigger writebacks?
Greetings,
Andres Freund
uldn't be too
hard. I'll try to look more tomorrow.
Greetings,
Andres Freund
context to ScheduleBufferTagForWriteback instead?
> --- a/src/test/regress/sql/stats.sql
> +++ b/src/test/regress/sql/stats.sql
Hm. Could we add a test for this? While it's not implemented everywhere, we
still issue the smgrwriteback() afaics. The default for the _flush_after GUCs
changes, but backend_flush_after is USERSET, so we could just change it for a
single command.
Greetings,
Andres Freund
lso what are the 'seconds' and 'tbl-MBs' metrics that were reported.
The total time for inserting N (1024 for the small files, 64 for the larger
ones). "tbl-MBs" is size of the resulting table, divided by time. I.e. a
measure of throughput.
Greetings,
Andres Freund
;
> [2] COPY (SELECT repeat(random()::text, 5) FROM generate_series(1, 6*10))
> TO '/tmp/copytest_data_text.copy' WITH (FORMAT text);
Greetings,
Andres Freund
Hi,
On 2023-05-03 09:20:28 -0400, Andrew Dunstan wrote:
> On 2023-04-27 Th 18:18, Andres Freund wrote:
> > Hi,
> >
> > On 2023-04-26 09:59:05 -0400, Andrew Dunstan wrote:
> > > Still running into this, and I am rather stumped. This is a blocker for
>
s dependent on the windows runtime
version.
Downthread you mention that the issue doesn't happen with IPC::Run - the
biggest difference I can see is that IPC::Run would IIRC not use a shell? Does
the problem "re-appear" if you make IPC::Run use a shell?
Greetings,
Andres Freund
nclude/utils/timeout.h b/src/include/utils/timeout.h
> index e561a1cde9..a8d360e255 100644
> --- a/src/include/utils/timeout.h
> +++ b/src/include/utils/timeout.h
> @@ -35,6 +35,7 @@ typedef enum TimeoutId
> IDLE_STATS_UPDATE_TIMEOUT,
> CLIENT_CONNECTION_CHECK_TIMEOUT,
> STARTUP_PROGRESS_TIMEOUT,
> + STARTUP_STAT_FLUSH_TIMEOUT,
> /* First user-definable timeout reason */
> USER_TIMEOUT,
> /* Maximum number of timeout reasons */
I think we could just reuse IDLE_STATS_UPDATE_TIMEOUT?
Greetings,
Andres Freund
Hi,
On 2023-04-25 16:00:24 -0400, Robert Haas wrote:
> On Tue, Apr 25, 2023 at 2:39 PM Andres Freund wrote:
> > I'm mildly inclined to not consider it a bug, given that this looks to have
> > been true for other stats for quite a while? But it does still seem worth
> > impr
tup process on the standby.
> Elsewhere on the internet where you originally raised this, I mentioned
> that I hacked a pgstat_flush_io() into the redo apply loop in
> PerformWalRecovery() but that I wasn't sure that this was affordable.
> Andres Freund replied saying that it would be too
Hi,
On 2023-04-25 11:42:43 -0400, Robert Haas wrote:
> On Mon, Apr 24, 2023 at 8:03 PM Andres Freund wrote:
> > What we've discussed somewhere in the past is to always truncate N+1 when
> > creating the first page in N. I.e. if we extend into 23456.1, we truncate
> > 23456.2
Hi,
On 2023-04-24 15:32:25 -0700, Andres Freund wrote:
> On 2023-04-24 10:53:35 +0200, Christoph Berg wrote:
> > I'm often seeing PG16 builds erroring out in the pgbench tests:
> > I don't think the disk is full since it's always hitting that same
> > spot, on some of
a right now.
What we've discussed somewhere in the past is to always truncate N+1 when
creating the first page in N. I.e. if we extend into 23456.1, we truncate
23456.2 to 0 blocks. As far as I can tell, that'd solve this issue?
Greetings,
Andres Freund
Hi,
On 2023-04-24 18:36:24 -0400, Melanie Plageman wrote:
> On Mon, Apr 24, 2023 at 6:13 PM Andres Freund wrote:
> > > Also, it seems like this (given the current code) is only reachable for
> > > permanent relations (i.e. not for IO object temp relation). If other
> &g
ack() / pg_flush_data()
- FileSync() / pg_fsync()
- FileFallocate()
- FileTruncate()
With the first two there's the added complication that it's not entirely
obvious whether it'd be better to handle this in File* or pg_*. I'd argue the
latter is a bit more sensible?
Greetings,
Andres Freund
On 2023-04-21 07:38:01 +0900, Michael Paquier wrote:
> On Thu, Apr 20, 2023 at 11:38:42AM +0900, Michael Paquier wrote:
> > No worries, committers should take care of that.
>
> Done as of 0ecb87e, as I can keep an eye on the buildfarm today, with
> a catversion bump.
Thanks!
s in PG16 or not. If this is just adding a new column and a few
> existing stats update calls then it should be okay to get in but if
> this requires some more complex work then we can probably update the
> docs.
I suspect it should really just be adding a few stats calls. The only possible
complication that I can see is that we might need to pass a bit more context
down in a place or two.
Greetings,
Andres Freund
Hi,
On 2023-04-24 17:37:48 -0400, Melanie Plageman wrote:
> On Mon, Apr 24, 2023 at 02:14:32PM -0700, Andres Freund wrote:
> > It starts blocking once "enough" IO is in flight. For things like an
> > immediate
> > checkpoint, that can happen fairly quickly,
Hi,
On 2023-04-24 16:39:36 -0400, Melanie Plageman wrote:
> On Wed, Apr 19, 2023 at 10:23:26AM -0700, Andres Freund wrote:
> > Hi,
> >
> > I noticed that the numbers in pg_stat_io dont't quite add up to what I
> > expected in write heavy workloads. Particularly for che
Hi,
On 2023-04-24 14:36:36 +0200, Alvaro Herrera wrote:
> On 2023-Apr-22, Andres Freund wrote:
> > I'm afraid we'll need TransactionIdRetreatSafely() again, when we convert
> > more
> > things to 64bit xids (lest they end up with the same bug as fixed by
> > be504a3e
Hi,
On 2023-04-13 13:18:38 +0200, Alvaro Herrera wrote:
> On 2023-Apr-11, Andres Freund wrote:
>
> > Updated patch attached. I think we should either apply something like that
> > patch, or at least add a to the docs.
>
> I gave this patch a loo
Hi,
On 2023-04-20 12:43:48 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Afaict the only safe thing to use when stripping static libs is
> > -g/--strip-debug.
>
> The previous complaint about this [1] suggested we use --strip-unneeded
> for all cases with GNU strip,
6:45:25 +
Add make install-strip target.
Afaict the only safe thing to use when stripping static libs is
-g/--strip-debug.
Greetings,
Andres Freund
pendant in
> various ways (which is why the tests use "explain analyze so rarely).
I think with sufficient options it's not machine specific. We have a bunch of
EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF) ..
in our tests.
Greetings,
Andres Freund
Hi,
On 2023-04-19 13:16:54 -0400, Robert Haas wrote:
> On Wed, Apr 19, 2023 at 12:54 PM Andres Freund wrote:
> > Interestingly, I haven't seen that as much in more recent benchmarks as it
> > used to. Partially I think because common s_b settings have gotten bigger, I
> >
that we should track writeback as well. I wonder if it's
worth doing so for 16? It'd give a more complete picture that way. The
counter-argument I see is that we didn't track the time for it in existing
stats either, and that nobody complained - but I suspect that's mostly because
nobody knew to look.
tions
like DIO is much more likely to cause problems, due to the drastically
different performance characteristics you get. I can see us making it
configurable to try using DIO though, but I am not convinced it's worth
bothering with that. But we'll see.
Greetings,
Andres Freund
h issues in a postmordial compiler, we'll just need
to beef up our configure test to detect that it doesn't actually fully support
specifying alignment.
Greetings,
Andres Freund
hmem allocation - which would be very hard in a
process based model - we can tell the kernel that some parts of that memory
aren't currently in use with madvise(MADV_REMOVE). It's not quite as trivial
as it sounds, because we'd have to free in multiple of huge_page_size.
Greetings,
Andres Freund
rther back?
> > Maybe the state where all the pages are new didn't happen before?
>
> Bingo: bisecting shows the failure started at
>
> commit 3d6a98457d8e21d85bed86cfd3e1d1df1b260721
> Author: Andres Freund
> Date: Wed Apr 5 08:19:39 2023 -0700
>
> Don't initi
we'll insert multiple
pages (when coming from heap_multi_insert(), with sufficient data).
Greetings,
Andres Freund
Hi,
On 2023-04-14 15:21:18 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-04-14 13:21:33 -0400, Tom Lane wrote:
> >> ... I'm not sure why only those two animals
> >> are unhappy, but I think they have a point: typical ABIs don't
> >> guarante
ith that, and disable direct IO
support if not?
Greetings,
Andres Freund
Hi,
On 2023-04-11 15:03:02 -0700, Andres Freund wrote:
> On 2023-04-11 16:54:53 -0400, Tom Lane wrote:
> > Here's something related to what I hit that time:
> >
> > diff --git a/src/backend/optimizer/plan/subselect.c
> > b/src/backend/optimizer/plan/subselect.c
>
Hi,
On 2023-04-12 08:00:00 +0300, Alexander Lakhin wrote:
> 12.04.2023 02:21, Andres Freund wrote:
> > Hi,
> >
> > On 2023-04-11 22:00:00 +0300, Alexander Lakhin wrote:
> > > A few days later I've found a new defect introduced with 31966b151.
> > That's the sa
n't make a whole lot of sense. How about:
* If rel is not NULL the horizon may be considerably more recent (i.e.
* allowing more tuples to be removed) than otherwise. In the NULL case a
* horizon that is correct (but not optimal) for all relations will be
* returned. Thus, if possible, a relation should be provided.
Greetings,
Andres Freund
to enable?
I think that's enabled by default in gcc these days, if supported by the
platform?
TBH, I really don't see the point of this style of profiling. It doesn't
provide an accurate view of where time is spent. You're much better off using
performance counter driven profiling with perf et al.
Greetings,
Andres Freund
1 (as well as some other maybe) needs to be reverted as well.
This reminds me: Is there a chance you could help out trying to make sepgsql
get tested as part of CI?
Currently CI uses only Debian for linux - can sepgsql be made work on that?
Greetings,
Andres Freund
[1] https://postgr.es/m
learMatch() somewhere,
but the non-parallel case isn't.
Greetings,
Andres Freund
ngs,
Andres Freund
>From fbe84381fa39a48f906358ade0a64e93b81c05c9 Mon Sep 17 00:00:00 2001
From: Andres Freund
Date: Tue, 11 Apr 2023 16:04:44 -0700
Subject: [PATCH v1] WIP: Fix ExtendBufferedRelTo() assert failure in recovery
+ tests
Reported-by: Alexander Lakhin
Reported-by: Tom Lane
Discussion:
484187c1356416
Currently src/tools/msvc does build successfully, although the tests haven't
finished yet:
https://cirrus-ci.com/build/6298699714789376
(the cause for the opensuse failure is known, need to find cycles to tackle
that, not related to meson)
Greetings,
Andres Freund
Hi,
On 2023-04-11 16:54:53 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-04-11 14:48:44 -0400, Tom Lane wrote:
> >> I have seen this failure a couple of times recently while
> >> testing code that caused crashes and restarts:
>
> > Do you ha
eve that this was a minor oversight. Attached patch fixes the issue.
Makes sense. Looks like there never was a flag defined for the sign bit,
luckily. I assume you're just going to apply this for HEAD?
Greetings,
Andres Freund
Hi,
On 2023-04-11 13:35:38 -0700, Andres Freund wrote:
> On 2023-04-11 14:46:23 -0500, Justin Pryzby wrote:
> > Yes, $SUBJECT is correct.
> >
> > On an old centos6 VM which I'd forgotten about and never removed from
> > monitoring, I noticed that a process had recent
ng nearly-continuously for months before that).
It possibly could be:
Author: Andres Freund
Branch: master [cb2e7ddfe] 2022-12-02 18:10:30 -0800
Branch: REL_15_STABLE Release: REL_15_2 [c6a60471a] 2022-12-02 18:07:47 -0800
Branch: REL_14_STABLE Release: REL_14_7 [6344bc097] 2022-12-02 18:10:30 -0
introduce some backoff? It's really annoying to have to trawl through all
those logs when there's a problem.
Greetings,
Andres Freund
I wonder if we should eventually redefine the RBM* things into a bitmask.
> In any case, I'm pretty sure Andres broke it in 26158b852, because
> I hadn't seen it before this weekend.
Yea, that's clearly the fault of 26158b852.
Greetings,
Andres Freund
orm. There's no debug printout or anything, python just exits with an
error code indicating an access violation.
Greetings,
Andres Freund
Hi,
On 2023-04-11 11:33:01 -0500, Justin Pryzby wrote:
> On Wed, Mar 22, 2023 at 10:00:48AM -0700, Andres Freund wrote:
> > I don't know whether others think we should apply it this release, given the
> > "late submission", but I tend to think it's not worth car
Hi,
On 2023-04-11 13:30:15 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Here's a draft docs change.
>
> > I added the in two places in install-windows.sgml so it's visible
> > on both the generated pages in the chunked output. That does mean it's
>
Hi,
On 2023-04-09 16:40:54 -0700, Noah Misch wrote:
> On Sun, Apr 09, 2023 at 02:45:16PM -0700, Andres Freund wrote:
> > It's not *just* that scenario. With a few concurrent connections you can get
> > into problematic territory even with halfway reasonable shared buffers.
>
&
s section.
> This commit, therefore, moves the options listed in the anti-features
> section into other sections and removes that section.
>
> For consistency, this reorganization has been done on the make section
> of the docs as well.
Makes sense to me. "Anti-Features" is confusing as a name to start with.
Greetings,
Andres Freund
at does mean it's visible
twice nearby in the single-page output, but I don't think that's commonly
used.
Greetings,
Andres Freund
>From 11b7229f499917fb1902ce226a31c5e2e7463390 Mon Sep 17 00:00:00 2001
From: Andres Freund
Date: Tue, 11 Apr 2023 10:05:18 -0700
Subject: [PATCH v1] docs: Bui
of anything that should
prevent building with meson with it. I am fairly sure that it can't build
tab-complete.c, but you're presumably not building with tab completion support
anyway?
Greetings,
Andres Freund
Hi,
On 2023-04-10 18:55:26 -0700, Andres Freund wrote:
> On 2023-04-10 19:27:27 +1200, Thomas Munro wrote:
> > On Mon, Apr 10, 2023 at 2:57 PM Andres Freund wrote:
> > > Have you tried to write a reproducer for this that doesn't involve
> > > postgres?
> >
&g
Hi,
On 2023-04-10 19:27:27 +1200, Thomas Munro wrote:
> On Mon, Apr 10, 2023 at 2:57 PM Andres Freund wrote:
> > Have you tried to write a reproducer for this that doesn't involve postgres?
>
> I tried a bit. I'll try harder soon.
>
> > ... What kernel version did you
Hi,
On 2023-04-10 08:14:18 +0900, Michael Paquier wrote:
> On Fri, Apr 07, 2023 at 12:01:17PM -0700, Andres Freund wrote:
> > Why would it mean that? Parallel workers are updated together with the
> > leader,
> > so there's no compatibility issue?
>
> My point is tha
we'd not have enough resources to also run that for cfbot. Once
16 forked, we then could set to run automatically in the 16 branch, as cfbot
won't run those.
Greetings,
Andres Freund
ard it'd be to switch over?
Greetings,
Andres Freund
-torture program in our tree for some
of these things. We've found issues with our assumptions on several operating
systems and filesystems, without systematically looking. Or even stressing IO
all that hard in our tests.
Greetings,
Andres Freund
Hi,
On 2023-04-08 21:29:54 -0700, Noah Misch wrote:
> On Sat, Apr 08, 2023 at 11:08:16AM -0700, Andres Freund wrote:
> > On 2023-04-07 23:04:08 -0700, Andres Freund wrote:
> > > There were some failures in CI (e.g. [1] (and perhaps also bf, didn't yet
> > > check),
Hi,
On 2023-04-04 09:03:45 -0700, Andres Freund wrote:
> For quite a while I'd been wishing to see *differential* code coverage, to see
> what changed in code coverage between two major releases. Unfortunately lcov
> didn't provide that. A few months ago a PR for it has been merged
y we copy the page to temporary memory when computing
checksums.
I think we should modify the test to enable checksums - if the problem goes
away, then it's likely to be related to modifying pages while an O_DIRECT
write is ongoing...
Greetings,
Andres Freund
Hi,
On 2023-04-08 17:31:02 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-04-08 17:10:19 -0400, Tom Lane wrote:
> > It's also odd that it's just crake having the issue. It's just a linux host,
> > afaics.
>
> Indeed. I'm guessing from the compiler vers
lly an O_DIRECT issue, or
whether it's an independent issue exposed by the new test.
I wonder if we should make the test use data checksum - if we continue to see
the wrong query results, the corruption is more likely to be in memory.
Greetings,
Andres Freund
that I know of (my eyes glaze over every time I try to reconcile the
src/tools/perl.m4 comments with the referenced comments in Mkvcbuild.pm), and
probably more small references that grep terms didn't find.
Greetings,
Andres Freund
[1] https://postgr.es/m/3598664.1680976414%40sss.pgh.pa.us
Hi,
Given the frequency of failures on this in the buildfarm, I propose using the
temporary workaround of using wal_level=replica. That avoids the use of the
over-eager log_newpage_range().
Greetings,
Andres Freund
Hi,
On 2023-04-07 23:04:08 -0700, Andres Freund wrote:
> There were some failures in CI (e.g. [1] (and perhaps also bf, didn't yet
> check), about "no unpinned buffers available". I was worried for a moment
> that this could actually be relation to the bulk extension patch
Hi,
On 2023-04-07 22:50:18 -0400, Tom Lane wrote:
> Or should credential delegation be viewed as an incremental feature that we
> can support or not?
That seems like the best way forward here.
Greetings,
Andres Freund
Hi,
On 2023-04-07 14:27:09 -0700, Andres Freund wrote:
> I think I'll push these in a few hours. While this needed more changes than
> I'd like shortly before the freeze, I think they're largely not in very
> interesting bits and pieces - and this feature has been in the works for abou
Hi,
On 2023-04-07 11:12:26 -0700, Andres Freund wrote:
> +
> +
> + confl_active_logicalslot
> bigint
> +
> +
> + Number of active logical slots in this database that have been
> + invalidated because they conflict with recovery (no
) should use
it?
Do we care about fixing this in the backbranches? Probably not, given there
haven't been user complaints?
Greetings,
Andres Freund
[1] https://cirrus-ci.com/task/4519721039560704
Hi,
On 2023-04-08 13:18:55 +1200, Thomas Munro wrote:
> If you build with --with-wal-blocksize=/-Dwal_blocksize= anything but
> 8, this breaks:
>
> running bootstrap script ... LOG: GUC (PGC_INT)
> wal_writer_flush_after, boot_val=256, C-var=128
> TRAP: failed
On 2023-04-07 22:53:53 -0400, Bruce Momjian wrote:
> On Fri, Apr 7, 2023 at 10:44:09PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Fri, Apr 7, 2023 at 09:55:00PM -0400, Tom Lane wrote:
> > >> Uh, what? Why would we not be able to tell from the remote server's
> > >> version
etail("This slot has been invalidated because it was conflicting
> with recovery.")));
>
> Won't it be better to keep the same errmsg in the above two cases?
Probably - do you have a preference? I think the former is a bit better?
Greetings,
Andres Freund
of that I changed something in the patch subject.
> On Fri, Apr 07, 2023 at 11:12:26AM -0700, Andres Freund wrote:
> > Hi,
> >
> > On 2023-04-07 08:47:57 -0700, Andres Freund wrote:
> > > Integrated all of these.
> >
> > From 0e038eb5dfddec500fbf4625775d1fa
ld versions, using :encoding(UTF-8) seems
sensible?
Greetings,
Andres Freund
1101 - 1200 of 8966 matches
Mail list logo
