Hi,
commit 676887a3 added support for jsonb subscripting.
Many thanks for working on this. I really like the improved syntax.
I was also hoping for some performance benefits,
but my testing shows that
jsonb_value['existing_key'] = new_value;
takes just as long time as
jsonb_value :=
On Tue, Apr 13, 2021 at 04:39:58PM +0900, Michael Paquier wrote:
> Looks fine to me. Let's wait a bit first to see if Fujii-san has any
> objections to this cleanup as that's his code originally, from
> 32a9c0bd.
And hearing nothing, done. The tests of postgres_fdw are getting much
faster for
Hello David,
Thank you for your reply.
> Can you share if these times were to run EXPLAIN ANALYZE or if they
> were just the queries being executed normally?
These times were to run EXPLAIN ANALYZE. I executed each query twice,
and the **average** execution time was shown in the table of the
On Tue, Apr 13, 2021 at 10:12:35AM -0400, Tom Lane wrote:
> The following parameters are intended for developer testing, and
> should never be enabled for production work. However, some of
> them can be used to assist with the recovery of severely
> damaged databases.
Okay, that's fine by me.
--
At Wed, 14 Apr 2021 13:17:55 +0900, Kohei KaiGai wrote in
> 2021年4月14日(水) 0:00 Fujii Masao :
> >
> > On 2021/04/13 23:25, Kohei KaiGai wrote:
> > > 2021年4月13日(火) 21:03 Bharath Rupireddy
> > > :
> > >> Yeah, ONLY clause is not pushed to the remote server in case of SELECT
> > >> commands. This
2021年4月14日(水) 0:00 Fujii Masao :
>
> On 2021/04/13 23:25, Kohei KaiGai wrote:
> > 2021年4月13日(火) 21:03 Bharath Rupireddy
> > :
> >> Yeah, ONLY clause is not pushed to the remote server in case of SELECT
> >> commands. This is also true for DELETE and UPDATE commands on foreign
> >> tables.
>
>
On Tue, Apr 13, 2021 at 8:30 PM Fujii Masao wrote:
> On 2021/04/13 23:25, Kohei KaiGai wrote:
> > 2021年4月13日(火) 21:03 Bharath Rupireddy
> > :
> >> Yeah, ONLY clause is not pushed to the remote server in case of SELECT
> >> commands. This is also true for DELETE and UPDATE commands on foreign
>
Noah Misch writes:
> On Tue, Apr 13, 2021 at 06:26:34PM -0400, Tom Lane wrote:
>> Attached are some draft patches to convert almost all of the
>> contrib modules' SQL functions to use SQL-standard function bodies.
>> The point of this is to remove the residual search_path security
>> hazards that
On Wed, Apr 7, 2021 at 5:18 PM Amit Langote wrote:
> On Wed, Apr 7, 2021 at 8:24 AM Tom Lane wrote:
> > I also could not get excited about postponing initialization of RETURNING
> > or WITH CHECK OPTIONS expressions. I grant that that can be helpful
> > when those features are used, but I doubt
On Wed, Apr 14, 2021 at 8:04 AM vignesh C wrote:
>
> On Wed, Apr 14, 2021 at 7:52 AM Masahiko Sawada wrote:
> >
> > I've not looked at the patches yet but as Amit mentioned before[1],
> > it's better to move 0002 patch to after 0004. That is, 0001 patch
> > changes data type to NameData, 0002
On Wed, 14 Apr 2021 at 10:41, Craig Ringer
wrote:
> On Wed, 14 Apr 2021 at 02:25, Robert Haas wrote:
> > You could try to identify locks by pointer addresses, but that's got
> > security hazards and the addreses aren't portable across all the
> > backends involved in the parallel query because
On Wed, 14 Apr 2021 at 02:25, Robert Haas wrote:
> So before the commit in question --
> 3761fe3c20bb040b15f0e8da58d824631da00caa -- T_ID() used to compute an
> offset for a lock within the tranche that was supposed to uniquely
> identify the lock. However, the whole idea of an array per tranche
On Tue, 13 Apr 2021 at 21:54, osumi.takami...@fujitsu.com
wrote:
> On Monday, April 12, 2021 3:58 PM Amit Kapila wrote:
>> On Mon, Apr 12, 2021 at 10:03 AM osumi.takami...@fujitsu.com
>> wrote:
>> > but if we take a measure to fix the doc, we have to be careful for the
>> > description,
On Wed, Apr 14, 2021 at 7:52 AM Masahiko Sawada wrote:
>
> On Tue, Apr 13, 2021 at 5:07 PM vignesh C wrote:
> >
> > On Mon, Apr 12, 2021 at 7:03 PM Masahiko Sawada
> > wrote:
> > >
> > > On Mon, Apr 12, 2021 at 9:36 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Mon, Apr 12, 2021 at 5:29 PM
On Wed, 14 Apr 2021 at 04:46, Andres Freund wrote:
>
> On 2021-04-13 14:25:23 -0400, Robert Haas wrote:
> > On Mon, Apr 12, 2021 at 11:06 PM Andres Freund wrote:
> > You could identify every lock by a tranche ID + an array offset + a
> > "tranche instance ID". But where would you store the
On Tue, Apr 13, 2021 at 5:07 PM vignesh C wrote:
>
> On Mon, Apr 12, 2021 at 7:03 PM Masahiko Sawada wrote:
> >
> > On Mon, Apr 12, 2021 at 9:36 PM Amit Kapila wrote:
> > >
> > > On Mon, Apr 12, 2021 at 5:29 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Mon, Apr 12, 2021 at 8:08 PM Amit
On Tue, Apr 13, 2021 at 06:26:34PM -0400, Tom Lane wrote:
> Attached are some draft patches to convert almost all of the
> contrib modules' SQL functions to use SQL-standard function bodies.
> The point of this is to remove the residual search_path security
> hazards that we couldn't fix in
On Tue, Apr 13, 2021 at 10:46 AM Masahiko Sawada
wrote:
>
> On Mon, Apr 12, 2021 at 9:16 PM vignesh C wrote:
> >
> > On Mon, Apr 12, 2021 at 4:46 PM Amit Kapila
wrote:
> > >
> > > On Sat, Apr 10, 2021 at 6:51 PM vignesh C wrote:
> > > >
> > >
> > > Thanks, 0001 and 0002 look good to me. I have
On Tue, Apr 13, 2021 at 08:00:34AM -0700, Noah Misch wrote:
> On Tue, Apr 13, 2021 at 02:43:11PM +0900, Michael Paquier wrote:
>>> - If extschema='public', "pg_dump -e plpgsql --schema=public" includes
>>> commands to dump the relation data. This surprised me. (The
>>> --schema=public
On Wed, Apr 14, 2021 at 4:59 AM Peter Geoghegan wrote:
>
> On Mon, Apr 12, 2021 at 11:05 PM Masahiko Sawada
> wrote:
> > I realized that when the failsafe is triggered, we don't bypass heap
> > truncation that is performed before updating relfrozenxid. I think
> > it's better to bypass it too.
On 4/12/21 7:04 PM, Tom Lane wrote:
> Ranier Vilela writes:
>> Em seg., 12 de abr. de 2021 às 03:04, Tom Lane escreveu:
>>> It would be wrong, though, or at least not have the same effect.
>
>> I think that you speak about fill pointers with 0 is not the same as fill
>> pointers with NULL.
>
Attached are some draft patches to convert almost all of the
contrib modules' SQL functions to use SQL-standard function bodies.
The point of this is to remove the residual search_path security
hazards that we couldn't fix in commits 7eeb1d986 et al. Since
a SQL-style function body is fully
Hi,
On Tue, 13 Apr 2021 16:12:59 +0900 (JST)
Tatsuo Ishii wrote:
> [...]
> [...]
> [...]
>
> Thanks for the pointer. It seems we need to resume the discussion.
By the way, I've been playing with the idea of failing gracefully and retry
indefinitely (or until given -T) on SQL error
Hi,
On 2021-04-13 14:25:23 -0400, Robert Haas wrote:
> On Mon, Apr 12, 2021 at 11:06 PM Andres Freund wrote:
> You could identify every lock by a tranche ID + an array offset + a
> "tranche instance ID". But where would you store the tranche instance
> ID to make it readily accessible, other
On Mon, Apr 12, 2021 at 11:05 PM Masahiko Sawada wrote:
> I realized that when the failsafe is triggered, we don't bypass heap
> truncation that is performed before updating relfrozenxid. I think
> it's better to bypass it too. What do you think?
I agree. Bypassing heap truncation is exactly the
Charlie Hornsby writes:
> I tested the above patch with the invalid data locally and it avoids
> the restore error that we ran into previously. Also it requires no
> intervention to progress with pg_upgrade unlike my initial idea of
> adding an check, so it is definitely simpler from a user
On Mon, Apr 12, 2021 at 11:06 PM Andres Freund wrote:
> No, they have to be the same in each. Note how the tranche ID is part of
> struct LWLock. Which is why LWLockNewTrancheId() has to acquire a lock
> etc.
More precisely, if a tranche ID is defined in multiple backends, it
needs to be defined
On Sat, Apr 10, 2021 at 01:42:26PM -0500, Justin Pryzby wrote:
> On Sun, Mar 21, 2021 at 03:01:15PM -0300, Alvaro Herrera wrote:
> > > But note that it doesn't check if an existing constraint "implies" the new
> > > constraint - maybe it should.
> >
> > Hm, I'm not sure I want to do that, because
> On 12-Apr-2021, at 17:25, Bruce Momjian wrote:
>
> On Mon, Apr 12, 2021 at 05:20:43PM -0700, Bryn Llewellyn wrote:
>> I’d argue that the fact that this:
>>
>> ('0.3 months'::interval) + ('0.7 months'::interval)
>>
>> Is reported as '30 days' and not '1 month' is yet another
>> bug—precisely
On Mon, Apr 12, 2021 at 10:07 PM James Coleman wrote:
>
> On Mon, Apr 12, 2021 at 7:49 PM David Rowley wrote:
> >
> > On Tue, 13 Apr 2021 at 11:42, Tom Lane wrote:
> > >
> > > David Rowley writes:
> > > > I realised when working on something unrelated last night that we can
> > > > also do
On 2021-Apr-12, Bruce Momjian wrote:
> OK, the attached patch renames pg_stat_activity.queryid to 'query_id'. I
> have not changed any of the APIs which existed before this feature was
> added, and are called "queryid" or "queryId" --- it is kind of a mess.
> I assume I should leave those
Tom wrote:
> I do find it interesting that we now have two reports of somebody
> doing "ALTER ROLE SET role = something". In the older thread,
> I was skeptical that that had any real use-case, so I wonder if
> Charlie has a rationale for having done that.
Unfortunately I haven't heard back from
On Tue, Apr 13, 2021 at 10:33 AM Dave Page wrote:
> On a system with selinux and sepgsql configured, search path resolution
> appears to fail if sepgsql is in enforcing mode, but selinux is in permissive
> mode (which, as I understand it, should cause sepgsql to behave as if it's in
>
Hello Sir/Madam,
I'm Nandni Mehla, a sophomore currently pursuing B.Tech in IT from Indira
Gandhi Delhi Technical University for Women, Delhi. I've recently started
working on open source and I think I will be a positive addition to
your organization for working on projects using C and SQL, as I
On 2021-Apr-13, Amit Langote wrote:
> Actually it occurred to me this morning that CLOBBER_CACHE_ALWAYS is
> what exposed this problem on this animal (not sure if other such
> animals did too though). With CLOBBER_CACHE_ALWAYS, a PartitionDesc
> will be built afresh on most uses. In this
On Wed, 2021-04-07 at 10:20 +0900, Michael Paquier wrote:
> Anyway, using a FATAL in this code path is fine by me at the end, so I
> have applied the patch. Let's see now what the buildfarm thinks about
> it.
Looks like the farm has gone green, after some test fixups. Thanks for
all the reviews!
On 2021/04/13 23:25, Kohei KaiGai wrote:
2021年4月13日(火) 21:03 Bharath Rupireddy :
Yeah, ONLY clause is not pushed to the remote server in case of SELECT
commands. This is also true for DELETE and UPDATE commands on foreign
tables.
This sounds reasonable reason why ONLY should be ignored in
On Tue, Apr 13, 2021 at 02:43:11PM +0900, Michael Paquier wrote:
> On Sun, Apr 04, 2021 at 03:08:02PM -0700, Noah Misch wrote:
> > I noticed the patch's behavior for relations that are members of non-dumped
> > extensions and are also registered using pg_extension_config_dump(). It
> > depends on
On Tue, 13 Apr 2021 at 21:40, Craig Ringer
wrote:
> Findings:
>
> * A probe without arguments or with simple arguments is just a 'nop'
> instruction
> * Probes that require function calls, pointer chasing, other
> expression evaluation etc may impose a fixed cost to collect up
> arguments even
Justin Pryzby writes:
> On Fri, Apr 09, 2021 at 04:28:25PM +0300, Yura Sokolov wrote:
>> Occasinally I found I'm not able to `make check` old Postgresql versions.
>> I've bisected between REL_11_0 and "Rename pg_rewind's copy_file_range()"
>> and
>> found 372728b0d49552641f0ea83d9d2e08817de038fa
> On 12 Apr 2021, at 08:58, Amit Kapila wrote:
>
> On Mon, Apr 12, 2021 at 10:03 AM osumi.takami...@fujitsu.com
> wrote:
>>
>>> I checked the PG-DOC, found it says that “Replication of TRUNCATE
>>> commands is supported”[1], so maybe TRUNCATE is not supported in
>>> synchronous logical
On a system with selinux and sepgsql configured, search path resolution
appears to fail if sepgsql is in enforcing mode, but selinux is in
permissive mode (which, as I understand it, should cause sepgsql to behave
as if it's in permissive mode anyway - and does for other operations).
Regardless of
On Tue, Apr 13, 2021 at 6:22 PM vignesh C wrote:
> > 2) How about
> > + Specifies whether the subscriber must verify the
> > publications that are
> > + being subscribed to are present in the publisher. By default,
> > the subscriber
> > instead of
> > + Specifies whether
2021年4月13日(火) 21:03 Bharath Rupireddy :
>
> On Tue, Apr 13, 2021 at 2:37 PM Kohei KaiGai wrote:
> > Here are two points to discuss.
> >
> > Regarding to the FDW-APIs, yes, nobody can deny someone want to implement
> > their own FDW module that adds special handling when its foreign table
> > is
Michael Paquier writes:
> On Mon, Apr 12, 2021 at 01:40:52AM -0400, Tom Lane wrote:
>> Perhaps ... what did you have in mind?
> The first sentence of the page now says that:
> "The following parameters are intended for work on the PostgreSQL
> source code, and in some cases to assist with
On Mon, Apr 12, 2021 at 4:22 PM Bruce Momjian wrote:
> On Mon, Apr 12, 2021 at 03:09:48PM -0700, Bryn Llewellyn wrote:
> > I showed you all this example a long time ago:
> >
> > select (
> > '
> > 3.853467 years
> > '::interval
> > )::text as i;
> >
> > This behavior is the same
exactly my point, want to scan only 500GB data instead of 1TB. That can be
handy for vacuum freeze at a dangerous stage (reaching towards 2B).
"Maybe we can track the oldest xid per page in a map like visiblity map
or integrate it with visibility map. We need to freeze only pages that
are
On Monday, April 12, 2021 3:58 PM Amit Kapila wrote:
> On Mon, Apr 12, 2021 at 10:03 AM osumi.takami...@fujitsu.com
> wrote:
> > but if we take a measure to fix the doc, we have to be careful for the
> > description, because when we remove the primary keys of 'test' tables on the
> scenario in
On Tue, 13 Apr 2021 at 21:05, Craig Ringer
wrote:
> On Tue, 13 Apr 2021 at 11:06, Andres Freund wrote:
> > IIRC those aren't really comparable - the kernel actually does modify
> > the executable code to replace the tracepoints with nops.
>
> Same with userspace static trace markers (USDTs).
>
>
Hi,
Whilst trying to debug a deadlock in some tpc-ds query I noticed
something that could cause problems in the hashjoin implementation and
cause potentially deadlocks (if my analysis is right).
Whilst building the inner hash table, the whole time the grow barriers
are attached (the
Hi.
Currently PostgreSQL supports CTE push down for SELECT statements, but
it is implemented as turning each CTE reference into subquery.
When CTE is referenced multiple times, we have choice - to materialize
CTE (and disable quals distribution to the CTE query) or inline it (and
so run CTE
On Tue, 13 Apr 2021 at 11:06, Andres Freund wrote:
> > Each backend can have different tranche IDs (right?)
>
> No, they have to be the same in each. Note how the tranche ID is part of
> struct LWLock. Which is why LWLockNewTrancheId() has to acquire a lock
> etc.
Ah. I misunderstood that at
On Thu, Apr 8, 2021 at 12:13 PM Bharath Rupireddy
wrote:
>
> On Wed, Apr 7, 2021 at 10:37 PM vignesh C wrote:
> > > I think, we can also have validate_publication option allowed for
> > > ALTER SUBSCRIPTION SET PUBLICATION and REFRESH PUBLICATION commands
> > > with the same behaviour i.e. error
Hi,
Few of the statistics description in monitoring_stats.sgml doc is not
consistent. Made all the descriptions consistent by including
punctuation marks at the end of each description.
Thoughts?
Regards,
Vignesh
From b74179aec11eb1f2439ef43e1830531c2cde78a2 Mon Sep 17 00:00:00 2001
From:
On Tue, Apr 13, 2021 at 1:51 PM Virender Singla wrote:
>
> Thanks Masahiko for the response.
>
> "What is
> the use case where users want to freeze fewer transactions, meaning
> invoking anti-wraparound frequently?"
>
> My overall focus here is anti wraparound vacuum on huge tables in emergency
On Tue, Apr 13, 2021 at 04:34:23PM +0900, Michael Paquier wrote:
> On Mon, Apr 12, 2021 at 01:40:52AM -0400, Tom Lane wrote:
> >> - Should we make more general the description of the developer options
> >> in the docs?
> >
> > Perhaps ... what did you have in mind?
>
> The first sentence of the
On Tue, Apr 13, 2021 at 2:37 PM Kohei KaiGai wrote:
> Here are two points to discuss.
>
> Regarding to the FDW-APIs, yes, nobody can deny someone want to implement
> their own FDW module that adds special handling when its foreign table
> is specified
> with ONLY-clause, even if we usually
On Fri, Apr 09, 2021 at 04:28:25PM +0300, Yura Sokolov wrote:
> Good day, hackers.
>
> I've got HP ProBook 640g8 with i7-1165g7. I've installed Ubuntu 20.04 LTS on
> it
> and started to play with PostgreSQL sources.
>
> Occasinally I found I'm not able to `make check` old Postgresql versions.
On Tue, 13 Apr 2021 at 19:48, Virender Singla wrote:
> Yes another thing here is anti wraparound vacuum also cleans dead tuples but
> i am not sure what we can do to avoid that.
> There can be vacuum to only freeze the tulpes?
You might want to have a look at [1], which was just pushed for
I think it is better to add this test case to regress.
发件人: Tom Lane
发送时间: 2021年4月13日 0:59
收件人: Yulin PEI
抄送: pgsql-hackers@lists.postgresql.org
主题: Re: Core dump happens when execute sql CREATE VIEW v1(c1) AS (SELECT ('4'
COLLATE "C")::INT FROM
After reading the code and the patch, I think the patch is good. If the
type is non-collatable, we do not add a CollateExpr node as a 'parent' node to
the coerced node.
发件人: Tom Lane
发送时间: 2021年4月13日 0:59
收件人: Yulin PEI
抄送:
Yura Sokolov писал 2021-04-09 16:28:
Good day, hackers.
I've got HP ProBook 640g8 with i7-1165g7. I've installed Ubuntu 20.04
LTS on it
and started to play with PostgreSQL sources.
Occasinally I found I'm not able to `make check` old Postgresql
versions.
At least 9.6 and 10. They are
On Tue, 13 Apr 2021 at 21:29, Yuya Watari wrote:
> I used the TPC-DS scale factor 100 in the evaluation. I executed all
> of the 99 queries in the TPC-DS, and the result cache worked in the 21
> queries of them. However, some queries took too much time, so I
> skipped their execution. I set
Hello,
Recently, the result cache feature was committed to PostgreSQL. I
tested its performance by executing TPC-DS. As a result, I found that
there were some regressions in the query performance.
I used the TPC-DS scale factor 100 in the evaluation. I executed all
of the 99 queries in the
2021年4月13日(火) 16:17 Fujii Masao :
>
> On 2021/04/13 14:22, Kohei KaiGai wrote:
> > Let me remind the discussion at the design level.
> >
> > If postgres_fdw (and other FDW drivers) needs to consider whether
> > ONLY-clause is given
> > on the foreign tables of them, what does a foreign table
At Tue, 13 Apr 2021 16:17:12 +0900, Fujii Masao
wrote in
>
>
> On 2021/04/13 14:22, Kohei KaiGai wrote:
> > Let me remind the discussion at the design level.
> > If postgres_fdw (and other FDW drivers) needs to consider whether
> > ONLY-clause is given
> > on the foreign tables of them, what
On Mon, Apr 12, 2021 at 7:03 PM Masahiko Sawada wrote:
>
> On Mon, Apr 12, 2021 at 9:36 PM Amit Kapila wrote:
> >
> > On Mon, Apr 12, 2021 at 5:29 PM Masahiko Sawada
> > wrote:
> > >
> > > On Mon, Apr 12, 2021 at 8:08 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Mon, Apr 12, 2021 at 4:34
On Mon, Apr 12, 2021 at 10:12:46PM -0400, Bruce Momjian wrote:
> On Thu, Apr 8, 2021 at 01:01:42PM -0400, Bruce Momjian wrote:
> > On Thu, Apr 8, 2021 at 12:51:06PM -0400, Álvaro Herrera wrote:
> > > On 2021-Apr-08, Bruce Momjian wrote:
> > >
> > > > pg_stat_activity.queryid is new, but I can
Hello,
After upgrading the cluster from 10.x to 13.1 we've started getting a problem
describe pgsql-general:
https://www.postgresql.org/message-id/8bf8785c-f47d-245c-b6af-80dc1eed40db%40unitygroup.com
We've noticed similar issue being described on this list in
Thanks Masahiko for the response.
"What is
the use case where users want to freeze fewer transactions, meaning
invoking anti-wraparound frequently?"
My overall focus here is anti wraparound vacuum on huge tables in emergency
situations (where we reached very close to 2B transactions or already
On Mon, Apr 12, 2021 at 11:29:28AM +0530, Bharath Rupireddy wrote:
> I changed to 5min. If at all there's any server that would take more
> than 5min to remove a process from the system processes list, then it
> would see a warning on timeout.
Looks fine to me. Let's wait a bit first to see if
On Mon, Apr 12, 2021 at 01:40:52AM -0400, Tom Lane wrote:
> Michael Paquier writes:
>> However, I'd like to think that we can do better than what's proposed
>> in the patch. There are a couple of things to consider here:
>> - Should the parameter be renamed to reflect that it should only be
>>
On Mon, Apr 12, 2021 at 10:36:10PM -0700, Noah Misch wrote:
> Christoph Berg's first message on this thread reported doing that. If
> supporting server_user!=pg_regress_user is unwarranted and Christoph Berg
> should stop, then already-committed code suffices.
Not sure that we have ever claimed
On 2021/04/13 14:22, Kohei KaiGai wrote:
Let me remind the discussion at the design level.
If postgres_fdw (and other FDW drivers) needs to consider whether
ONLY-clause is given
on the foreign tables of them, what does a foreign table represent in
PostgreSQL system?
My assumption is, a
> On Tue, Apr 13, 2021 at 5:51 PM Tatsuo Ishii wrote:
>> Currently standard pgbench scenario produces transaction serialize
>> errors "could not serialize access due to concurrent update" if
>> PostgreSQL runs in REPEATABLE READ or SERIALIZABLE level, and the
>> session aborts. In order to
On Tue, Apr 13, 2021 at 5:51 PM Tatsuo Ishii wrote:
> Currently standard pgbench scenario produces transaction serialize
> errors "could not serialize access due to concurrent update" if
> PostgreSQL runs in REPEATABLE READ or SERIALIZABLE level, and the
> session aborts. In order to achieve
On 2021/04/13 12:46, Justin Pryzby wrote:
On Tue, Apr 13, 2021 at 12:38:35PM +0900, Fujii Masao wrote:
+ Relation data structures for each
+ foreign tables to be truncated.
"foreign tables" should be "foreign table" because it follows "each"?
Yes, you're right.
+
+
All,
Guys, thank you all for your advice! As a starting point I definitely
should take a look at the current Commitfest and try to help in review as
best I can. Thanks!
Regards,
пн, 12 апр. 2021 г. в 16:38, Justin Pryzby :
> On Mon, Apr 12, 2021 at 03:21:41PM +, Ian Zagorskikh wrote:
> >
On Thu, Apr 8, 2021 at 11:42 AM Masahiko Sawada wrote:
>
> On Thu, Apr 8, 2021 at 8:41 AM Peter Geoghegan wrote:
> >
> > On Wed, Apr 7, 2021 at 8:52 AM Peter Geoghegan wrote:
> > > All of the changes from your fixup patch are clear improvements, and
> > > so I'll include them in the final
79 matches
Mail list logo
