that well.
lotsadisk, lotsacpu? :)
Greetings,
Andres Freund
rtunately is pretty
easy to break, so I'd be hesitant.
I guess we could stop running the full regression tests in 002_pg_upgrade.pl
if !large?
Greetings,
Andres Freund
nse?
Greetings,
Andres Freund
[1]
https://www.postgresql.org/message-id/20221029025420.eplyow6k7tgu6he3%40awork3.anarazel.de
hance to invoke
> update_progress(), the timeout can happen if there are a lot of such
> messages.
ISTM that the likelihood of causing harm due to increased overhead is higher
than the gain.
Greetings,
Andres Freund
Hi,
On 2023-02-13 08:22:34 +0530, Amit Kapila wrote:
> On Sat, Feb 11, 2023 at 3:04 AM Andres Freund wrote:
> >
> > > One difference I see with the patch is that I think we will end up
> > > sending keepalive for empty prepared transactions even though we don't
>
Hi,
On 2023-02-13 12:52:23 -0500, Tom Lane wrote:
> Andres Freund writes:
> > E.g. I fire of a query, it's slower than I'd like, I want to attach perf. Of
> > course I can establish a separate connection, query pg_stat_activity there,
> > and then perf. But that requir
ic verification of pg_stat_statements
output being sane after running the test? Even if that's perhaps just actually
printing the statements.
Greetings,
Andres Freund
in a query
> and can use pg_backend_pid(). What do you need the backend PID for outside
> of such a query?
E.g. I fire of a query, it's slower than I'd like, I want to attach perf. Of
course I can establish a separate connection, query pg_stat_activity there,
and then perf. But that requires manually filtering pg_stat_activity to find
the query.
Greetings,
Andres Freund
On 2023-02-13 18:33:34 +0900, Kyotaro Horiguchi wrote:
> At Mon, 13 Feb 2023 10:15:03 +0530, Bharath Rupireddy
> wrote in
> > On Sun, Feb 12, 2023 at 11:01 PM Andres Freund wrote:
> > >
> > > On 2023-02-12 19:59:00 +0530, Bharath Rupireddy wrote:
> > >
Hi,
On 2023-02-11 05:44:47 +, Takamichi Osumi (Fujitsu) wrote:
> On Saturday, February 11, 2023 11:10 AM Andres Freund
> wrote:
> > Has there been any discussion about whether this is actually best
> > implemented on the client side? You could alternatively implement it
cur_key->sk_collation,
> - atp,
> cur_key->sk_argument);
> + if (!isnull && (cur_key->sk_flags & SK_SEARCHNULL))
> + return false;
Shouldn't need to extract the column if we just want to know if it's NULL (see
heap_attisnull()). Afaics the value isn't accessed after this.
Greetings,
Andres Freund
don't need them, or, even better, initialize the array as a constant, once.
Greetings,
Andres Freund
about portability.
> (I left out the 0004 declaration-formatting patch for now, btw.)
Makes sense.
Greetings,
Andres Freund
ata, 0, zbuffer_sz);
I previously commented on this - why are we memseting a buffer on every call
to this? That's not at all free.
Something like
static const PGAlignedBlock zerobuf = {0};
would do the trick. You do need to cast the const away, to assign to
iov_base, but that's not too ugly.
Greetings,
Andres Freund
Hi,
On 2023-02-11 14:25:06 -0800, Andres Freund wrote:
> On 2023-01-20 13:40:55 +1300, David Rowley wrote:
> > v2-0004:
> >
> > 5. Is it worth having two versions of PinLocalBuffer() one to adjust
> > the usage count and one that does not? Couldn't the version that do
Hi,
On 2023-01-20 13:40:55 +1300, David Rowley wrote:
> On Tue, 10 Jan 2023 at 15:08, Andres Freund wrote:
> > Thanks for letting me now. Updated version attached.
>
> I'm not too sure I've qualified for giving a meaningful design review
> here, but I have started looking at
arately? If you prefer, I'm ok with adding a patch to this series instead,
though.
Greetings,
Andres Freund
On 2023-02-11 13:36:51 -0800, Andres Freund wrote:
> Even though it's not a correctness issue, it seems to me that
> DropRelationsAllBuffers() etc ought to check if the buffer is BM_TAG_VALID,
> before doing anything further. Particularly in DropRelationsAllBuffers(), the
> check we
ere would be an efficiency issue though, because when
encountering an invalid buffer, we'd unnecessarily enter InvalidateBuffer(),
which'd find that BM_[TAG_]VALID isn't set, and not to anything.
Even though it's not a correctness issue, it seems to me that
DropRelationsAllBuffers() etc ought to check if the buffer is BM_TAG_VALID,
before doing anything further. Particularly in DropRelationsAllBuffers(), the
check we do for each buffer isn't cheap. Doing it for buffers that don't even
have a tag seems .. not smart.
Greetings,
Andres Freund
On 2023-02-04 15:35:58 -0500, Corey Huinker wrote:
> This effectively makes the %p prompt (which I use in the example above) the
> same as %:BACKEND_PID: and we may want to note that in the documentation.
I don't really see much of a point in noting this in the doc. I don't know in
what
t we have %p is a minor precedent of psql special casing
backend pid in psql.
Greetings,
Andres Freund
is quite limited, the pre-check before copying the tuple will prevent this
from occurring too often, the copy will result in higher locality, and, most
importantly, the reduced palloc() overhead (~25% or so with aset.c) will
result in a considerably higher cache hit ratio / lower memory usage.
Greetings,
Andres Freund
Can anybody think of a good way out of that? It's not like that problem is
going to go away at some point...
Greetings,
Andres Freund
Hi,
On 2023-02-08 21:03:19 -0800, Andres Freund wrote:
> Pushed the first (and biggest) commit. More tomorrow.
Just pushed the actual pg_stat_io view, the splitting of the tablespace test,
and the pg_stat_io tests.
Yay!
Thanks all for patch and review!
> Already can't wait to see incre
t; pá 10. 2. 2023 v 21:18 odesílatel Andres Freund
> > > > napsal:
> > > > > On 2023-02-10 21:09:06 +0100, Pavel Stehule wrote:
> > > > > > Just a small note - I executed VACUUM ANALYZE on one customer's
> > > > > > database,
&
on't add
authorship notes in relevant sections of the documentation.
Greetings,
Andres Freund
ternatively implement it on the sender.
That'd have quite a few advantages, I think - you e.g. wouldn't remove the
ability to *receive* and send feedback messages. We'd not end up filling up
the network buffer with data that we'll not process anytime soon.
Greetings,
Andres Freund
7483647 == 1)
> ? 1 : -1];
This stuff shouldn't be in here, it's due to a debian patched autoconf.
Greetings,
Andres Freund
, anyway.
Still not sure what version we'd best use for now. Perhaps v8?
Greetings,
Andres Freund
gt; result = 0;
> else
> + {
> result = (int64) (tabentry->t_counts.t_numscans);
> + pfree(tabentry);
> + }
>
> PG_RETURN_INT64(result);
> }
I don't think we need to bother with individual pfrees in this path. The
caller will call the function in a dedicated memory context, that'll be reset
very soon after this.
Greetings,
Andres Freund
for a xact is already sent and then use that information
> for commit prepared but again that also didn't sound like a good idea.
I don't think it's worth optimizing this. However, the explanation for why
we're not skipping empty prepared xacts needs to be added to
pgoutput_prepare_txn() etc.
Greetings,
Andres Freund
:33 AM Andres Freund wrote:
> > Attached is a current, quite rough, prototype. It addresses some of the
> > points
> > raised, but far from all. There's also several XXXs/FIXMEs in it. I changed
> > the file-ending to .txt to avoid hijacking the CF entry.
> >
>
ably not too big. This database is a little bit
> unusual. This one database has more than 1 800 000 tables. and the same
> number of indexes.
If you have 1.8 million tables in a single database, what you saw might just
have been the size of the relation and catalog caches.
Greetings,
Andres Freund
: Andres Freund
References:
<20230210.113242.699878230551547182.horikyota@gmail.com>
<5420b28c-d33f-d25d-9f47-b06b8a237...@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5420b28c-d33f-d25d-9f47-b06b8a237...
e dictionary. As we need that field anyway, we
can easily have multiple dictionaries.
Greetings,
Andres Freund
Hi,
On February 9, 2023 8:45:20 PM PST, Tom Lane wrote:
>Andres Freund writes:
>> The only not sufficient ones that bother me to some degree are Ubuntu 20.04
>> and RHEL 8. The issues are different, oddly enough. Ubuntu has a new enough
>> ninja, but meson is too old, RHEL
Hi,
On 2023-02-05 16:52:07 -0800, Andres Freund wrote:
> I did survey available meson versions, and chose what features to
> use. But not really ninja, since I didn't know about this specific issue
> and other than this the ninja version differences were handled by meson.
RHEL world co
Hi,
On 2023-02-09 17:00:48 -0800, Peter Geoghegan wrote:
> On Thu, Feb 9, 2023 at 4:33 PM Andres Freund wrote:
> > I e.g. have a not-quite-done patch that creates a "template initdb", which
> > pg_regress and tap tests automatically use (except if non-default opti
Hi,
On 2023-02-09 19:00:00 +0530, Bharath Rupireddy wrote:
> On Thu, Feb 9, 2023 at 12:33 PM Andres Freund wrote:
> > On 2023-02-09 12:21:51 +0530, Bharath Rupireddy wrote:
> > > @@ -1105,18 +1105,22 @@ CREATE VIEW pg_stat_archiver AS
> > >
> >
On 2023-02-09 19:20:37 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I'm fine either way. It's barely noticeable compared to the rest of
> > postgres.
>
> Yeah, build-by-default isn't really a big deal. Install-by-default
> is more of a problem...
Perhaps we
the
tmp_install directory :)). I guess that'd still be less confusing?
I'm not at all wedded to the "setup" name.
Greetings,
Andres Freund
* approximate test time improvements:
local:
688.67user 154.44system 1:08.29elapsed 1234%CPU (0avgtext+0avgdata
138984maxresident)k
->
Hi,
On 2023-02-09 18:19:06 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-02-09 17:19:22 -0500, Tom Lane wrote:
> >> Hmmm .. a shell script would be fine by me, but it won't help in
> >> testing a Windows build. Maybe we need to make it a Perl script?
Hi,
On 2023-02-09 17:19:22 -0500, Tom Lane wrote:
> Andres Freund writes:
> > The trivial fix of using MAXPGPATH made it build, without warnings. That
> > doesn't say anything about actually working. So I guess porting the test
> > would
> > make sense.
>
> &g
Hi,
On 2023-02-09 13:55:32 -0800, Andres Freund wrote:
> ../src/tools/pg_bsd_indent/args.c(179): error C2065: 'PATH_MAX': undeclared
> identifier
> ../src/tools/pg_bsd_indent/args.c(179): error C2057: expected constant
> expression
> ../src/tools/pg_bsd_indent/args.c(179): erro
e platform they're not interruptible. Most of the
things changed here are debugging tools, but even so, it's e.g. pretty
annoying. E.g. you can't normally shut down while a backend is in
pre_auth_delay.
So I'm not sure it's the right direction to make pg_usleep() easier to use...
Greetings,
Andres Freund
that creates? If it's not super-widespread, it might be
ok to do that earlier. I wouldn't mind not seeing that uglyness every time I
run pgindent on a patch... Although I guess post-March-CF isn't that far away
at this point :)
Greetings,
Andres Freund
basic tests. It'd not take a whole lot to make that work:
- a search path for finding extensions, which'd be very useful for other
reasons as well
- a way to tell 'postgres', 'initdb' etc, which use find_other_exec(), that
they should use PATH
- a way to tell initdb where to find things li
Hi,
On 2023-02-09 13:48:46 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I think this misunderstanding is again due to the confusion between the
> > 'all'
> > target in doc/src/sgml and the default target, just like earlier in the
> > thread
> > /
har *path);
> these situations.
>
>
> -typedef void (*ArchiveShutdownCB) (void);
> +typedef void (*ArchiveShutdownCB) (ArchiveModuleState *state);
>
>
>
Perhaps mention that this needs to free state it allocated in the
ArchiveModuleState, or it'll be leaked?
Greetings,
Andres Freund
one...
If we had a 'restorer' process, startup fed some sort of a queue with things
to restore in the near future, it might be more realistic to do something you
describe?
Greetings,
Andres Freund
ll autocompletions for ninja work pretty well for me, a prefix like
that would make it easier to discover such "sub"-targets.
I'm was pondering adding a 'help' target that shows important targets.
Greetings,
Andres Freund
Hi,
On February 9, 2023 2:50:57 AM PST, Aleksander Alekseev
wrote:
>Hi Andres,
>
>> > So to clarify, are we talking about tuple-level compression? Or
>> > perhaps page-level compression?
>>
>> Tuple level.
>
>> although my own patch proposed attribute-level compression, not
>> tuple-level one,
orking, isn't
sufficient to consider something suspicious OK.
And changes affecting heapam.c visibility semantics need extremely careful
review, I have the battle scars to prove that to be true :P.
Greetings,
Andres Freund
d() AS buffers_written_backend,
> +pg_stat_get_buf_fsync_backend() AS buffers_fsync_backend,
> +pg_stat_get_checkpointer_stat_reset_time() AS stats_reset;
> +
I don't think the backend written stats belong more accurately in
pg_stat_checkpointer than pg_stat_bgwriter.
I continue to be worried about breaking just about any postgres monitoring
setup.
Greetings,
Andres Freund
On 2023-02-08 10:55:44 -0800, Nathan Bossart wrote:
> done
Pushed. Thanks!
).
My next step is to survey ninja versions across OSs / versions.
Greetings,
Andres Freund
Hi,
On 2023-02-07 22:38:14 -0800, Andres Freund wrote:
> I did another read through the series. I do have some minor changes, but
> they're minor. I think this is ready for commit. I plan to start pushing
> tomorrow.
Pushed the first (and biggest) commit. More tomorrow.
Already c
Hi,
On 2023-02-08 18:37:41 -0800, Peter Geoghegan wrote:
> On Wed, Feb 8, 2023 at 4:29 PM Andres Freund wrote:
> > 2) Add a message to lazy_vacuum() or lazy_vacuum_all_indexes(), that
> > includes
> >- num_index_scans
> >- how many indexes we'll scan
> &
On 2023-02-08 12:16:46 -0800, Jeff Davis wrote:
> On Thu, 2023-02-02 at 18:10 -0500, Tom Lane wrote:
> > Yeah. I would be resistant to making ICU a required dependency,
> > but it doesn't seem unreasonable to start moving towards it being
> > our default collation support.
>
> Patch attached.
Hi,
On 2023-02-08 14:03:49 -0800, Peter Geoghegan wrote:
> On Tue, Feb 7, 2023 at 6:47 PM Andres Freund wrote:
> > One thing I'm not quite sure what to do about is that we atm use a hardcoded
> > DEBUG2 (not controlled by VERBOSE) in a bunch of places:
> >
>
Hi,
On 2023-02-08 14:11:45 -0800, Andres Freund wrote:
> On 2023-02-07 17:10:21 -0800, Andres Freund wrote:
> I don't really understand how GetSafeSnapshotBlockingPids() can end up finding
> deadlock-hard's sessions being blocked by a safe snapshot. Afaict nothing uses
> serializable
Hi,
On 2023-02-07 17:10:21 -0800, Andres Freund wrote:
> diff -U3 /tmp/cirrus-ci-build/src/test/isolation/expected/deadlock-hard.out
> /tmp/cirrus-ci-build/build/testrun/isolation-running/isolation/results/deadlock-hard.out
> --- /tmp/cirrus-ci-build/src/test/isolation/expected/deadlock
> SLRUs, which would no longer apply. I’ve attached another patch that removes
> these tests.
I think you'd need to fix those tests, rather than just removing them.
I suspect we're going to continue to want SLRU specific stats, but your patch
also seems to remove those.
Greetings,
Andres Freund
Hi,
On 2023-02-08 10:30:37 -0800, Andres Freund wrote:
> On 2023-02-08 10:18:41 -0800, Andres Freund wrote:
> > I don't think the syncrep logic in WalSndUpdateProgress really works as-is -
> > consider what happens if e.g. the origin filter filters out entire
> > transaction
Hi,
On 2023-02-08 10:18:41 -0800, Andres Freund wrote:
> I don't think the syncrep logic in WalSndUpdateProgress really works as-is -
> consider what happens if e.g. the origin filter filters out entire
> transactions. We'll afaics never get to WalSndUpdateProgress(). In some case
Hi,
On 2023-02-08 09:57:56 -0800, Nathan Bossart wrote:
> On Wed, Feb 08, 2023 at 09:33:44AM -0800, Andres Freund wrote:
> > And yes, I'd be for a patch to remove all of those assertions.
>
> done
If you'd reorder it so that 0004 applies independently from the other changes
Hi,
On 2023-02-08 13:36:02 +0530, Amit Kapila wrote:
> On Wed, Feb 8, 2023 at 10:57 AM Andres Freund wrote:
> >
> > On 2023-02-03 10:13:54 +0530, Amit Kapila wrote:
> > > I am planning to push this to HEAD sometime next week (by Wednesday).
> > > To backpatch th
Hi,
On 2023-02-08 09:27:05 -0800, Nathan Bossart wrote:
> On Wed, Feb 08, 2023 at 08:27:13AM -0800, Andres Freund wrote:
> > One minor thing: I don't think we really need the AssertVariableIsOfType()
> > for
> > anything but the Init() one?
>
> This is another
it may not address all the points you may have in mind.
Yes, I think this looks pretty good now.
One minor thing: I don't think we really need the AssertVariableIsOfType() for
anything but the Init() one?
Greetings,
Andres Freund
ay, 'uuid-library' of type 'combo'.
Or add 'auto' as a combo option, and handle the value of the auto_features
option ourselves?
Greetings,
Andres Freund
the wins are big enough to not focus on it then and
there.
Greetings,
Andres Freund
overed bugs. However the
> arguments against received so far don't strike me personally as being
> particularly convincing.
I've said my piece, as-is I vote to reject the patch.
Greetings,
Andres Freund
Hi,
On 2023-02-07 17:10:21 -0800, Andres Freund wrote:
> So far the diff always is:
>
> diff -U3 /tmp/cirrus-ci-build/src/test/isolation/expected/deadlock-hard.out
> /tmp/cirrus-ci-build/build/testrun/isolation-running/isolation/results/deadlock-hard.out
> --- /tmp/cirrus-ci
tat_statements on a standby.
Greetings,
Andres Freund
the tablespace changes to later in the series
- split the tests out of the commit adding the view into its own commit
- minor code formatting things (e.g. didn't like nested for()s without {})
On 2023-01-25 16:56:17 +0900, Kyotaro Horiguchi wrote:
> At Tue, 24 Jan 2023 14:35:12 -0800, Andres Freund wr
On 2023-02-08 13:12:15 +0900, Michael Paquier wrote:
> On Thu, Feb 02, 2023 at 11:14:39AM +0900, Michael Paquier wrote:
> > Actually, I completely forgot to take into account that there is a
> > minor release planned for next week:
> > https://www.postgresql.org/developer/roadmap/
> >
> > So I'll
we processing? What are we actually waiting
for - because we don't actually wait for the data to sent out or anything,
just that they're in a network buffer.
Greetings,
Andres Freund
Hi,
On 2023-02-06 17:53:00 -0800, Andres Freund wrote:
> Another run hit an issue we've been fighting repeatedly on the buildfarm / CI:
> https://cirrus-ci.com/task/5527490404286464
> https://api.cirrus-ci.com/v1/artifact/task/5527490404286464/testrun/build/testrun/regress-runnin
502
2023-02-08 00:53:27.614 GMT startup[5800] LOG: invalid record length at
0/25353E8: wanted 24, got 0
2023-02-08 00:53:27.614 GMT startup[5800] LOG: redo done at 0/2534FE0 system
usage: CPU: user: 0.04 s, system: 0.04 s, elapsed: 0.15 s
Nevertheless, clearly this should never be reached.
Greetings,
Andres Freund
it 741d7f1047f fixed a similar issue in deadlock-hard. But it looks like
we need something more. But perhaps this isn't an output ordering issue:
How can we end up with s5c getting reported as waiting? I don't see how s5c
could end up blocking on anything?
Greetings,
Andres Freund
Hi,
On 2022-11-16 08:58:31 +, wangw.f...@fujitsu.com wrote:
> Attach the new patch set.
This patch causes several of the tests to fail. See e.g.:
https://cirrus-ci.com/task/6587624765259776
Most of the failures appear to be due to the main regression tests failing:
Hi,
On 2023-02-06 19:12:47 +, Bagga, Rishu wrote:
> Rebased patch as per latest community changes since last email.
This version doesn't actually build.
https://cirrus-ci.com/task/4512310190931968
[19:43:20.131] FAILED: src/test/modules/test_slru/test_slru.so.p/test_slru.c.o
Hi,
On 2023-02-05 10:36:39 -0800, Andrey Borodin wrote:
> On Fri, Jan 6, 2023 at 10:02 PM Andrey Borodin wrote:
> >
> > Hello! Please find attached v8.
>
> I got some interesting feedback from some patch users.
> There was an oversight that frequently yielded results that are 1,2 or
> 3 bytes
Hi,
On 2023-02-07 11:49:03 -0800, Andres Freund wrote:
> On 2023-02-01 11:23:57 +0530, Amit Kapila wrote:
> > On Tue, Jan 31, 2023 at 6:08 PM Masahiko Sawada
> > wrote:
> > >
> > > Attached updated patches.
> > >
> >
> > Thanks, Andres,
ues,
but that's possible with the proposed patch as well, as effective_xmin is
updated without any of the other locks. But I don't see a problem with that.
Greetings,
Andres Freund
nvisible row in part of the ctid chain.
>
> That's a reasonable concern, however I was unable to break unique
> constraints or triggers so far:
I think you'd have to do a careful analysis of a lot of code for that to hold
any water.
I continue to think that we should just reject this behavioural change.
Greetings,
Andres Freund
re currently starting multiple threads with questions a week. Could you at
least keep them in one thread?
Greetings,
Andres Freund
ement over master with TIMING ON vs TIMING OFF, when
> using the test-case from Andres' e-mail that started this thread.
>
> I hope I'll find time to work on these points during the next days.
This fails to build on several platforms:
https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest%2F42%2F3751
Greetings,
Andres Freund
ry() while testing and some
> comments.
The tests seem to frequently hang on freebsd:
https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest%2F42%2F3478
Greetings,
Andres Freund
would like to get this LockReleaseAll problem finally fixed in PG16,
> but I'd feel much better about this patch if it had some review from
> someone who has more in-depth knowledge of the locking code.
I feel my review wouldn't be independent, but I'll give it a shot if nobody
else does.
Greetings,
Andres Freund
Hi,
On 2023-02-07 09:00:13 +0530, Amit Kapila wrote:
> On Tue, Feb 7, 2023 at 2:04 AM Andres Freund wrote:
> > How about we make it an option in START_REPLICATION? Delayed logical rep can
> > toggle that on by default.
> Works for me. So, when this option is set in START_REP
Hi,
On 2023-02-06 19:29:46 -0800, Andres Freund wrote:
> There's something off. Isolationtester's control connection emits *loads* of
> invalidation messages:
> 2023-02-06 19:29:06.430 PST [2125297][client
> backend][6/0:121864][isolation/receipt-report/control connection] LOG:
Hi,
On 2023-02-06 17:53:00 -0800, Andres Freund wrote:
> WRT the fdw_retry_check: I wonder if we should increase the log level of
> a) pgfdw_inval_callback deciding to disconnect
> b) ReceiveSharedInvalidMessages() deciding to reset
>
> to DEBUG1, at least temporarily?
>
> A
Hi,
On 2022-12-08 16:36:07 -0800, Andres Freund wrote:
> On 2022-12-08 16:15:11 -0800, Andres Freund wrote:
> > Unfortunately cfbot shows that that doesn't work entirely reliably.
> >
> > The most frequent case is postgres_fdw, which somewhat regularly fails with
> >
On 2023-02-06 14:14:22 -0800, Andres Freund wrote:
> On 2023-02-07 11:03:18 +1300, Thomas Munro wrote:
> > What I see is that there were 1254 FreeBSD tasks run in that window, of
> > which 163 failed, and (more interestingly) 111 of those failures succeeded
> > on
Hi,
On 2023-02-05 15:30:57 -0800, Andres Freund wrote:
> Hm, I suspect the problem is that we didn't shut down the server due to
> the error, so the log file was changing while cirrus was trying to
> upload.
Pushed a fix for that.
Greetings,
Andres Freund
Hi,
On 2023-02-07 11:03:18 +1300, Thomas Munro wrote:
> On Tue, Feb 7, 2023 at 10:57 AM Andres Freund wrote:
> > On February 6, 2023 1:51:20 PM PST, Thomas Munro
> > wrote:
> > >Next up: the new "running" tests, spuriously failing around 8.8% of CI
> &g
Hi,
On February 6, 2023 1:51:20 PM PST, Thomas Munro wrote:
>Next up: the new "running" tests, spuriously failing around 8.8% of CI
>builds on FreeBSD. I'll go and ping that thread...
Is that rate unchanged? I thought I fixed the main issue last week?
Greetings,
Andres
--
Sent from my
There's really no need to
force us to do this manually.
Greetings,
Andres Freund
Hi,
On 2023-02-04 11:10:55 -0800, Peter Geoghegan wrote:
> On Sat, Feb 4, 2023 at 2:57 AM Andres Freund wrote:
> > Is there a good way to make breakage in the page recycling mechanism
> > visible with gist? I guess to see corruption, I'd have to halt a scan
> > before a pag
1501 - 1600 of 8924 matches
Mail list logo
