On Fri, Feb 16, 2024 at 5:53 PM vignesh C wrote:
>
>
> After the insert operation is replicated to the subscriber, the
> subscriber will set the lsn value sent by the publisher in the
> replication origin (in my case it was 0/1510978). publisher will then
> send keepalive messages with the current
On Fri, Feb 16, 2024 at 8:17 PM torikoshia wrote:
>
> I may be wrong since I seldom do data loading tasks, but I greed with
> you.
>
> I also a little concerned about the case where there are many malformed
> data and it causes lots of messages, but the information is usually
> valuable and if use
On Sat, Feb 17, 2024 at 10:05 AM vignesh C wrote:
>
> On Fri, 16 Feb 2024 at 10:50, Hayato Kuroda (Fujitsu)
> wrote:
>
> Thanks for the updated patch, Few suggestions:
> 1) This can be moved to keep it similar to other tests:
> +# Setup a disabled subscription. The upcoming test will check the
>
On Fri, Feb 16, 2024 at 11:01 PM Jeff Davis wrote:
>
> > Here, I'm with v23 patch set:
>
> Thank you, I'll look at these.
Thanks. Here's the v24 patch set after rebasing.
--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
From
On Fri, Feb 16, 2024 at 4:10 PM shveta malik wrote:
>
> On Thu, Feb 15, 2024 at 10:48 PM Bertrand Drouvot
> wrote:
>
> > 5 ===
> >
> > + if (SlotSyncWorker->syncing)
> > {
> > - SpinLockRelease(&SlotSyncCtx->mutex);
> > + SpinLockRelease(&SlotSyncWorker->
On Fri, 16 Feb 2024 at 10:50, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Vignesh,
>
> Thanks for reviewing! PSA new version.
>
> >
> > Thanks for the updated patch, few suggestions:
> > 1) Can we use a new publication for this subscription too so that the
> > publication and subscription naming will
Tomas Vondra writes:
> On 2/17/24 00:14, Tom Lane wrote:
>> The conclusion was that the specific invalid values didn't matter as
>> much on the other platforms as they do with glibc. But right now you
>> have a fifty-fifty chance that a pointer to garbage will look valid.
>> Do we want to increas
On Sat, Feb 17, 2024 at 2:16 AM Tomas Vondra
wrote:
>
> Hi,
>
> On 1/2/24 01:00, jian he wrote:
> > On Mon, Dec 4, 2023 at 5:11 PM John Naylor wrote:
> >>
> >> On Thu, Sep 28, 2023 at 12:22 AM Alexander Korotkov
> >> wrote:
> >>> The one thing triggering my perfectionism is that the patch does t
On 2/17/24 00:14, Tom Lane wrote:
> Tomas Vondra writes:
>> Maybe I'm completely misunderstanding the implication of those limits,
>> but doesn't this mean the claim that we can support 8 memory context
>> types is not quite true, and the limit is 4, because the 4 IDs are
>> already used for ma
On Wed, 2024-02-14 at 13:02 -0600, Nathan Bossart wrote:
> This seemed like the approach folks were most in favor of at the
> developer
> meeting a couple weeks ago [0]. At least, that was my interpretation
> of
> the discussion.
Attached rebased version.
Note the changes in amcheck. It's creati
Tomas Vondra writes:
> Maybe I'm completely misunderstanding the implication of those limits,
> but doesn't this mean the claim that we can support 8 memory context
> types is not quite true, and the limit is 4, because the 4 IDs are
> already used for malloc stuff?
Well, correct code would still
On 16.02.24 21:31, David G. Johnston wrote:
> Yes. In particular not all columns in the table need be specified in
> the copy command so while the parsed input data is all nulls the
> record itself may not be.
Yeah, you have a point there.
I guess if users want to avoid it to happen they can r
On 11/6/23 19:54, Matthias van de Meent wrote:
>
> ...
>
> Tangent: Do we have specific notes on worst-case memory usage of
> memory contexts with various allocation patterns? This new bump
> allocator seems to be quite efficient, but in a worst-case allocation
> pattern it can still waste about 1/
Hi,
I wanted to take a look at this patch but it seems to need a rebase,
because of a seemingly trivial conflict in MemoryContextMethodID:
--- src/include/utils/memutils_internal.h
+++ src/include/utils/memutils_internal.h
@@ -123,12 +140,13 @@ typedef enum MemoryContextMethodID
{
MCTX_UNUSED
Hi!
>7) -h 0.0.0.0 - As you mentioned, this is one of the cases where host
>and "server address" differ.
> I am not sure if it is an issue. Perhaps the other reviewers might
>have an opinion on it
>$ /usr/local/postgres-dev/bin/psql -x -U postgres -h 0.0.0.0 -c
>"\conninfo+" -c "\conninfo"
>Cur
"David G. Johnston" writes:
> Per the recent bug report, we should probably add something like (ignored)
> after the 50 connections for role1 since they are not allowed to login so
> the value is indeed ignored. It is ignored to zero as opposed to unlimited
> for the Superuser so maybe a differen
On Mon, Feb 12, 2024 at 2:29 PM Pavel Luzanov
wrote:
> regress_du_role1 | no| Inherit | no| 2024-12-31
> 00:00:00+03(invalid) | 50 | Group role without password but
> with valid until
> regress_du_role2 | yes | Inherit | yes |
On 2024-02-16 21:56:25 +0100, Magnus Hagander wrote:
> On Fri, Feb 16, 2024 at 9:51 PM Andres Freund wrote:
> > I only skimmed the patch, but it sure looks to me that we could end up with
> > none of the branches setting 31,32, so I think you'd have to make sure to
> > handle that case.
>
> That
On Fri, Feb 16, 2024 at 9:51 PM Andres Freund wrote:
>
> Hi,
>
> On 2024-02-16 21:41:41 +0100, Magnus Hagander wrote:
> > > Maybe I am missing something, but why aren't we just getting the value
> > > from
> > > the leader's entry, instead of copying it?
> >
> > The answer to that would be "becau
On Mon, 2024-02-12 at 17:44 -0800, Jeff Davis wrote:
> It looks like there's some renewed interest in this patch:
After rebasing (attached as 0001), I'm seeing some test failures. It
looks like the local LogwrtResult is not being updated in as many
places, and that's hitting the Assert that I rece
Hi,
On 2024-02-16 21:41:41 +0100, Magnus Hagander wrote:
> > Maybe I am missing something, but why aren't we just getting the value from
> > the leader's entry, instead of copying it?
>
> The answer to that would be "because I didn't think of it" :)
:)
> Were you thinking of something like the
Hi,
On 2024-02-16 15:22:16 -0500, Tom Lane wrote:
> Magnus Hagander writes:
> > I mean, we could split it into more than one view. But adding a new
> > view for every new thing we want to show is also not very good from
> > either a usability or performance perspective. So where would we put
> >
On Fri, Feb 16, 2024 at 8:55 PM Andres Freund wrote:
>
> Hi,
>
> On 2024-01-12 17:16:53 +0100, Magnus Hagander wrote:
> > On Thu, Jan 11, 2024 at 5:55 PM Bertrand Drouvot
> > wrote:
> > > On Thu, Jan 11, 2024 at 02:24:58PM +0100, Magnus Hagander wrote:
> > > > On Wed, Jan 10, 2024 at 3:12 PM Bert
Hi,
I took a look at this today, to try to understand the purpose and how it
works. Let me share some initial thoughts and questions I have. Some of
this may be wrong/missing the point, so apologies for that.
The goal seems worthwhile in general - the way I understand it, the
patch aims to provid
On Fri, Feb 16, 2024 at 5:29 PM Robert Haas wrote:
> 3. Reserve lots of address space and then only use some of it. I hear
> rumors that some forks of PG have implemented something like this. The
> idea is that you convince the OS to give you a whole bunch of address
> space, but you try to avoid
On 1/15/24 02:37, Peter Eisentraut wrote:
In this updated patch set, I have also added the treatment of the Constraint type. (I also noted
that the manual read/write functions for the Constraint type are out-of-sync again, so simplifying
this would be really helpful.) I have also added commit
On Fri, Feb 16, 2024 at 1:16 PM Jim Jones wrote:
> In case all columns of a record have been set to null due to data type
> incompatibility, should we insert it at all?
Yes. In particular not all columns in the table need be specified in the
copy command so while the parsed input data is all n
On Fri, Feb 16, 2024 at 9:20 PM Andres Freund wrote:
>
> Hi,
>
> On 2024-02-16 20:57:59 +0100, Magnus Hagander wrote:
> > On Fri, Feb 16, 2024 at 8:41 PM Andres Freund wrote:
> > > On 2024-01-10 12:46:34 +0100, Magnus Hagander wrote:
> > > > The attached patch adds a column "authuser" to pg_stat_
>> I have found it very strange that a tool like doxygen which can create
>> all sorts of call graphs, just ignores some comments. The comments
>> above function are very important.
I agree with you . I hated doxygen for decades because of the irritating
annotations it required. When I discover
On 16/02/2024 06:28, Robert Haas wrote:
3. Reserve lots of address space and then only use some of it. I hear
rumors that some forks of PG have implemented something like this. The
idea is that you convince the OS to give you a whole bunch of address
space, but you try to avoid having all of it b
Magnus Hagander writes:
> I mean, we could split it into more than one view. But adding a new
> view for every new thing we want to show is also not very good from
> either a usability or performance perspective. So where would we put
> it?
It'd have to be a new view with a row per session, show
Hi,
On 2024-02-16 20:57:59 +0100, Magnus Hagander wrote:
> On Fri, Feb 16, 2024 at 8:41 PM Andres Freund wrote:
> > On 2024-01-10 12:46:34 +0100, Magnus Hagander wrote:
> > > The attached patch adds a column "authuser" to pg_stat_activity which
> > > contains the username of the externally authen
Hi!
On 12.02.24 01:00, jian he wrote:
> attached v2.
> syntax: `on_error set_to_null`
> based on upthread discussion, now if you specified `on_error
> set_to_null` and your column has `not
> null` constraint, we convert the error field to null, so it may error
> while bulk inserting for violating
On Fri, Feb 16, 2024 at 12:50 PM Tomas Vondra
wrote:
>
> Hello Gabriele,
>
> I think the improvement makes sense (it's indeed a bit strange to not
> partition the history table), and the patch looks good.
>
> I did think about whether this should be optional in some way - that is,
> separate from
On Fri, Feb 16, 2024 at 01:45:52PM +0100, Mats Kindahl wrote:
> Looks good to me.
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Feb 16, 2024 at 8:41 PM Andres Freund wrote:
>
> Hi,
>
> On 2024-01-10 12:46:34 +0100, Magnus Hagander wrote:
> > The attached patch adds a column "authuser" to pg_stat_activity which
> > contains the username of the externally authenticated user, being the
> > same value as the SYSTEM_USE
Hi,
On 2024-01-12 17:16:53 +0100, Magnus Hagander wrote:
> On Thu, Jan 11, 2024 at 5:55 PM Bertrand Drouvot
> wrote:
> > On Thu, Jan 11, 2024 at 02:24:58PM +0100, Magnus Hagander wrote:
> > > On Wed, Jan 10, 2024 at 3:12 PM Bertrand Drouvot
> > > wrote:
> > > >
> > > > If we go the 2 fields way,
Hi,
On 2024-01-10 12:46:34 +0100, Magnus Hagander wrote:
> The attached patch adds a column "authuser" to pg_stat_activity which
> contains the username of the externally authenticated user, being the
> same value as the SYSTEM_USER keyword returns in a backend.
I continue to think that it's a ba
On Fri, Jan 19, 2024 at 1:43 PM Julien Rouhaud wrote:
>
> Hi,
>
> On Thu, Jan 18, 2024 at 11:01 PM Magnus Hagander wrote:
> >
> > I did. Here it is, and also including that suggested docs fix as well
> > as a rebase on current master.
>
> +if (MyClientConnectionInfo.authn_id)
> +strlc
I wrote:
> So now I'm thinking that we do have enough detail in the present
> proposal, and we just need to think about whether there's some
> nicer way to present it than the particular spelling I used here.
Here's a rebase over 9f1337639 --- no code changes, but this affects
some of the new or c
On Fri, Jan 19, 2024 at 12:33 PM Aleksander Alekseev
wrote:
>
> Hi,
>
> > > Did you forget to share the new revision (aka v4)? I can only see the
> > > "reorder_parallel_worker_bestart.patch" attached.
> >
> > I did. Here it is, and also including that suggested docs fix as well
> > as a rebase on
Hi,
On 2024-02-16 15:53:11 +0100, Peter Eisentraut wrote:
> The patch is quite fragile, and treading outside the tested paths will
> likely lead to grave misbehavior. Use with caution. But I feel that
> the general structure is ok, and we just need to fill in the
> proverbial few thousand lines
On Fri, Jan 19, 2024 at 7:20 AM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Thu, Jan 18, 2024 at 04:01:33PM +0100, Magnus Hagander wrote:
> > On Mon, Jan 15, 2024 at 11:17 AM Bertrand Drouvot
> > > Did you forget to share the new revision (aka v4)? I can only see the
> > > "reorder_parallel_worker_best
Hi,
On 2024-02-16 09:58:43 +0530, Robert Haas wrote:
> I remember Magnus making a comment many years ago to the effect that
> every setting that is PGC_POSTMASTER is a bug, but some of those bugs
> are very difficult to fix. Perhaps the use of the word bug is
> arguable, but I think the sentiment
I wrote:
> I find it surprising that the committed patch does not touch
> pg_dump. Is it really true that pg_dump dumps situations with
> differing compression/storage settings accurately already?
It's worse than I thought. Run "make installcheck" with
today's HEAD, then:
$ pg_dump -Fc regressi
Hi,
On 1/2/24 01:00, jian he wrote:
> On Mon, Dec 4, 2023 at 5:11 PM John Naylor wrote:
>>
>> On Thu, Sep 28, 2023 at 12:22 AM Alexander Korotkov
>> wrote:
>>> The one thing triggering my perfectionism is that the patch does two
>>> syscache lookups instead of one.
>>
>> For an admin function us
Hello Gabriele,
I think the improvement makes sense (it's indeed a bit strange to not
partition the history table), and the patch looks good.
I did think about whether this should be optional in some way - that is,
separate from partitioning the accounts table, and users would have to
explicitly
Alvaro Herrera wrote:
> This is great to hear.
>
> On 2024-Jan-31, Antonin Houska wrote:
>
> > Is your plan to work on it soon or should I try to write a draft patch? (I
> > assume this is for PG >= 18.)
>
> I don't have plans for it, so if you have resources, please go for it.
ok, I'm thinki
On Fri, 2024-02-16 at 13:08 +0530, Bharath Rupireddy wrote:
> I'd suggest we strike a balance here - error out in assert builds if
> startptr+count is past the current insert position and trust the
> callers for production builds.
It's not reasonable to have divergent behavior between assert-enabl
Thanks for your work on this. I haven't been keeping up with the
discussion, but I took a quick look at the latest patch.
+
+"Database", "Authenticated User", "System User" (only for PostgreSQL
16 or higher),
+"Current User", "Session User", "Backend PID", "Server Address
Hi,
> > In one of my environments, this feature didn't work as expected.
> > Digging into it, I found that it is incompatible with FETCH_COUNT
> > being set. Sorry for not recognising this during the betas.
> >
> > Attached a simple patch with tests running the cursor declaration
> > through PQexe
> On 16 Feb 2024, at 15:49, Peter Eisentraut wrote:
> Like, if we did a "crypt-aes", would that be FIPS-compliant? I don't know.
If I remember my FIPS correct: Only if it used a FIPS certified implementation,
like the one in OpenSSL when the fips provider has been loaded. The cipher
must be al
Peter Eisentraut writes:
> I have committed this. It is great to get this behavior fixed and also
> to get the internals more consistent. Thanks.
I find it surprising that the committed patch does not touch
pg_dump. Is it really true that pg_dump dumps situations with
differing compression/st
On 16.02.24 14:30, Daniel Gustafsson wrote:
On 16 Feb 2024, at 13:57, Peter Eisentraut wrote:
On 16.02.24 10:16, Daniel Gustafsson wrote:
2. The crypt() and gen_salt() methods built on top of them (modes of operation,
kind of) are not FIPS-compliant.
I wonder if it's worth trying to make pgc
On 2024-02-16 17:15, Bharath Rupireddy wrote:
On Wed, Feb 14, 2024 at 5:04 PM torikoshia
wrote:
[] let the users know what line numbers are
> containing the errors that COPY ignored something like [1] with a
> simple change like [2].
Agreed.
Unlike my patch, it hides the error information
On Thu, Feb 15, 2024 at 6:12 PM Robert Haas
wrote:
Hi,
I've just been catching up on this thread.
+ if (MyProc->heldLocks)
+ {
+ ereport(LOG_SERVER_ONLY,
+ errmsg("ignored request for logging query plan due to lock
conflicts"),
+ errdetail("You can try again in a moment."));
+ return;
+ }
I
On Fri, Feb 16, 2024 at 7:10 AM Kyotaro Horiguchi
wrote:
>
> Good catch! The comment seems wrong also to me. The subsequent bytes
> can be written simultaneously, and it's very normal that there are
> unflushed bytes are in OS's page buffer. The objective of the comment
> seems to be to declare th
On Thu, Feb 15, 2024 at 3:49 PM Nazir Bilal Yavuz wrote:
>
> > I'm wondering why the WALRead() callers are always reading XLOG_BLCKSZ
> > despite knowing exactly how much to read. Is it to tell the OS to
> > explicitly fetch the whole page from the disk? If yes, the OS will do
> > that anyway beca
> On 16 Feb 2024, at 13:57, Peter Eisentraut wrote:
>
> On 16.02.24 10:16, Daniel Gustafsson wrote:
>>> 2. The crypt() and gen_salt() methods built on top of them (modes of
>>> operation, kind of) are not FIPS-compliant.
>> I wonder if it's worth trying to make pgcrypto disallow non-FIPS complia
I have committed this. It is great to get this behavior fixed and also
to get the internals more consistent. Thanks.
On 16.02.24 10:16, Daniel Gustafsson wrote:
2. The crypt() and gen_salt() methods built on top of them (modes of operation,
kind of) are not FIPS-compliant.
I wonder if it's worth trying to make pgcrypto disallow non-FIPS compliant
ciphers when the compiled against OpenSSL is running with FIPS
On Fri, Feb 16, 2024 at 1:32 PM Andrei Lepikhov
wrote:
>
> On 16/2/2024 07:00, jian he wrote:
> > On Wed, Feb 14, 2024 at 11:21 AM Andrei Lepikhov
> > wrote:
> > My OS: Ubuntu 22.04.3 LTS
> > I already set the max_parallel_workers_per_gather to 10.
> > So for all cases, it should use parallelism
Dear Euler,
Here are comments for v21.
01. main
```
/* rudimentary check for a data directory. */
...
/* subscriber PID file. */
```
Initial char must be upper, and period is not needed.
02. check_data_directory
```
snprintf(versionfile, MAXPGPATH, "%s/PG_VERSION", datad
On Thu, Jun 9, 2022 at 1:01 PM Kyotaro Horiguchi
wrote:
>
> > Currently CREATE_REPLICATION_SLOT/pg_create_logical_replication_slot waits
> > unboundedly if there are any in-progress write transactions [1]. []
> >
> > How about we provide a timeout for the command/function instead of letting
>
On Fri, Feb 16, 2024 at 12:32 AM Nathan Bossart
wrote:
> Here is what I have staged for commit.
>
Looks good to me.
Checked that all of the comparisons are in the expected order, except
inside compDESC, cmp_lsn, and resource_priority_cmp, where the order is
reversed.
Best wishes,
Mats Kindahl
On Fri, Feb 16, 2024 at 10:50 AM Hayato Kuroda (Fujitsu)
wrote:
>
> Thanks for reviewing! PSA new version.
>
+# Setup a disabled subscription. The upcoming test will check the
+# pg_createsubscriber won't work, so it is sufficient.
+$publisher->safe_psql('postgres', "CREATE PUBLICATION regress_pu
Hi,
The following assertion failure was seen while testing one scenario
for other patch:
TRAP: failed Assert("s->data.confirmed_flush >=
s->last_saved_confirmed_flush"), File: "slot.c", Line: 1760, PID:
545314
postgres: checkpointer performing shutdown
checkpoint(ExceptionalCondition+0xbb)[0x564ee
On 2/16/24 04:16, Daniel Gustafsson wrote:
On 15 Feb 2024, at 16:49, Peter Eisentraut wrote:
1. All the block ciphers currently supported by crypt() and gen_salt() are not
FIPS-compliant.
2. The crypt() and gen_salt() methods built on top of them (modes of operation,
kind of) are not FIPS-
Dear Daniel
Thanks for your reply.
> I wonder if it's worth trying to make pgcrypto disallow non-FIPS compliant
> ciphers when the compiled against OpenSSL is running with FIPS mode
> enabled, or raise a WARNING when used? It seems rather unlikely that
> someone running OpenSSL with FIPS=yes wan
Dear Peter
Thanks for the replying
> 1. All the block ciphers currently supported by crypt() and gen_salt() are not
> FIPS-compliant.
>
> 2. The crypt() and gen_salt() methods built on top of them (modes of
> operation,
> kind of) are not FIPS-compliant.
>
> 3. The implementations (crypt-blowfi
On 15.02.24 23:16, Maiquel Grassi wrote:
>
> Hi!
>
> (v16)
>
> In this version, I made a small adjustment to the indentation
> of the \conninfo code and described the columns as returned
> by \conninfo+ as suggested by Jim Jones.
>
>
I've performed the following tests with v16:
1) hostaddr=172
Dear Shubham,
Thanks for testing. It seems you ran with v20 patch, but I confirmed
It could reproduce with v21.
>
> I found a couple of issues, while verifying the cascaded replication
> with the following scenarios:
> Scenario 1) Create cascade replication like node1->node2->node3
> without usi
v3-0001-Remove-non-existing-file-from-.gitattributes.patch
I have committed that one.
v3-0002-Require-final-newline-in-.po-files.patch
The .po files are imported from elsewhere, so I'm not sure this is going
to have the desired effect. Perhaps it's worth cleaning up, but it
would require mor
On 13.02.2024 00:29, Pavel Luzanov wrote:
The changes are split into two patches.
0001 - pg_roles view. I plan to organize a new thread for discussion.
Please see it here:
https://www.postgresql.org/message-id/db1d94ba-1e6e-4e86-baff-91e6e79071c1%40postgrespro.ru
--
Pavel Luzanov
Postgres Prof
Hello,
Currently, a role with the createrole attribute can create roles, set and
change their password,
but can't see the password. Can't even see if the password is set or not.
In this case, you can mistakenly set the Valid until attribute to roles without
a password.
And there is no way to de
> On 15 Feb 2024, at 16:21, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> On 15 Feb 2024, at 11:38, Peter Eisentraut wrote:
>>> We don't have a man page for pg_regress, so there is no place to
>>> comprehensively document all the options and their interactions.
>
>> This comes up every now
On Thu, Feb 15, 2024 at 4:53 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Euler,
>
> > Policy)
> >
> > Basically, we do not prohibit to connect to primary/standby.
> > primary_slot_name may be changed during the conversion and
> > tuples may be inserted on target just after the promotion, but it see
> On 15 Feb 2024, at 16:49, Peter Eisentraut wrote:
> 1. All the block ciphers currently supported by crypt() and gen_salt() are
> not FIPS-compliant.
>
> 2. The crypt() and gen_salt() methods built on top of them (modes of
> operation, kind of) are not FIPS-compliant.
I wonder if it's worth
On Friday, February 16, 2024 3:43 PM Amit Kapila
wrote:
>
> On Fri, Feb 16, 2024 at 11:43 AM Amit Kapila wrote:
> >
> > Thanks for noticing this. I have pushed all your debug patches. Let's
> > hope if there is a BF failure next time, we can gather enough
> > information to know the reason of t
On Wed, Feb 14, 2024 at 5:04 PM torikoshia wrote:
>
> [] let the users know what line numbers are
> > containing the errors that COPY ignored something like [1] with a
> > simple change like [2].
>
> Agreed.
> Unlike my patch, it hides the error information(i.e. 22P02: invalid
> input syntax f
Hi,
On Fri, Feb 16, 2024 at 01:12:31PM +0530, Amit Kapila wrote:
> On Fri, Feb 16, 2024 at 11:43 AM Amit Kapila wrote:
> >
> > Thanks for noticing this. I have pushed all your debug patches. Let's
> > hope if there is a BF failure next time, we can gather enough
> > information to know the reason
81 matches
Mail list logo
