Re: Why forbid "INSERT INTO t () VALUES ();"

On 2020-06-25 18:07, Tom Lane wrote: So I'm still not convinced we should do this. "MySQL is incapable of conforming to the standard" is a really lousy reason for us to do something. Conformance to the standard means that the syntax described in the standard behaves as specified in the standa

Re: [patch] demote

Hello. At Thu, 25 Jun 2020 19:27:54 +0200, Jehan-Guillaume de Rorthais wrote in > Here is a summary of my work during the last few days on this demote approach. > > Please, find in attachment v2-0001-Demote-PoC.patch and the comments in the > commit message and as FIXME in code. > > The patch

Re: [patch] demote

Mmm. Fat finger.. At Fri, 26 Jun 2020 16:14:38 +0900 (JST), Kyotaro Horiguchi wrote in > Hello. > > If we are going to dive so close to server shutdown, we can just > utilize the restart-after-crash path, which we can assume to work > reliably. The attached is a quite rough sketch, hijacking s

Re: Ought to use heap_multi_insert() for pg_attribute/depend insertions?

On Thu, Jun 25, 2020 at 09:38:23AM +0200, Daniel Gustafsson wrote: > Attached is a rebased version which was updated to handle the changes for op > class parameters introduced in 911e70207703799605. Thanks for the updated version. While re-reading the code, I got cold feet with the changes done i

Re: PG 13 release notes, first draft

Hi, I realized that PG 13 release note still has the following entry: Add FOREIGN to ALTER statements, if appropriate (Luis Carril) WHAT IS THIS ABOUT? IIUC this entry is about that pg_dump adds FOREIGN word to ALTER TABLE command.

Re: Creating a function for exposing memory usage of backend process

Hi, On Fri, Jun 26, 2020 at 3:42 PM Bharath Rupireddy wrote: > While going through the mail chain on relation, plan and catalogue > caching [1], I'm thinking on the lines that is there a way to know the > current relation, plan and catalogue cache sizes? If there is a way > already, please ignor

Re: Transactions involving multiple postgres foreign servers, take 2

On Fri, Jun 26, 2020 at 10:50 AM Masahiko Sawada wrote: > > On Tue, 23 Jun 2020 at 13:26, Amit Kapila wrote: > > > > > > I think at this stage it is important that we do some study of various > > approaches to achieve this work and come up with a comparison of the > > pros and cons of each approa

Re: Resetting spilled txn statistics in pg_stat_replication

On Fri, Jun 26, 2020 at 11:31 AM Masahiko Sawada wrote: > > On Thu, 25 Jun 2020 at 19:35, Amit Kapila wrote: > > > > On Tue, Jun 23, 2020 at 6:39 PM Amit Kapila wrote: > > > > > > On Tue, Jun 23, 2020 at 3:48 PM Tomas Vondra > > > wrote: > > > > > > > > On Tue, Jun 23, 2020 at 10:58:18AM +0530,

Re: Resetting spilled txn statistics in pg_stat_replication

On Tue, Jun 23, 2020 at 12:18 PM Tomas Vondra wrote: > On Tue, Jun 23, 2020 at 10:58:18AM +0530, Amit Kapila wrote: > >On Tue, Jun 23, 2020 at 9:32 AM Masahiko Sawada > > wrote: > >> > >> On Sun, 21 Jun 2020 at 06:57, Tomas Vondra < > tomas.von...@2ndquadrant.com> wrote: > >> > > >> > > > >> > >W

Re: Remove a redundant condition check

On Thu, Jun 25, 2020 at 11:23 PM Ádám Balogh wrote: > > > A one line change to remove a duplicate check. This duplicate check was > detected during testing my contribution to a static code analysis tool. There > is no functional change, no new tests needed. > > Yeah, this duplicate check is add

Re: PostgreSQL 13 Beta 1 Release Announcement Draft

On 19/05/2020 04:29, Jonathan S. Katz wrote: > Hi, > > Attached is a draft of the release announcement for the PostgreSQL 13 > Beta 1 release this week. > > Hi, Maybe I'm too late, but in this paragraph : > `psql` now includes the `\warn` command that is similar to the `\echo` command > in terms

[PATCH] Remove Extra palloc Of raw_buf For Binary Format In COPY FROM

