On Wed, Jun 28, 2023 at 09:20:03PM -0700, Gurjeet Singh wrote:
> The comment on top of connect_utils.c:connectDatabase() seems pertinent:
>
>> (Callers should not pass
>> * allow_password_reuse=true unless reconnecting to the same database+user
>> * as before, else we might create password
At Wed, 28 Jun 2023 16:24:02 -0700, Nathan Bossart
wrote in
> While working on some other patches, I found myself wanting to use the
> following command to vacuum the catalogs in all databases in a cluster:
>
> vacuumdb --all --schema pg_catalog
>
> However, this presently fails with
On Thu, Jun 29, 2023 at 02:11:43AM +, Shinoda, Noriyoshi (PN Japan FSIP)
wrote:
> I found while testing PostgreSQL 16 Beta 1 that the output of the \?
> metacommand did not include \dS, \dpS.
> The attached patch changes the output of the \? meta command to:
Thanks for the report! I've
On Thursday, June 29, 2023 12:06 PM vignesh C wrote:
>
> On Wed, 28 Jun 2023 at 19:26, Ashutosh Bapat
> wrote:
> >
> > Hi Vignesh,
> > Thanks for working on this.
> >
> > On Wed, Jun 28, 2023 at 4:52 PM vignesh C wrote:
> > >
> > > Here is a patch having the fix for the same. I have not added
On Tue, Jun 27, 2023 at 9:57 PM Nathan Bossart wrote:
>
> While looking at something unrelated, I noticed that the vacuumdb docs
> mention the following:
>
> vacuumdb might need to connect several times to the PostgreSQL server,
> asking for a password each time.
>
> IIUC this has
On Wed, 28 Jun 2023 at 19:26, Ashutosh Bapat
wrote:
>
> Hi Vignesh,
> Thanks for working on this.
>
> On Wed, Jun 28, 2023 at 4:52 PM vignesh C wrote:
> >
> > Here is a patch having the fix for the same. I have not added any
> > tests as the existing tests cover this scenario. The same issue is
On Thu, 29 Jun 2023 at 09:26, Tomas Vondra
wrote:
> AllocSetContext 224B -> 208B (4 cachelines)
> GenerationContext 152B -> 136B (3 cachelines)
> SlabContext 200B -> 200B (no change, adds 4B hole)
>
> Nothing else changes, AFAICS.
I don't think a lack of a reduction in the number
On Thu, Jun 29, 2023 at 8:19 AM Michael Paquier wrote:
> Nothing much to add, so applied with the initial comment fix.
Thanks for pushing it!
Thanks
Richard
While working on the invalid parameterized join path issue [1], I
noticed that we can simplify the codes for checking parameterized
partial paths in try_partial_hashjoin/mergejoin_path, with the help of
macro PATH_REQ_OUTER.
- if (inner_path->param_info != NULL)
- {
-
On Fri, Jun 23, 2023 at 10:25 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear hackers,
>
> While discussing based on the article[1] with Japanese developers,
> I found inconsistencies between codes and documents.
>
> 45b1a67a[2] changed the behavior when non-ASCII characters was set as
>
On Wed, Jun 28, 2023 at 10:09 PM Tom Lane wrote:
> However, given that what we need is to exclude parameterization
> that depends on the currently-formed OJ, it seems to me we can do
> it more simply and without any new JoinPathExtraData field,
> as attached. What do you think?
I think it
Hi,
Thank you for developing a good feature.
I found while testing PostgreSQL 16 Beta 1 that the output of the \?
metacommand did not include \dS, \dpS.
The attached patch changes the output of the \? meta command to:
Current output
psql=# \?
\z [PATTERN] same as \dp
\dp
Em qua., 28 de jun. de 2023 às 18:45, Tomas Vondra <
tomas.von...@enterprisedb.com> escreveu:
> On 6/27/23 20:55, Ranier Vilela wrote:
> > Hi,
> >
> >>I finished writing the code patch for transformation "Or" expressions to
> >>"Any" expressions. I didn't see any problems in regression tests,
At Wed, 28 Jun 2023 22:28:13 +0900, torikoshia
wrote in
>
> On 2022-09-29 17:18, Polina Bungina wrote:
> > I agree with your suggestions, so here is the updated version of
> > patch. Hope I haven't missed anything.
> > Regards,
> > Polina Bungina
>
> Thanks for working on this!
> It seems
On Thu, 29 Jun 2023 at 08:19, Michael Paquier wrote:
> On Wed, Jun 28, 2023 at 09:26:02PM +0800, Japin Li wrote:
>> +1. LGTM.
>
> Nothing much to add, so applied with the initial comment fix.
Thanks!
--
Regrads,
Japin Li.
On Wed, Jun 28, 2023 at 10:45:02AM +0200, Peter Eisentraut wrote:
> Right, the usual style is just to check whether an environment variable is
> set to something, not what it is.
>
> Also note that in general not all environment variables are processed by
> Perl, so I would avoid encoding Perl
On Wed, Jun 28, 2023 at 09:26:02PM +0800, Japin Li wrote:
> +1. LGTM.
Nothing much to add, so applied with the initial comment fix.
--
Michael
signature.asc
Description: PGP signature
Hi,
On 2023-06-28 17:56:55 -0400, Tom Lane wrote:
> Tomas Vondra writes:
> > ... 4B is tiny compared to what we waste due to the doubling.
>
> Yeah. I've occasionally wondered if we should rethink aset.c's
> "only power-of-2 chunk sizes" rule. Haven't had the bandwidth
> to pursue the idea
Hi all,
While working on a different patch, I have noted three code paths that
call changeDependencyFor() but don't check that they do not return
errors. In all the three cases (support function, extension/schema
and object/schema), it seems to me that only one dependency update is
expected.
I
Hi,
On 2023-06-28 23:26:00 +0200, Tomas Vondra wrote:
> Yeah. FWIW I was interested what the patch does in practice, so I
> checked what pahole says about impact on struct sizes:
>
> AllocSetContext 224B -> 208B (4 cachelines)
> GenerationContext 152B -> 136B (3 cachelines)
> SlabContext
While working on some other patches, I found myself wanting to use the
following command to vacuum the catalogs in all databases in a cluster:
vacuumdb --all --schema pg_catalog
However, this presently fails with the following error:
cannot vacuum specific schema(s) in all
Hi,
On 2023-06-28 07:26:03 +0200, Ronan Dunklau wrote:
> I see it as a way to have *some* sort of control over the malloc
> implementation we use, instead of tuning our allocations pattern on top of it
> while treating it entirely as a black box. As for the tuning, I proposed
> earlier to replace
On 6/28/23 14:17, Tatsuo Ishii wrote:
Small question.
This query (with all the defaults made explicit):
SELECT s.company, s.tdate, s.price,
FIRST_VALUE(s.tdate) OVER w,
LAST_VALUE(s.tdate) OVER w,
lowest OVER w
FROM stock AS s
WINDOW w AS (
PARTITION BY s.company
Tomas Vondra writes:
> On 6/28/23 16:52, Peter Eisentraut wrote:
>> - 0001: Change type of pg_statistic_ext.stxstattarget, to match
>> attstattarget. Maybe this should go into PG16, for consistency?
> Not sure about 0001 vs PG16, it'd require catversion bump.
Yeah, past beta1 I think we should
Tomas Vondra writes:
> ... 4B is tiny compared to what we waste due to the doubling.
Yeah. I've occasionally wondered if we should rethink aset.c's
"only power-of-2 chunk sizes" rule. Haven't had the bandwidth
to pursue the idea though.
regards, tom lane
On 6/26/23 20:15, Alena Rybakina wrote:
> Hi, all!
>
> On 24.06.2023 14:23, Tomas Vondra wrote:
>> On 6/24/23 02:08, Tom Lane wrote:
>>> Tomas Vondra writes:
The problem is that the selectivity for "IS NULL" is estimated using the
table-level statistics. But the LEFT JOIN entirely
On 6/27/23 20:55, Ranier Vilela wrote:
> Hi,
>
>>I finished writing the code patch for transformation "Or" expressions to
>>"Any" expressions. I didn't see any problems in regression tests, even
>>when I changed the constant at which the minimum or expression is
>>replaced by any at 0. I ran my
On 6/28/23 16:52, Peter Eisentraut wrote:
> Here are a few patches related to attstattarget:
>
> - 0001: Change type of pg_statistic_ext.stxstattarget, to match
> attstattarget. Maybe this should go into PG16, for consistency?
>
> - 0002: Add macro for maximum statistics target, instead of
On 6/28/23 12:59, Tom Lane wrote:
> David Rowley writes:
>> Perhaps it's ok to leave the context creation functions with Size
>> typed parameters and then just Assert the passed-in sizes are not
>> larger than 1GB within the context creation function.
>
> Yes, I'm strongly opposed to not using
This patch adds a few examples to demonstrate the following:
* The existence of the ctid column on every table
* The utility of ctds in self joins
* A practical usage of SKIP LOCKED
The reasoning for this is a bit long, but if you're interested, keep
reading.
In the past, there has been a
Hi,
On 2023-06-28 10:40:22 +0200, Peter Eisentraut wrote:
> On 26.06.23 21:54, Andres Freund wrote:
> > For something like pg_list.h the malloc(free) attribute is a bit awkward to
> > use, because one a) needs to list ~30 functions that can free a list and b)
> > the referenced functions need to
On Wed, Jun 28, 2023 at 4:06 PM Yugo NAGATA wrote:
>
> On Wed, 28 Jun 2023 00:01:02 +0800
> jian he wrote:
>
> > On Thu, Jun 1, 2023 at 2:47 AM Yugo NAGATA wrote:
> > >
> > > On Thu, 1 Jun 2023 23:59:09 +0900
> > > Yugo NAGATA wrote:
> > >
> > > > Hello hackers,
> > > >
> > > > Here's a
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Andrew Dunstan writes:
>> On 2023-06-22 Th 16:56, Greg Sabino Mullane wrote:
>>> * Do all of these transforms need to be their own contrib modules? So
>>> much duplicated code across contrib/*_plperl already (and *plpython
>>> too for that
On 28.06.23 12:46, Laurenz Albe wrote:
On Wed, 2023-06-28 at 15:40 +0530, Pradeep Kumar wrote:
I was under the impression that the --link option would create hard links
between the
old and new cluster's data files, but it appears that the entire old cluster
data was
copied to the new cluster,
The MergeAttributes() and related code in and around tablecmds.c is huge
and ancient, with many things bolted on over time, and difficult to deal
with. I took some time to make careful incremental updates and
refactorings to make the code easier to follow, more compact, and more
modern in
Alena Rybakina writes:
> On 23.06.2023 14:28, Andrey Lepikhov wrote:
>> On 2/5/2012 20:34, Tom Lane wrote:
>>> On reflection I think that the idea of clamping ndistinct beforehand is
>>> just wrong, and what we ought to do instead is apply a multiplier to the
>>> selectivity estimate afterwards.
Here are a few patches related to attstattarget:
- 0001: Change type of pg_statistic_ext.stxstattarget, to match
attstattarget. Maybe this should go into PG16, for consistency?
- 0002: Add macro for maximum statistics target, instead of hardcoding
it everywhere.
- 0003: Take pg_attribute
Richard Guo writes:
> On Wed, Jun 28, 2023 at 6:28 AM Tom Lane wrote:
>> For a real fix, I'm inclined to extend the loop that calculates
>> param_source_rels (in add_paths_to_joinrel) so that it also tracks
>> a set of incompatible relids that *must not* be present in the
>> parameterization of
Hi Vignesh,
Thanks for working on this.
On Wed, Jun 28, 2023 at 4:52 PM vignesh C wrote:
>
> Here is a patch having the fix for the same. I have not added any
> tests as the existing tests cover this scenario. The same issue is
> present in back branches too.
Interesting, we have a test for
Hi!
On 15.06.2023 11:30, Andrey Lepikhov wrote:
Hi, all.
Some of my clients use JOIN's with three - four clauses. Quite
frequently, I see complaints on unreasonable switch of JOIN algorithm
to Merge Join instead of Hash Join. Quick research have shown one weak
place - estimation of an
On 2022-09-29 17:18, Polina Bungina wrote:
I agree with your suggestions, so here is the updated version of
patch. Hope I haven't missed anything.
Regards,
Polina Bungina
Thanks for working on this!
It seems like we are also facing the same issue.
I tested the v3 patch under our condition,
On Wed, 28 Jun 2023 at 16:27, Richard Guo wrote:
> On Wed, Jun 28, 2023 at 3:36 PM Michael Paquier wrote:
>
>> On Wed, Jun 28, 2023 at 03:09:55PM +0800, Richard Guo wrote:
>> > +1. To nitpick, how about we remove the blank line just before removing
>> > the key for top level entry?
>> >
>> >
Hi Yugo
Thank you for taking a look at the paper.
The key difference from PostgreSQL is that it only allows updates on single
table views. My paper discusses two kinds of joins of two tables. It
discusses how to update them and how to determine when they occur.
The paper also discusses
Small question.
> This query (with all the defaults made explicit):
>
> SELECT s.company, s.tdate, s.price,
>FIRST_VALUE(s.tdate) OVER w,
>LAST_VALUE(s.tdate) OVER w,
>lowest OVER w
> FROM stock AS s
> WINDOW w AS (
> PARTITION BY s.company
> ORDER BY s.tdate
> ROWS
On Mon, 26 Jun 2023 at 15:51, Amit Kapila wrote:
>
> On Mon, Jun 26, 2023 at 3:07 PM Ashutosh Bapat
> wrote:
> >
> > Hi All,
> > Every pg_decode routine except pg_decode_message that decodes a
> > transactional change, has following block
> > /* output BEGIN if we haven't yet */
> > if
David Rowley writes:
> Perhaps it's ok to leave the context creation functions with Size
> typed parameters and then just Assert the passed-in sizes are not
> larger than 1GB within the context creation function.
Yes, I'm strongly opposed to not using Size/size_t in the mmgr APIs.
If we go that
Thank you for running the profiles.
On Tue, 27 Jun 2023 at 21:11, Yuya Watari wrote:
> On Sat, Jun 24, 2023 at 1:15 PM David Rowley wrote:
> > I think it's also important to check we don't slow anything down for
> > more normal-sized sets. The vast majority of sets will contain just a
> >
On Fri, Apr 14, 2023 at 4:00 PM Hayato Kuroda (Fujitsu)
wrote:
>
> > Sorry for the delay, I didn't had time to come back to it until this
> > afternoon.
>
> No issues, everyone is busy:-).
>
> > I don't think that your analysis is correct. Slots are guaranteed to be
> > stopped after all the
On Wed, 2023-06-28 at 15:40 +0530, Pradeep Kumar wrote:
> > > I was under the impression that the --link option would create hard links
> > > between the
> > > old and new cluster's data files, but it appears that the entire old
> > > cluster data was
> > > copied to the new cluster, resulting
This is my numbers.
df ~/pradeep_test/pg_upgrade_testing/postgres_11.4/master
~/pradeep_test/pg_upgrade_testing/postgres_14/new_pg
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/nvme0n1p4_crypt 375161856 102253040 270335920 28% /home
Sure,
du -sk ~/pradeep_test/pg_upgrade_testing/postgres_11.4/master
~/pradeep_test/pg_upgrade_testing/postgres_14/new_pg
11224524 /home/test/pradeep_test/pg_upgrade_testing/postgres_11.4/master
41952 /home/test/pradeep_test/pg_upgrade_testing/postgres_14/new_pg
On Wed, Jun 28, 2023 at 11:54 AM
Hi,
This is a WIP patch to add WAL write and fsync stats to pg_stat_io
view. There is a track_io_timing variable to control pg_stat_io
timings and a track_wal_io_timing variable to control WAL timings. I
couldn't decide on which logic to enable WAL timings on pg_stat_io.
For now, both pg_stat_io
On 28.06.23 08:24, Laurenz Albe wrote:
On Wed, 2023-06-28 at 11:49 +0530, Pradeep Kumar wrote:
I was under the impression that the --link option would create hard links
between the
old and new cluster's data files, but it appears that the entire old cluster
data was
copied to the new cluster,
On Wed, 28 Jun 2023 at 20:13, Peter Eisentraut wrote:
> size_t (= Size) is the correct type in C to store the size of an object
> in memory. This is partially a self-documentation issue: If I see
> size_t in a function signature, I know what is intended; if I see
> uint32, I have to wonder what
HI,
On Jun 28, 2023, 17:26 +0800, Julien Rouhaud , wrote:
> On Wed, Jun 28, 2023 at 05:17:14PM +0800, Julien Rouhaud wrote:
> > >
> > > Table t1 and t2 both has 2 columns: c1, c2, when CTE join select *, the
> > > result target list seems to lost one’s column c1.
> > > But it looks good when
On Wed, Jun 28, 2023 at 05:17:14PM +0800, Julien Rouhaud wrote:
> >
> > Table t1 and t2 both has 2 columns: c1, c2, when CTE join select *, the
> > result target list seems to lost one’s column c1.
> > But it looks good when select cte1.* and t1.* explicitly .
> >
> > Is it a bug?
>
> This is
Hi
Regards,
Zhang Mingli
On Jun 28, 2023, 17:17 +0800, Julien Rouhaud , wrote:
> This is working as intended. When using a USING clause you "merge" both
> columns so the final target list only contain one version of the merged
> columns, which doesn't happen if you use e.g. ON instead. I'm
Hi,
On Wed, Jun 28, 2023 at 04:52:34PM +0800, Zhang Mingli wrote:
>
> Mini repo
>
> create table t1(c1 int, c2 int);
> CREATE TABLE
> create table t2(c1 int, c2 int);
> CREATE TABLE
> explain with cte1 as (insert into t2 values (1, 2) returning *) select * from
> cte1 join t1 using(c1);
> QUERY
Hi,
Explain verbose, seems HashJoin node drop that column.
gpadmin=# explain(verbose) with cte1 as (insert into t2 values (1, 2) returning
*) select * from cte1 join t1 using(c1);
QUERY PLAN
---
Hash Join (cost=0.04..41.23
Hi,
Mini repo
create table t1(c1 int, c2 int);
CREATE TABLE
create table t2(c1 int, c2 int);
CREATE TABLE
explain with cte1 as (insert into t2 values (1, 2) returning *) select * from
cte1 join t1 using(c1);
QUERY PLAN
Hash
On Wed, Jun 28, 2023, at 08:26, jian he wrote:
> Hi there.
> I changed the function hashset_contains to strict.
Changing hashset_contains to STRICT would cause it to return NULL
if any of the operands are NULL, which I don't believe is correct, since:
SELECT NULL = ANY('{}'::int4[]);
?column?
On 27.06.23 17:54, Dagfinn Ilmari Mannsåker wrote:
However, the docs
(https://www.postgresql.org/docs/16/regress-tap.html#REGRESS-TAP-VARS)
say "If the environment variable PG_TEST_NOCLEAN is set", not "is set to
a true value", and the existing test in PostgreSQL::Test::Cluster's END
block is:
On 26.06.23 21:54, Andres Freund wrote:
For something like pg_list.h the malloc(free) attribute is a bit awkward to
use, because one a) needs to list ~30 functions that can free a list and b)
the referenced functions need to be declared.
Hmm. Saying list_concat() "deallocates" a list is
> On 31 May 2023, at 21:07, Sandro Santilli wrote:
> On Thu, Apr 27, 2023 at 12:49:57PM +0200, Sandro Santilli wrote:
>> I'm happy to bring back the control-file switch if there's an
>> agreement about that.
>
> I'm attaching an up-to-date version of the patch with the control-file
> switch
On Wed, Jun 28, 2023 at 3:36 PM Michael Paquier wrote:
> On Wed, Jun 28, 2023 at 03:09:55PM +0800, Richard Guo wrote:
> > +1. To nitpick, how about we remove the blank line just before removing
> > the key for top level entry?
> >
> > - /* Also remove entries for top level statements */
> > +
In memory contexts, block and chunk sizes are likely to be limited by
some upper bounds. Some examples of those bounds can be
MEMORYCHUNK_MAX_BLOCKOFFSET and MEMORYCHUNK_MAX_VALUE. Both values are
only 1 less than 1GB.
This makes memory contexts to have blocks/chunks with sizes less than
1GB.
On Wed, 28 Jun 2023 00:01:02 +0800
jian he wrote:
> On Thu, Jun 1, 2023 at 2:47 AM Yugo NAGATA wrote:
> >
> > On Thu, 1 Jun 2023 23:59:09 +0900
> > Yugo NAGATA wrote:
> >
> > > Hello hackers,
> > >
> > > Here's a rebased version of the patch-set adding Incremental View
> > > Maintenance
On Thu, 1 Jun 2023 12:18:47 -0500
Terry Brennan wrote:
> Hello all,
>
> I am a researcher in databases who would like to suggest a new function. I
> am writing to you because you have an active developer community. Your
> website said that suggestions for new functions should go to this
A quick scan of the archives doesn't turn up anyone who has volunteered in
advance to run the upcoming commitfest. Is anyone keen at trying their hand at
this very important community work? The July CF is good for anyone doing this
for the first time IMHO as it's usually less stressful than the
On Wed, Jun 28, 2023 at 03:09:55PM +0800, Richard Guo wrote:
> +1. To nitpick, how about we remove the blank line just before removing
> the key for top level entry?
>
> - /* Also remove entries for top level statements */
> + /* Also remove entries if exist for top level statements */
>
On Wed, Jun 28, 2023 at 09:20:27AM +0900, Kyotaro Horiguchi wrote:
> At Tue, 27 Jun 2023 18:58:39 -0500, David Christensen
> wrote in
>>> Adjusted as per the v2 attached.
>>
>> +1
>
> +1
Okay, cool. Both of you seem happy with it, so I have applied it.
Thanks for the quick checks.
--
Hi,
On Tue, Feb 21, 2023 at 4:12 PM Amit Langote wrote:
> On Tue, Feb 21, 2023 at 12:40 AM Tom Lane wrote:
> > Alvaro Herrera writes:
> > > On 2023-Feb-20, Amit Langote wrote:
> > >> One more thing we could try is come up with a postgres_fdw test case,
> > >> because it uses the
This email has no patch yet -- it's more of a placeholder to gather some
issues into one place. During previous work on replacing vacuum's bsearch'd
array for TID storage with a radix tree, Andres suggested [1] that the hash
table in tidbitmap.c should also be replaced. This will hopefully
On Wed, Jun 28, 2023 at 3:04 PM Michael Paquier wrote:
> On Wed, Jun 28, 2023 at 12:15:47PM +0800, Japin Li wrote:
> > - /* Remove the key if it exists, starting with the
> top-level entry */
> > + /* Remove the key if it exists, starting with the
> non-top-level entry
On Wed, Jun 28, 2023 at 12:15:47PM +0800, Japin Li wrote:
> - /* Remove the key if it exists, starting with the top-level
> entry */
> + /* Remove the key if it exists, starting with the non-top-level
> entry */
> key.toplevel = false;
> entry
On Wed, Jun 28, 2023 at 6:28 AM Tom Lane wrote:
> For a real fix, I'm inclined to extend the loop that calculates
> param_source_rels (in add_paths_to_joinrel) so that it also tracks
> a set of incompatible relids that *must not* be present in the
> parameterization of a proposed path. This
Hi,
On 6/26/23 12:34 PM, Amit Kapila wrote:
On Mon, Jun 26, 2023 at 11:15 AM Drouvot, Bertrand
wrote:
On 6/20/23 12:22 PM, Amit Kapila wrote:
On Mon, Jun 19, 2023 at 9:56 PM Drouvot, Bertrand
wrote:
In such a case (slot valid on the primary but invalidated on the standby) then
I think
On Tue, Jun 27, 2023 at 4:27 PM Joel Jacobson wrote:
>
> On Tue, Jun 27, 2023, at 04:35, jian he wrote:
> > in SQLMultiSets.pdf(previously thread) I found a related explanation
> > on page 45, 46.
> > /home/jian/hashset/0001-make-int4hashset_contains-strict-and-header-file-change.patch
> > (CASE
> On 23 Jun 2023, at 22:10, Cary Huang wrote:
>> Off the cuff that doesn't seem like a bad idea, but I wonder if we should add
>> them to pg_stat_ssl (or both) instead if we deem them valuable?
>
> I think the same information should be available to pg_stat_ssl as well.
> pg_stat_ssl can show
On Wed, 2023-06-28 at 11:49 +0530, Pradeep Kumar wrote:
> I was under the impression that the --link option would create hard links
> between the
> old and new cluster's data files, but it appears that the entire old cluster
> data was
> copied to the new cluster, resulting in a significant
Dear Postgres Hackers,
I hope this email finds you well. I am currently facing an issue while
performing an upgrade using the pg_upgrade utility with the --link option.
I was under the impression that the --link option would create hard links
between the old and new cluster's data files, but it
81 matches
Mail list logo
