Hi,
On 2020-08-26 15:58:14 +1200, Thomas Munro wrote:
> > --12.51%--compactify_tuples
> > PageRepairFragmentation
> > heap2_redo
> > StartupXLOG
>
> I wonder if there is something higher level that
On 2020-08-25 18:59, Tom Lane wrote:
Peter Eisentraut writes:
Here is a series of patches to remove some unused function parameters.
In each case, the need for them was removed by some other code changes
over time but the unusedness was not noticed. I have included a
reference to when they
On Tue, Aug 25, 2020 at 9:16 PM Jakub Wartak wrote:
> I just wanted to help testing this patch (defer SLRU fsyncs during recovery)
> and also faster compactify_tuples() patch [2] as both are related to the WAL
> recovery performance in which I'm interested in. This is my first message to
>
On Thu, 20 Aug 2020 at 17:42, Amit Kapila wrote:
>
> On Thu, Aug 20, 2020 at 12:32 PM Amit Kapila wrote:
> >
> > On Thu, Aug 20, 2020 at 12:18 PM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, 20 Aug 2020 at 14:01, Amit Kapila wrote:
> > > >
> > > > On Wed, Aug 19, 2020 at 12:54 PM Masahiko
On Wed, Aug 26, 2020 at 11:41:39AM +0900, Kyotaro Horiguchi wrote:
> At Tue, 25 Aug 2020 10:04:44 -0400, Bruce Momjian wrote in
> > I think there are a few problems here. In the docs, it says "will still
> > verify", but it doesn't say if it verifies the CA, or the CA _and_ the
> > CN/username.
At Tue, 25 Aug 2020 10:04:44 -0400, Bruce Momjian wrote in
> On Tue, Aug 25, 2020 at 03:53:20PM +0900, Kyotaro Horiguchi wrote:
> > At Mon, 24 Aug 2020 23:04:51 -0400, Bruce Momjian wrote
> > in
> > > > > I don't see "no-verify" mentioned anywhere in our docs.
> > > >
> > > > no-verify
Em ter., 25 de ago. de 2020 às 23:02, Kyotaro Horiguchi <
horikyota@gmail.com> escreveu:
> At Tue, 25 Aug 2020 10:20:07 -0300, Ranier Vilela
> wrote in
> > Hi Tom,
> >
> > Per Coverity.
> >
> > The function parse_hba_auth_op at (src/backend/libpq/hba.c) allows
> resource
> > leaks when
At Tue, 25 Aug 2020 10:20:07 -0300, Ranier Vilela wrote
in
> Hi Tom,
>
> Per Coverity.
>
> The function parse_hba_auth_op at (src/backend/libpq/hba.c) allows resource
> leaks when called
> by the function parse_hba_line, with parameters LOG and DEBUG3 levels.
> The function SplitGUCList
On 2020/08/25 11:39, Fujii Masao wrote:
On 2020/08/24 21:56, torikoshia wrote:
On 2020-08-24 13:13, Fujii Masao wrote:
On 2020/08/24 13:01, torikoshia wrote:
On 2020-08-22 21:18, Michael Paquier wrote:
Thanks for reviewing!
On Fri, Aug 21, 2020 at 11:27:06PM +0900, torikoshia wrote:
On Tue, Aug 25, 2020 at 11:51 PM Robert Haas wrote:
>
> On Tue, Aug 25, 2020 at 8:17 AM Masahiko Sawada
> wrote:
> > +
> > +
> > + While performing surgery on a damaged relation, we must not be doing
> > anything
> > + else on that relation in parallel. This is to ensure that when we are
>
On 2020/08/26 2:50, Andreas Karlsson wrote:
On 8/25/20 7:42 PM, Bruce Momjian wrote:
On Tue, Aug 25, 2020 at 12:59:31PM -0400, Tom Lane wrote:
Peter Eisentraut writes:
Here is a series of patches to remove some unused function parameters.
In each case, the need for them was removed by
Em ter., 25 de ago. de 2020 às 20:29, Alvaro Herrera <
alvhe...@2ndquadrant.com> escreveu:
> On 2020-Aug-25, Ranier Vilela wrote:
>
> > kkk, I think it's enough for me.
> > I believe that PostgreSQL will not run on the ISS yet.
>
> Actually, I believe there are some satellites that run Postgres
On Wed, 26 Aug 2020 at 05:18, Andy Fan wrote:
>
>
> On Tue, Aug 25, 2020 at 11:53 PM Andres Freund wrote:
>>
>> On 2020-08-25 20:48:37 +1200, David Rowley wrote:
>> > Also, just in case anyone is misunderstanding this Andres' argument.
>> > It's entirely based on the performance impact of having
On 2020-Aug-25, Ranier Vilela wrote:
> Em ter., 25 de ago. de 2020 às 19:45, Alvaro Herrera <
> alvhe...@2ndquadrant.com> escreveu:
>
> > On 2020-Aug-25, Ranier Vilela wrote:
> >
> > > If the variable hscan->rs_cblock is InvalidBlockNumber the test can
> > > protect root_offsets fail.
> >
> >
On 2020-Aug-25, Ranier Vilela wrote:
> 1. Even heap_get_root_tuples at line 1347, be called.
> Does it fill all roots_offsets?
Yes -- read the comments there.
> 2. hscan->rs_cbuf is constant?
> if (hscan->rs_cblock != root_blkno)
It is the buffer that contains the given block. Those two
On Tue, Aug 25, 2020 at 6:21 AM Stephen Frost wrote:
> This all definitely sounds quite interesting and the idea to look at the
> XID to see if we're in the same transaction and therefore likely
> inserting a related tuple certainly makes some sense. While I get that
> it might not specifically
Em ter., 25 de ago. de 2020 às 20:20, Alvaro Herrera <
alvhe...@2ndquadrant.com> escreveu:
> On 2020-Aug-25, Ranier Vilela wrote:
>
> > And it is guaranteed that, rs_cblock is not InvalidBlockNumber when the
> > page is read?
>
> It could be InvalidBlockNumber if sufficient neutrinos hit the
On 2020-Aug-25, Ranier Vilela wrote:
> kkk, I think it's enough for me.
> I believe that PostgreSQL will not run on the ISS yet.
Actually, I believe there are some satellites that run Postgres -- not
100% sure about this.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL
On 2020-Aug-25, Ranier Vilela wrote:
> And it is guaranteed that, rs_cblock is not InvalidBlockNumber when the
> page is read?
It could be InvalidBlockNumber if sufficient neutrinos hit the memory
bank and happen to set all the bits in the block number.
--
Álvaro Herrera
Em ter., 25 de ago. de 2020 às 20:13, Alvaro Herrera <
alvhe...@2ndquadrant.com> escreveu:
> On 2020-Aug-25, Ranier Vilela wrote:
>
> > Em ter., 25 de ago. de 2020 às 19:45, Alvaro Herrera <
> > alvhe...@2ndquadrant.com> escreveu:
> >
> > > On 2020-Aug-25, Ranier Vilela wrote:
> > >
> > > > If
Em ter., 25 de ago. de 2020 às 19:54, Ranier Vilela
escreveu:
> Em ter., 25 de ago. de 2020 às 19:45, Alvaro Herrera <
> alvhe...@2ndquadrant.com> escreveu:
>
>> On 2020-Aug-25, Ranier Vilela wrote:
>>
>> > If the variable hscan->rs_cblock is InvalidBlockNumber the test can
>> > protect
I can confirm that this two-month old email report still produces
different results with indexes on/off in git master, which I don't think
is ever correct behavior.
---
On Wed, Jun 24, 2020 at 03:11:03PM -0700, Jesse Zhang
Em ter., 25 de ago. de 2020 às 19:45, Alvaro Herrera <
alvhe...@2ndquadrant.com> escreveu:
> On 2020-Aug-25, Ranier Vilela wrote:
>
> > If the variable hscan->rs_cblock is InvalidBlockNumber the test can
> > protect root_offsets fail.
>
> When does that happen?
>
At first pass into the while
On Wed, 26 Aug 2020 at 01:18, Tomas Vondra wrote:
>
> On Wed, Aug 26, 2020 at 12:51:37AM +1200, David Rowley wrote:
> >I noticed today there are a few places where we use bms_num_memebers()
> >where we really should be using bms_membership(). These are not bugs,
> >they're mostly just bad
On 2020-Aug-25, Ranier Vilela wrote:
> If the variable hscan->rs_cblock is InvalidBlockNumber the test can
> protect root_offsets fail.
When does that happen?
> The var root_blkno only is checked at line 1853.
That's a different function.
--
Álvaro Herrera
Em ter., 25 de ago. de 2020 às 18:06, Alvaro Herrera <
alvhe...@2ndquadrant.com> escreveu:
> On 2020-Aug-25, Ranier Vilela wrote:
>
> > The variable root_offsets is read at line 1641, but, at this point,
> > the content is unknown, so it is impossible to test works well.
>
> Surely it is set by
On 2020-Aug-25, Ranier Vilela wrote:
> The variable root_offsets is read at line 1641, but, at this point,
> the content is unknown, so it is impossible to test works well.
Surely it is set by heap_get_root_tuples() in line 1347? The root_blkno
variable is used exclusively to know whether
On Sat, Jul 4, 2020 at 08:47:53AM +0200, Fabien COELHO wrote:
>
> Hello Peter,
>
> > The original stylesheets explicitly go out of their way to do it that
> > way. We can easily fix that by removing that special case. See attached
> > patch.
> >
> > That patch only fixes it for the header.
On Mon, Aug 24, 2020 at 3:35 PM Andres Freund wrote:
> To avoid unnecessary backward compat pains it seems best to first
> introduce compat wrappers using the current signature, and then
> subsequently replace in-core callers with the direct calls.
I like the idea of doing this, purely to make
Hi,
On 2020-08-25 14:22:28 -0400, Robert Haas wrote:
> On Tue, Aug 25, 2020 at 2:17 PM Andres Freund wrote:
> > It seems easy enough to slap a compiler "enforced" deprecation warning
> > on the new compat version, in master only. Seems unnecessary to make
> > life immediately harder for
On Tue, Aug 25, 2020 at 2:17 PM Andres Freund wrote:
> It seems easy enough to slap a compiler "enforced" deprecation warning
> on the new compat version, in master only. Seems unnecessary to make
> life immediately harder for extensions authors desiring cross-version
> compatibility.
I don't
On Tue, Aug 25, 2020 at 8:17 AM Masahiko Sawada
wrote:
> +
> +
> + While performing surgery on a damaged relation, we must not be doing
> anything
> + else on that relation in parallel. This is to ensure that when we are
> + operating on a damaged tuple there is no other transaction trying
Hi,
On 2020-08-25 13:59:35 -0400, Robert Haas wrote:
> On Mon, Aug 24, 2020 at 6:35 PM Andres Freund wrote:
> > Thoughts?
>
> This is likely to cause a certain amount of annoyance to many
> PostgreSQL developers, but if you have evidence that it will improve
> performance significantly, I think
Hi,
I couldn't test the patch as it does not apply cleanly on master.
The CF bot is green, and I can apply v2 cleanly FWIW:
http://commitfest.cputube.org/michael-paquier.html
Sorry, I didn't apply correctly. The tests pass for me. In addition, I
tested
with partitioned tables. It
On Tue, Aug 25, 2020 at 10:15 AM Ranier Vilela wrote:
> If variable htids is accessed like array, but is a simple pointer, can be
> "This might corrupt or misinterpret adjacent memory locations."
This exact Coverity complaint has already been discussed, and marked
as a false positive on the
On Mon, Aug 24, 2020 at 6:35 PM Andres Freund wrote:
> Thoughts?
This is likely to cause a certain amount of annoyance to many
PostgreSQL developers, but if you have evidence that it will improve
performance significantly, I think it's very reasonable to do it
anyway. However, if we do it all in
On 8/25/20 7:42 PM, Bruce Momjian wrote:
On Tue, Aug 25, 2020 at 12:59:31PM -0400, Tom Lane wrote:
Peter Eisentraut writes:
Here is a series of patches to remove some unused function parameters.
In each case, the need for them was removed by some other code changes
over time but the
On Mon, Aug 24, 2020 at 2:12 AM Dilip Kumar wrote:
> IIUC, the main reason for using this flag is for taking the decision
> whether we need any detoasting for this tuple. For example, if we are
> rewriting the table because the compression method is changed then if
> HEAP_HASCUSTOMCOMPRESSED
On Tue, Aug 25, 2020 at 12:59:31PM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > Here is a series of patches to remove some unused function parameters.
> > In each case, the need for them was removed by some other code changes
> > over time but the unusedness was not noticed. I have
On Tue, Aug 25, 2020 at 11:53 PM Andres Freund wrote:
> Hi,
>
> On 2020-08-25 20:48:37 +1200, David Rowley wrote:
> > On Tue, 25 Aug 2020 at 08:26, Andres Freund wrote:
> > > While I'm against introducing a separate node for the caching, I'm
> *not*
> > > against displaying a different node
On Tue, Aug 25, 2020 at 11:53 PM Andres Freund wrote:
> Hi,
>
> On 2020-08-25 20:48:37 +1200, David Rowley wrote:
> > On Tue, 25 Aug 2020 at 08:26, Andres Freund wrote:
> > > While I'm against introducing a separate node for the caching, I'm
> *not*
> > > against displaying a different node
Hi,
Per Coverity.
ARRAY vs SINGLETON
If variable htids is accessed like array, but is a simple pointer, can be
"This might corrupt or misinterpret adjacent memory locations."
at line 723:
/* Form standard non-pivot tuple */
itup->t_info &= ~INDEX_ALT_TID_MASK;
htids = >t_tid;
1. Here htids is
On 8/24/20 4:42 PM, Andres Freund wrote:
>
> This test is really hairy, which isn't great. But until we have a proper
> framework for controlling server side execution, I am not sure how we
> better can achieve test coverage for this stuff. And there've been bugs,
> so it's worth testing.
>
Peter Eisentraut writes:
> Here is a series of patches to remove some unused function parameters.
> In each case, the need for them was removed by some other code changes
> over time but the unusedness was not noticed. I have included a
> reference to when they became unused in each case.
Peter Eisentraut writes:
> On 2020-07-24 15:23, Tom Lane wrote:
>> Sounds good. Do we want to try Noah's idea of temporarily committing
>> the remaining changes, to see if the buildfarm is happy?
> I think to get value out of this you'd have to compare the config.status
> output files (mainly
Hi Tom,
Per Coverity.
The variable root_offsets is read at line 1641, but, at this point,
the content is unknown, so it is impossible to test works well.
regards,
Ranier Vilela
fix_uninitialized_variable_heapam_handler.patch
Description: Binary data
I wrote:
> I've spent the day fooling around with a re-implementation of
> isolationtester that waits for all its controlled sessions to quiesce
> (either wait for client input, or block on a lock held by another
> session) before moving on to the next step. That was not a feasible
> approach
Hi,
On 2020-08-25 20:48:37 +1200, David Rowley wrote:
> On Tue, 25 Aug 2020 at 08:26, Andres Freund wrote:
> > While I'm against introducing a separate node for the caching, I'm *not*
> > against displaying a different node type when caching is
> > present. E.g. it'd be perfectly reasonable from
Hi Tom,
Per Coverity.
The SearchSysCache1 allows return NULL and at function AlterStatistics,
has one mistake, lack of, check of return, which enables a dereference NULL
pointer,
at function heap_modify_tuple.
While there is room for improvement.
Avoid calling SearchSysCache1 and table_open if
On Tue, Aug 25, 2020 at 6:27 PM Amit Kapila wrote:
>
> On Tue, Aug 25, 2020 at 10:41 AM Dilip Kumar wrote:
> >
> > On Tue, Aug 25, 2020 at 9:31 AM Amit Kapila wrote:
> > >
> > >
> > > I think the existing design is superior as it allows the flexibility
> > > to create transaction files in
On Tue, Aug 25, 2020 at 03:53:20PM +0900, Kyotaro Horiguchi wrote:
> At Mon, 24 Aug 2020 23:04:51 -0400, Bruce Momjian wrote in
> > > > I don't see "no-verify" mentioned anywhere in our docs.
> > >
> > > no-verify itself is mentioned here.
> > >
> > >
On 2020-07-24 15:23, Tom Lane wrote:
Peter Eisentraut writes:
On 2020-07-17 10:46, Peter Eisentraut wrote:
v1-0001-Rename-configure.in-to-configure.ac.patch
I have committed that, and I have sent feedback to the Autoconf
developers about our concerns about the slowness of some of the new
On 2020-08-02 23:18, Tom Lane wrote:
Thomas Gilligan writes:
Under the next version of macOS (11.0 unreleased beta 3), configuring Postgres
9.5 and 9.6 fails with
checking test program... ok
checking whether long int is 64 bits... no
checking whether long long int is 64 bits... no
The USE_OPENSSL_RANDOM macro is defined when OpenSSL is used as a randomness
provider, but the implementation of strong randomness is guarded by USE_OPENSSL
in most places. This is technically the same thing today, but it seems
hygienic to use the appropriate macro in case we ever want to allow
On Tue, 2020-08-25 at 13:48 +0200, Daniel Gustafsson wrote:
> > On 25 Aug 2020, at 12:20, Peter Eisentraut
> > wrote:
> >
> > A user tried to use the cracklib build-time option of the passwordcheck
> > module. This failed, as it turned out because there was no dictionary
> > installed in the
On 20/08/2020 11:32, Kyotaro Horiguchi wrote:
0002: Rewording that old->target and new->source makes the meaning far
clearer. Moving decisions core code into filemap_finalize is
reasonable.
By the way, some of the rules are remaining in
process_source/target_file. For example,
Hi Tom,
Per Coverity.
The function parse_hba_auth_op at (src/backend/libpq/hba.c) allows resource
leaks when called
by the function parse_hba_line, with parameters LOG and DEBUG3 levels.
The function SplitGUCList (src/bin/pg_dump/dumputils.c) allows even
returning FALSE,
that namelist list is
Greetings,
* Peter Geoghegan (p...@bowt.ie) wrote:
> On Mon, Aug 24, 2020 at 6:38 AM John Naylor
> wrote:
> > Other ideas?
>
> I've been experimenting with changing the way that we enforce heap
> fill factor with calls to heap_insert() (and even heap_update()) that
> happen to occur at a
On Wed, Aug 26, 2020 at 12:51:37AM +1200, David Rowley wrote:
I noticed today there are a few places where we use bms_num_memebers()
where we really should be using bms_membership(). These are not bugs,
they're mostly just bad examples to leave laying around, at best, and
a small performance
I noticed today there are a few places where we use bms_num_memebers()
where we really should be using bms_membership(). These are not bugs,
they're mostly just bad examples to leave laying around, at best, and
a small performance penalty, at worst.
Unless there are any objections, I plan to
Hi Masahiko-san,
Thank you for the review. Please check my comments inline below:
On Tue, Aug 25, 2020 at 1:39 PM Masahiko Sawada
wrote:
>
> On Fri, 21 Aug 2020 at 22:25, Ashutosh Sharma wrote:
> >
> > Hi Masahiko-san,
> >
> > Please find the updated patch with the following new changes:
> >
>
> On 17 Aug 2020, at 08:11, yuzuko wrote:
>
> I'm sorry for the late reply.
>
>> This version seems to fail under Werror which is used in the Travis builds:
>>
>> autovacuum.c: In function ‘relation_needs_vacanalyze’:
>> autovacuum.c:3117:59: error: ‘reltuples’ may be used uninitialized in
On Tue, 25 Aug 2020 at 17:08, Masahiko Sawada
wrote:
>
> On Fri, 21 Aug 2020 at 22:25, Ashutosh Sharma wrote:
> >
> > Hi Masahiko-san,
> >
> > Please find the updated patch with the following new changes:
> >
>
> Thank you for updating the patch!
>
> > 1) It adds the code changes in
> On 25 Aug 2020, at 12:20, Peter Eisentraut
> wrote:
>
> A user tried to use the cracklib build-time option of the passwordcheck
> module. This failed, as it turned out because there was no dictionary
> installed in the right place, but the error was not properly reported,
> because the
On 25/08/2020 20:48, David Rowley wrote:
On Tue, 25 Aug 2020 at 08:26, Andres Freund wrote:
While I'm against introducing a separate node for the caching, I'm *not*
against displaying a different node type when caching is
present. E.g. it'd be perfectly reasonable from my POV to have a 'Cached
A user tried to use the cracklib build-time option of the passwordcheck
module. This failed, as it turned out because there was no dictionary
installed in the right place, but the error was not properly reported,
because the existing code just throws away the error message from
cracklib.
On 14.07.2020 00:11, Anastasia Lubennikova wrote:
On 06.07.2020 13:45, Anastasia Lubennikova wrote:
The previous discussion of automatic partition creation [1] has
addressed static and dynamic creation of partitions and ended up with
several syntax proposals.
In this thread, I want to
út 25. 8. 2020 v 11:19 odesílatel Peter Smith
napsal:
> On Tue, Aug 25, 2020 at 4:58 PM Pavel Stehule
> wrote:
> > When you run ./unused_oids script, then you get this message
> >
> > [pavel@nemesis catalog]$ ./unused_oids
>
> > Patches should use a more-or-less consecutive range of OIDs.
> >
On Tue, Aug 25, 2020 at 4:58 PM Pavel Stehule wrote:
> When you run ./unused_oids script, then you get this message
>
> [pavel@nemesis catalog]$ ./unused_oids
> Patches should use a more-or-less consecutive range of OIDs.
> Best practice is to start with a random choice in the range 8000-.
>
On Wed, Aug 12, 2020 at 6:06 PM Thomas Munro wrote:
> [patch]
Hi Thomas / hackers,
I just wanted to help testing this patch (defer SLRU fsyncs during recovery)
and also faster compactify_tuples() patch [2] as both are related to the WAL
recovery performance in which I'm interested in. This is
> On 21 Aug 2020, at 08:02, Andrey V. Lepikhov
> wrote:
>
> On 7/1/20 2:10 PM, Daniel Gustafsson wrote:
>>> On 27 Dec 2019, at 08:34, Kohei KaiGai wrote:
>>> The attached v2 fixed the problem, and regression test finished correctly.
>> This patch no longer applies to HEAD, please submit an
On Tue, 25 Aug 2020 at 08:26, Andres Freund wrote:
> While I'm against introducing a separate node for the caching, I'm *not*
> against displaying a different node type when caching is
> present. E.g. it'd be perfectly reasonable from my POV to have a 'Cached
> Nested Loop' join and a plain
On Mon, Aug 24, 2020 at 9:33 PM osumi.takami...@fujitsu.com
wrote:
> I've fixed my v06 and created v07.
Hi Osumi-san.
I have reviewed the test code of the v07 patch.
Below are my comments.
COMMENT (confusing functions)
+create function before_replacement() returns trigger as $$
+begin
On Fri, 21 Aug 2020 at 22:25, Ashutosh Sharma wrote:
>
> Hi Masahiko-san,
>
> Please find the updated patch with the following new changes:
>
Thank you for updating the patch!
> 1) It adds the code changes in heap_force_kill function to clear an
> all-visible bit on the visibility map
On Mon, Aug 24, 2020 at 9:33 PM osumi.takami...@fujitsu.com
wrote:
> I've fixed my v06 and created v07.
Hi Osumi-san.
I have reviewed the source code of the v07 patch.
(I also reviewed the test cases but I will share those comments as a
separate post).
Below are my comments - sorry, many of
út 25. 8. 2020 v 9:32 odesílatel Pavel Stehule
napsal:
>
>
> po 24. 8. 2020 v 21:43 odesílatel Pavel Stehule
> napsal:
>
>>
>>
>> ne 23. 8. 2020 v 23:08 odesílatel Tom Lane napsal:
>>
>>> Pavel Stehule writes:
>>> > I am sending a patch that is years used in GoodData.
>>>
>>> I'm quite
po 24. 8. 2020 v 21:43 odesílatel Pavel Stehule
napsal:
>
>
> ne 23. 8. 2020 v 23:08 odesílatel Tom Lane napsal:
>
>> Pavel Stehule writes:
>> > I am sending a patch that is years used in GoodData.
>>
>> I'm quite unexcited about that. I'd be the first to agree that the
>> ten-pages estimate
On Aug 25, 2020, at 8:26 AM, Bruce Momjian
mailto:br...@momjian.us>> wrote:
Yes, I tested back to 9.5 too:
CREATE EXTENSION file_fdw;
CREATE SERVER pgconf FOREIGN DATA WRAPPER file_fdw;
CREATE FOREIGN TABLE pgconf (line TEXT) SERVER pgconf OPTIONS ( filename
'postgresql.conf', format 'text',
út 25. 8. 2020 v 1:19 odesílatel Peter Smith napsal:
> Hi.
>
> I have re-checked the string_to_table_20200824.patch.
>
>
>
> On Tue, Aug 25, 2020 at 2:34 AM Pavel Stehule
> wrote:
>
> >> COMMENT (help text)
> >>
> >> +Splits the string at occurrences
> >> +of delimiter and
At Mon, 24 Aug 2020 23:04:51 -0400, Bruce Momjian wrote in
> > > I don't see "no-verify" mentioned anywhere in our docs.
> >
> > no-verify itself is mentioned here.
> >
> > https://www.postgresql.org/docs/13/ssl-tcp.html#SSL-CLIENT-CERTIFICATES
>
> Oh, I see it now, thanks. Do you have any
80 matches
Mail list logo