Hi Hackers, There seems to be an extra palloc of 64KB of raw_buf for binary format files which is not required as copy logic for binary files don't use raw_buf, instead, attribute_buf is used in CopyReadBinaryAttribute. Attached is a patch, which places a check to avoid this unnecessary 64KB pall

Re: [Patch] ALTER SYSTEM READ ONLY

On Fri, Jun 26, 2020 at 10:11:41AM +0530, Amul Sul wrote: > I think that's expected since the server isn't clean shutdown, similar error > can > be seen with any server which has been shutdown in immediate mode > (pg_clt -D data_dir -m i). Any operation working on on-disk relation blocks needs to

Re: Remove a redundant condition check

On Fri, Jun 26, 2020 at 02:39:22PM +0530, Amit Kapila wrote: > It seems we forgot to remove the additional check for switchedTLI > while adding a new check. I think we can remove this duplicate check > in the HEAD code. I am not sure if it is worth to backpatch such a > change. Yes, there is no

Re: [Patch] ALTER SYSTEM READ ONLY

On Fri, Jun 26, 2020 at 12:15 PM Michael Banck wrote: > > Hi, > > On Wed, Jun 24, 2020 at 01:54:29PM +0530, tushar wrote: > > On 6/22/20 11:59 AM, Amul Sul wrote: > > > 2. Now skipping the startup checkpoint if the system is read-only mode, as > > > discussed [2]. > > > > I am not able to perform

Re: Remove a redundant condition check

Em sex., 26 de jun. de 2020 às 06:09, Amit Kapila escreveu: > On Thu, Jun 25, 2020 at 11:23 PM Ádám Balogh > wrote: > > > > > > A one line change to remove a duplicate check. This duplicate check was > detected during testing my contribution to a static code analysis tool. > There is no function

Re: Windows regress fails (latest HEAD)

Em qui., 11 de jun. de 2020 às 10:28, Ranier Vilela escreveu: > Em qui., 11 de jun. de 2020 às 10:01, Andrew Dunstan < > andrew.duns...@2ndquadrant.com> escreveu: > >> >> On 6/11/20 8:52 AM, Ranier Vilela wrote: >> > Hi, >> > Latest HEAD, fails with windows regress tests. >> > >> > float8

Re: TAP tests and symlinks on Windows

On 2020-06-23 12:55, Michael Paquier wrote: I have implemented a patch based on the feedback received that does the following, tested with all three patterns (MSVC only on Windows): - Assume that all non-Windows platform have a proper symlink implementation for perl. - If on Windows, check for th

Re: Online checksums patch - once again

On Thu, Jun 25, 2020 at 5:43 AM Daniel Gustafsson wrote: > Sorry being a bit thick, can you elaborate which case you're thinking about? > CREATE TABLE sets the attribute according to the value of data_checksums, and > before enabling checksums (and before changing data_checksums to inprogress) > t

Re: pgsql: Enable Unix-domain sockets support on Windows

On Sat, Mar 28, 2020 at 7:37 PM Peter Eisentraut wrote: > > Enable Unix-domain sockets support on Windows > + +/* + * Windows headers don't define this structure, but you can define it yourself + * to use the functionality. + */ +struct sockaddr_un +{ + unsigned short sun_family; + char sun_p

Re: Ought to use heap_multi_insert() for pg_attribute/depend insertions?

> On 26 Jun 2020, at 10:11, Michael Paquier wrote: > > On Thu, Jun 25, 2020 at 09:38:23AM +0200, Daniel Gustafsson wrote: >> Attached is a rebased version which was updated to handle the changes for op >> class parameters introduced in 911e70207703799605. > > Thanks for the updated version. Tha

Re: should libpq also require TLSv1.2 by default?

> On 26 Jun 2020, at 00:44, Tom Lane wrote: > My feeling now is that we'd be better off defaulting > ssl_min_protocol_version to something nonempty, just to make this > behavior platform-independent. We certainly can't leave the docs > as they are. Yeah, given the concensus in this thread and y

Re: Online checksums patch - once again

> On 26 Jun 2020, at 14:12, Robert Haas wrote: > > On Thu, Jun 25, 2020 at 5:43 AM Daniel Gustafsson wrote: >> Sorry being a bit thick, can you elaborate which case you're thinking about? >> CREATE TABLE sets the attribute according to the value of data_checksums, and >> before enabling checksum

ModifyTable overheads in generic plans

Hi, I would like to discuss a refactoring patch that builds on top of the patches at [1] to address $subject. To get an idea for what eliminating these overheads looks like, take a look at the following benchmarking results. Note 1: I've forced the use of generic plan by setting plan_cache_mode

Re: xid wraparound danger due to INDEX_CLEANUP false

On Thu, Jun 25, 2020 at 8:44 PM Peter Geoghegan wrote: > I am sure about this much: The design embodied by Masahiko's patch is > clearly a better one overall, even if it doesn't fix the problem on > its own. I agree that we cannot allow nbtree to ignore "INDEX_CLEANUP > = off", even if that means

Re: [PATCH] Remove Extra palloc Of raw_buf For Binary Format In COPY FROM

On Fri, Jun 26, 2020 at 3:16 PM Bharath Rupireddy < bharath.rupireddyforpostg...@gmail.com> wrote: > Hi Hackers, > > There seems to be an extra palloc of 64KB of raw_buf for binary format > files which is not required > as copy logic for binary files don't use raw_buf, instead, attribute_buf > is

Re: [Patch] ALTER SYSTEM READ ONLY

On Fri, Jun 26, 2020 at 5:59 AM Michael Paquier wrote: > Any operation working on on-disk relation blocks needs to have a > consistent state, and a clean shutdown gives this guarantee thanks to > the shutdown checkpoint (see also pg_rewind). There are two states in > the control file, shutdown fo

RE: Remove a redundant condition check

Hello, -Original Message- From: Amit Kapila Sent: 2020. június 26., péntek 11:09 To: Ádám Balogh Cc: PostgreSQL Hackers Subject: Re: Remove a redundant condition check >On Thu, Jun 25, 2020 at 11:23 PM Ádám Balogh wrote: >> >> >> A one line change to remove a duplicate check. This du

Re: should libpq also require TLSv1.2 by default?

Daniel Gustafsson writes: >> On 26 Jun 2020, at 00:44, Tom Lane wrote: >> BTW, the server-side report of the problem looks like >> LOG: could not accept SSL connection: wrong version number > I can totally see some thinking that it's the psql version at client side > which > is referred to and

pg_dump bug for extension owned tables

Found when working against release 12. Given the following extension: :: share/postgresql/extension/dummy--1.0.0.sql :: -- complain if script is sourced in psql, rather than via CREATE EXTENSION \echo Use "CREATE EXTENSION dummy" to load this file. \quit CREATE TABLE

Re: pg_dump bug for extension owned tables

On 6/26/20 9:57 AM, Andrew Dunstan wrote: > It appears that for extension owned tables tbinfo.attgenerated isn't > being properly populated, so line 2050 in REL_12_STABLE, which is line > 2109 in git tip, is failing. > > Should have mentioned this is in src/bin/pg_dump/pg_dump.c cheers andre

Possible NULL dereferencing (src/backend/tcop/pquery.c)

Hi, Per Coverity. Perhaps it is excessive caution. Probably assertion check has already caught all possible errors. But, redundancy may not cost as much and is worth it. 1.Assertion check /* Caller messed up if we have neither a ready query nor held data. */ Assert(queryDesc || portal->holdStore)

Re: Default setting for enable_hashagg_disk

On Fri, Jun 26, 2020 at 12:02:10AM -0400, Bruce Momjian wrote: On Fri, Jun 26, 2020 at 01:53:57AM +0200, Tomas Vondra wrote: I'm not saying it's not beneficial to use different limits for different nodes. Some nodes are less sensitive to the size (e.g. sorting often gets faster with smaller work

Re: pg_dump bug for extension owned tables

On Fri, Jun 26, 2020 at 11:24 AM Andrew Dunstan < andrew.duns...@2ndquadrant.com> wrote: > > > On 6/26/20 9:57 AM, Andrew Dunstan wrote: > > It appears that for extension owned tables tbinfo.attgenerated isn't > > being properly populated, so line 2050 in REL_12_STABLE, which is line > > 2109 in gi

Re: should libpq also require TLSv1.2 by default?

Here is a quick attempt at getting libpq and the server to report suitable hint messages about SSL version problems. The main thing I don't like about this as formulated is that I hard-wired knowledge of the minimum and maximum SSL versions into the hint messages. That's clearly not very maintaina

Re: Default setting for enable_hashagg_disk

On Fri, Jun 26, 2020 at 04:44:14PM +0200, Tomas Vondra wrote: > On Fri, Jun 26, 2020 at 12:02:10AM -0400, Bruce Momjian wrote: > > On Fri, Jun 26, 2020 at 01:53:57AM +0200, Tomas Vondra wrote: > > > I'm not saying it's not beneficial to use different limits for different > > > nodes. Some nodes are

Re: bugfix: invalid bit/varbit input causes the log file to be unreadable

Quan Zongliang writes: > The reason is that the error message in the bit_in / varbit_in function > is output directly using %c. Causes the log file to not be decoded > correctly. > The attachment is a patch. I'm really quite skeptical of the premise here. We do not guarantee that the postmast

Re: PG 13 release notes, first draft

On Fri, Jun 26, 2020 at 05:24:16PM +0900, Masahiko Sawada wrote: > Hi, > > I realized that PG 13 release note still has the following entry: > > > > >Add FOREIGN to ALTER statements, >if appropriate (Luis Carril) > > > >WHAT IS THIS ABOUT? >

Re: Default setting for enable_hashagg_disk

On Fri, Jun 26, 2020 at 12:37:26PM -0400, Bruce Momjian wrote: On Fri, Jun 26, 2020 at 04:44:14PM +0200, Tomas Vondra wrote: On Fri, Jun 26, 2020 at 12:02:10AM -0400, Bruce Momjian wrote: > On Fri, Jun 26, 2020 at 01:53:57AM +0200, Tomas Vondra wrote: > > I'm not saying it's not beneficial to us

Re: pg_dump bug for extension owned tables

On Fri, Jun 26, 2020 at 11:55 AM Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: > > > On Fri, Jun 26, 2020 at 11:24 AM Andrew Dunstan < andrew.duns...@2ndquadrant.com> wrote: > > > > > > On 6/26/20 9:57 AM, Andrew Dunstan wrote: > > > It appears that for extension owned tables tbinfo.att

Re: PG 13 release notes, first draft

On 2020-Jun-26, Bruce Momjian wrote: > On Fri, Jun 26, 2020 at 05:24:16PM +0900, Masahiko Sawada wrote: > > Author: Alvaro Herrera > > 2020-03-20 [4e6209134] pg_dump: Add FOREIGN to ALTER statements, if > > appropriate > > --> > > > > > >Add FOREIGN to ALTER > > statements, > >

Re: should libpq also require TLSv1.2 by default?

I wrote: > Anybdy have a better idea? Is there a reasonably direct way to ask > OpenSSL what its min and max versions are? After some digging, there apparently is not. At first glance it would seem that SSL_get_min_proto_version/SSL_get_max_proto_version should help, but in reality they're just

Re: PG 13 release notes, first draft

Reading Luis Carril's other entry in the relnotes, Allow pg_dump --include-foreign-data to dump data from foreign servers (Luis Carril) It seems to suggest that --include-foreign-data existed previously, which is not true. I would have worded it as "Add --include-foreign-data option to pg_dump

Re: Why forbid "INSERT INTO t () VALUES ();"

Hello Isaac, This is not the only area where empty tuples are not supported. Consider: PRIMARY KEY () This should mean the table may only contain a single row, but is not supported. Yep. This is exactly the kind of case about which I was trying the command, after reading Bruce Momjian blo

Re: Default setting for enable_hashagg_disk

On Thu, Jun 25, 2020 at 1:36 PM Andres Freund wrote: > 12 28164.865 ms > > fast ssd: > HEAD92520.680 ms > > magnetic: > HEAD183968.538 ms > > (no reads, there's plenty enough memory. Just writes because the age / > amount thresholds for dirty data are reached) > > In the magnetic case

Re: [PATCH] Allow to specify restart_lsn in pg_create_physical_replication_slot()

On 2020-06-23 04:18, Michael Paquier wrote: On Mon, Jun 22, 2020 at 08:18:58PM +0300, Alexey Kondratov wrote: Things get worse when we allow specifying an older LSN, since it has a higher chances to be at the horizon of deletion by checkpointer. Anyway, if I get it correctly, with a current pat

Re: should libpq also require TLSv1.2 by default?

> On 26 Jun 2020, at 22:22, Tom Lane wrote: > > I wrote: >> Anybdy have a better idea? Is there a reasonably direct way to ask >> OpenSSL what its min and max versions are? > > After some digging, there apparently is not. AFAIK everyone either #ifdef around the TLS1_x_VERSION macros or the Ope

Re: Possible NULL dereferencing (src/backend/tcop/pquery.c)

Ranier Vilela writes: > 1.Assertion check > /* Caller messed up if we have neither a ready query nor held data. */ > Assert(queryDesc || portal->holdStore); > But in release, if QueryDesc is NULL and portal->holdStore is NULL too, > when Call PushActiveSnapshot *deference* NULL check can happen.

Re: should libpq also require TLSv1.2 by default?

Daniel Gustafsson writes: > SSL_R_UNKNOWN_PROTOCOL seem to covers cases when someone manages to perform > something which OpenSSL believes is a broken SSLv2 connection, but their own > client-level code use it to refer to SSL as well as TLS. Maybe it's worth > adding as a belts and suspenders typ

Re: pg_dump bug for extension owned tables

On 6/26/20 2:10 PM, Fabrízio de Royes Mello wrote: > > On Fri, Jun 26, 2020 at 11:55 AM Fabrízio de Royes Mello > mailto:fabriziome...@gmail.com>> wrote: > > > > > > On Fri, Jun 26, 2020 at 11:24 AM Andrew Dunstan > > wrote: > > > > > > > > > On 6/26/20 9:5

Re: Weird failures on lorikeet

On 6/25/20 2:42 PM, Andrew Dunstan wrote: > On 6/25/20 12:52 PM, Alvaro Herrera wrote: >> Is there something going on with lorikeet again? I see this: >> >> 2020-06-25 01:55:13.380 EDT [5ef43c40.21e0:85] pg_regress/typed_table LOG: >> statement: SELECT c.oid::pg_catalog.regclass >> FROM p

Re: PG 13 release notes, first draft

On Fri, Jun 26, 2020 at 04:23:26PM -0400, Alvaro Herrera wrote: > Reading Luis Carril's other entry in the relnotes, > > Allow pg_dump --include-foreign-data to dump data from foreign servers (Luis > Carril) > > It seems to suggest that --include-foreign-data existed previously, > which is not

Re: Default setting for enable_hashagg_disk

On Fri, Jun 26, 2020 at 07:45:13PM +0200, Tomas Vondra wrote: > On Fri, Jun 26, 2020 at 12:37:26PM -0400, Bruce Momjian wrote: > > I was thinking more of being able to allocate a single value to be > > shared by all active sesions. > > Not sure I understand. What "single value" do you mean? I was

Re: xid wraparound danger due to INDEX_CLEANUP false

On Fri, Jun 26, 2020 at 5:39 AM Robert Haas wrote: > My opinion is that there's no need to change the code in the > back-branches, and that I don't really like the approach in master > either. I guess it's hard to see a way that we could fix this in the backbranches, provided we aren't willing to

Re: Possible NULL dereferencing (src/backend/tcop/pquery.c)

Em sex., 26 de jun. de 2020 às 18:24, Tom Lane escreveu: > Ranier Vilela writes: > > 1.Assertion check > > /* Caller messed up if we have neither a ready query nor held data. */ > > Assert(queryDesc || portal->holdStore); > > > But in release, if QueryDesc is NULL and portal->holdStore is NULL t

Re: Default setting for enable_hashagg_disk

On Fri, Jun 26, 2020 at 4:00 PM Bruce Momjian wrote: > Imagine we set the cluster-wide total of work_mem to 1GB. If a session > asks for 100MB, if there are no other active sessions, it can grant the > entire 100MB. If there are other sessions running, and 500MB has > already been allocated, may

Re: Default setting for enable_hashagg_disk

On Fri, Jun 26, 2020 at 01:53:05PM -0700, Peter Geoghegan wrote: > On Thu, Jun 25, 2020 at 1:36 PM Andres Freund wrote: > > 12 28164.865 ms > > > > fast ssd: > > HEAD92520.680 ms > > > > magnetic: > > HEAD183968.538 ms > > > > (no reads, there's plenty enough memory. Just writes becau

Re: Default setting for enable_hashagg_disk

On Fri, Jun 26, 2020 at 07:00:20PM -0400, Bruce Momjian wrote: On Fri, Jun 26, 2020 at 07:45:13PM +0200, Tomas Vondra wrote: On Fri, Jun 26, 2020 at 12:37:26PM -0400, Bruce Momjian wrote: > I was thinking more of being able to allocate a single value to be > shared by all active sesions. Not su

Re: Default setting for enable_hashagg_disk

On Sat, Jun 27, 2020 at 01:58:50AM +0200, Tomas Vondra wrote: > > Since work_mem affect the optimizer choices, I can imagine it getting > > complex since nodes would have to ask the global work_mem allocator how > > much memory it _might_ get, but then ask for final work_mem during > > execution, a

Re: Default setting for enable_hashagg_disk

On Fri, Jun 26, 2020 at 4:59 PM Tomas Vondra wrote: > I agree larger work_mem for hashagg (and thus less spilling) may mean > lower work_mem for so some other nodes that are less sensitive to this. > But I think this needs to be formulated as a cost-based decision, > although I don't know how to d

Re: Review for GetWALAvailability()

On 2020-Jun-25, Kyotaro Horiguchi wrote: > It is error-prone restriction, as discussed before. > > Without changing updator-side, invalid restart_lsn AND valid > invalidated_at can be regarded as the lost state. With the following > change suggested by Fujii-san we can avoid the confusing status.

Added tab completion for the missing options in copy statement

Hi, I found that tab completion for some parts of the copy statement was missing. The Tab completion was missing for the following cases: 1) COPY [BINARY] FROM filename -> "BINARY", "DELIMITER", "NULL", "CSV", "ENCODING", "WITH (", "WHERE" should be shown. 2) COPY [BINARY] TO filename -> "BINARY

Re: [PATCH] Remove Extra palloc Of raw_buf For Binary Format In COPY FROM

On Fri, Jun 26, 2020 at 6:15 PM Rushabh Lathia wrote: > > > > On Fri, Jun 26, 2020 at 3:16 PM Bharath Rupireddy > wrote: >> >> Hi Hackers, >> >> There seems to be an extra palloc of 64KB of raw_buf for binary format >> files which is not required >> as copy logic for binary files don't use raw_b

Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit

On Mon, Jun 22, 2020 at 11:26 AM Bharath Rupireddy wrote: > > Hi, > > When a query on foreign table is executed from a local session using > postgres_fdw, as expected the local postgres backend opens a > connection which causes a remote session/backend to be opened on the > remote postgres server

Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit

On Mon, Jun 22, 2020 at 11:26 AM Bharath Rupireddy wrote: > Attached the initial patch(based on commit > 9550ea3027aa4f290c998afd8836a927df40b09d), test setup. > make check is failing sysviews.out 2020-06-27 07:22:32.162146320 +0530 @@ -73,6 +73,7 @@ name | setting

Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit

On Sun, Jun 21, 2020 at 10:56 PM Bharath Rupireddy < bharath.rupireddyforpostg...@gmail.com> wrote: > When a query on foreign table is executed from a local session using > postgres_fdw, as expected the local postgres backend opens a > connection which causes a remote session/backend to be opened

Re: [PATCH] Remove Extra palloc Of raw_buf For Binary Format In COPY FROM

Thanks Rushabh and Vignesh for the comments. > > One comment: > We could change below code: > + */ > + if (!cstate->binary) > + cstate->raw_buf = (char *) palloc(RAW_BUF_SIZE + 1); > + else > + cstate->raw_buf = NULL; > to: > cstate->raw_buf = (cstate->binary) ? NULL : (char *) palloc(RAW_BUF_SIZE

Re: xid wraparound danger due to INDEX_CLEANUP false

On Sat, 27 Jun 2020 at 08:00, Peter Geoghegan wrote: > > On Fri, Jun 26, 2020 at 5:39 AM Robert Haas wrote: > > My opinion is that there's no need to change the code in the > > back-branches, and that I don't really like the approach in master > > either. > > I guess it's hard to see a way that w

Re: Remove a redundant condition check

On Fri, Jun 26, 2020 at 3:32 PM Michael Paquier wrote: > > On Fri, Jun 26, 2020 at 02:39:22PM +0530, Amit Kapila wrote: > > It seems we forgot to remove the additional check for switchedTLI > > while adding a new check. I think we can remove this duplicate check > > in the HEAD code. I am not su