Hi,
On February 3, 2022 9:04:04 PM PST, Justin Pryzby wrote:
>On Thu, Feb 03, 2022 at 11:57:18AM -0800, Andres Freund wrote:
>> On 2022-02-02 21:58:28 -0600, Justin Pryzby wrote:
>> > FYI: I've rebased these against your cirrus/windows changes.
>>
>> What's the idea behind
>> #echo 'deb
Hi,
On Thu, Feb 03, 2022 at 10:42:32PM -0300, Alvaro Herrera wrote:
> On 2022-Feb-03, Pavel Stehule wrote:
>
> > The biggest problem is coexistence of Postgres's SEARCH_PATH object
> > identification, and local and public scopes used in MODULEs or in Oracle's
> > packages.
> >
> > I can
On Wed, Feb 02, 2022 at 08:15:02AM -0500, Robert Haas wrote:
> On Tue, Feb 1, 2022 at 5:36 PM Nathan Bossart
> wrote:
>> I can work on a new patch if this is the direction we want to go. There
>> were a couple of functions that called GetMaxBackends() repetitively that I
>> should probably fix
I'm chiming in a little late here, but as someone who worked on a
system to basically work around the lack of unprivileged CREATE ROLE
for a cloud provider (I worked on the Heroku Data team for several
years), I thought it might be useful to offer my perspective. This is,
of course, not the only
On Thu, Feb 03, 2022 at 11:57:18AM -0800, Andres Freund wrote:
> On 2022-02-02 21:58:28 -0600, Justin Pryzby wrote:
> > FYI: I've rebased these against your cirrus/windows changes.
>
> Did you put then on a dedicated branch, or only intermixed with other changes?
Yes it's intermixed (because I
On Thu, Feb 03, 2022 at 07:26:01PM -0800, Andres Freund wrote:
> Which reminds me: Perhaps we ought to hint about reducing / removing
> autovacuum cost limits in this situation? And perhaps make autovacuum absorb
> config changes while running? It's annoying that an autovac halfway into a
> huge
On Wed, Feb 2, 2022 at 7:39 AM David G. Johnston
wrote:
> I would at least consider having the UX go something like:
>
> postgres=# ALTER SYSTEM SET shared_preload_libraries = not_such_library;
> ERROR: that library is not present>.
> HINT: to bypass the error please add FORCE before SET
>
On Thu, Feb 3, 2022 at 3:25 PM Peter Eisentraut
wrote:
>
> On 02.02.22 07:54, Amit Kapila wrote:
>
> > Sure, but is this the reason you want to store all the error info in
> > the system catalog? I agree that providing more error info could be
> > useful and also possibly the previously failed
Hi,
On 2022-02-03 21:08:03 -0500, Robert Haas wrote:
> On Thu, Feb 3, 2022 at 8:35 PM Andres Freund wrote:
> > We can compute the:
> > 1) oldest slot by xmin, with name
> > 2) oldest walsender by xmin, with pid
> > 3) oldest prepared transaction id by xid / xmin, with name
> > 4) oldest
On Thu, 3 Feb 2022 at 15:38, Andres Freund wrote:
> I've pushed the patch this thread is about now. Lets see what the buildfarm
> says. I only could one windows version. Separately I've also pushed a patch
> to run the windows tests under a timeout. I hope in combination these patches
> address
On 2/4/22 03:47, Tomas Vondra wrote:
./json-generate.py 3 2 8 1000 6 1000
Sorry, this should be (different order of parameters):
./json-generate.py 3 2 1000 8 6 1000
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 1/25/22 17:56, Mahendra Singh Thalor wrote:
>
...
For the last few days, I was trying to understand these patches, and
based on Tomas's suggestion, I was doing some performance tests.
With the attached .SQL file, I can see that analyze is taking more time
with these patches.
*Setup:
I added a commitfest entry for this to try to attract Windows-hacker
reviews. I wondered about adjusting it to run on older systems, but I
think we're about ready to drop support for Windows < 10 anyway, so
maybe I'll go and propose that separately, instead.
On Thu, Feb 3, 2022 at 8:35 PM Andres Freund wrote:
> Yea, I'd have no problem leaving the "hard" limit somewhere closer to 1
> million (although 100k should be just as well), but introduce a softer "only
> vacuum/drop/truncate" limit a good bit before that.
+1.
> To address the "as long as"
On 2022/02/03 15:50, Kyotaro Horiguchi wrote:
On way to take. In that case should we log something like
"Restartpoint canceled" or something?
+1
By the way, restart point should start only while recoverying, and at
the timeof the start both checkpoint.redo and checkpoint LSN are
already
Hi,
On 2022-02-03 17:25:51 -0500, Andrew Dunstan wrote:
> OK, I have all the pieces working and I know what I need to do to adapt
> fairywren. The patch you provided is not necessary any more.
Cool. Are you going to post that?
> (I think your TMPDIR spec is missing a /build/)
I think I went
On 2022-Feb-03, Pavel Stehule wrote:
> The biggest problem is coexistence of Postgres's SEARCH_PATH object
> identification, and local and public scopes used in MODULEs or in Oracle's
> packages.
>
> I can imagine MODULES as third level of database unit object grouping with
> following
Hi,
On 2022-02-03 17:02:15 -0500, Robert Haas wrote:
> On Thu, Feb 3, 2022 at 4:50 PM Andres Freund wrote:
> > I wonder if we shouldn't add some exceptions to the xid allocation
> > prevention. It makes sense that we don't allow random DML. But it's e.g.
> > often
> > more realistic to drop /
Hi!
On Wed, Jan 26, 2022 at 7:07 PM sergei sh. wrote:
> I've fixed issues 2 -- 4 in attached version.
>
> GUC parameter has been removed for the number of pages to collect
> before splitting and fixed value of 4 is used instead, as discussed
> off-list with Andrey Borodin, Aliaksandr Kalenik,
On Thu, Feb 3, 2022 at 7:08 PM David Rowley wrote:
> Currently, the patch validates 3 rules:
>
> 1) Ensure a parallel_aware path has only parallel_aware or
> parallel_safe subpaths.
I think that every path that is parallel_aware must also be
parallel_safe. So checking for either parallel_aware
On Thu, Feb 3, 2022 at 5:08 PM John Naylor wrote:
> Looking closer, there is a function defined by an extension. I'd have
> to dig further to see if writes happen. The error is exactly what
> we've been talking about:
>
> 2022-01-03 22:03:23 PST ERROR: database is not accepting commands to
>
On Fri, Feb 04, 2022 at 09:08:22AM +0900, Fujii Masao wrote:
> On 2022/02/04 1:46, Yugo NAGATA wrote:
>> I found a old parameter name 'heapRelation' in the comment
>> of CheckIndexCompatible. This parameter was removed by 5f173040.
>>
>> Attached is a patch to remove it from the comment.
It
On Fri, Oct 30, 2020 at 9:46 PM Tomas Vondra
wrote:
>
> On Fri, Oct 16, 2020 at 03:35:51PM -0700, Peter Geoghegan wrote:
> >I suppose that a change like this could end up affecting other things,
> >such as EXPLAIN ANALYZE statistics. OTOH we only break out index pages
> >separately for bitmap
On 2022/02/04 1:46, Yugo NAGATA wrote:
Hello,
I found a old parameter name 'heapRelation' in the comment
of CheckIndexCompatible. This parameter was removed by 5f173040.
Attached is a patch to remove it from the comment.
Thanks for the report! I agree to remove the mention of parameter
On Wed, 26 Jan 2022 at 05:32, Tom Lane wrote:
> Therefore, what I think could be useful is some very-late-stage
> assertion check (probably in createplan.c) verifying that the
> child of a Gather is parallel-aware. Or maybe the condition
> needs to be more general than that, but anyway the idea
On Thu, Feb 03, 2022 at 09:45:08AM +0530, Bharath Rupireddy wrote:
> On Thu, Feb 3, 2022 at 12:07 AM Nathan Bossart
> wrote:
>> If there is a problem reading the directory, we will LOG and then exit the
>> loop. If we didn't scan through all the entries in the directory, there is
>> a chance
On 1/24/22 21:36, Andres Freund wrote:
> Hi,
>
> On 2022-01-24 16:47:28 -0500, Andrew Dunstan wrote:
>> Give me what you can and I'll see what I can do. I have a couple of
>> moderately high priority items on my plate, but I will probably be able
>> to fit in some testing when those make my eyes
On Thu, Feb 3, 2022 at 4:58 PM Andres Freund wrote:
>
> Hi,
>
> On 2022-02-03 16:18:27 -0500, John Naylor wrote:
> > I just checked some client case notes where they tried just that
> > before getting outside help, and both SELECT and VACUUM FREEZE
> > commands were rejected.
>
> What kind of
On Thu, Feb 3, 2022 at 4:50 PM Andres Freund wrote:
> I wonder if we shouldn't add some exceptions to the xid allocation
> prevention. It makes sense that we don't allow random DML. But it's e.g. often
> more realistic to drop / truncate a few tables with unimportant content,
> rather than spend
Hi,
On 2022-02-03 16:18:27 -0500, John Naylor wrote:
> I just checked some client case notes where they tried just that
> before getting outside help, and both SELECT and VACUUM FREEZE
> commands were rejected.
What kind of SELECT was that? Any chance it caused a write via functions, a
view,
On Thu, Feb 3, 2022 at 4:18 PM John Naylor wrote:
> I just checked some client case notes where they tried just that
> before getting outside help, and both SELECT and VACUUM FREEZE
> commands were rejected. The failure is clearly indicated in the log.
It would be helpful to know how it failed -
On Thu, Feb 03, 2022 at 04:45:52PM -0500, Robert Haas wrote:
> On Thu, Feb 3, 2022 at 4:25 PM Nathan Bossart
> wrote:
>> 024_archive_recovery.pl seems to do something similar. Patch attached.
>
> Committed. I think this is mostly an issue for pg_regress tests, as
> opposed to
Hi,
On 2022-02-03 13:42:20 -0500, Robert Haas wrote:
> They *do* have a choice. They can continue to operate the system in
> multi-user mode, they can have read access to their data, and they can
> run VACUUM and other non-XID-allocating commands to fix the issue.
> Sure, their application can't
On Thu, Feb 3, 2022 at 4:25 PM Nathan Bossart wrote:
> 024_archive_recovery.pl seems to do something similar. Patch attached.
Committed. I think this is mostly an issue for pg_regress tests, as
opposed to 024_archive_recovery.pl, which is a TAP test. Maybe I'm
wrong about that, but it looks to
On Thu, Feb 03, 2022 at 04:15:30PM -0500, Robert Haas wrote:
> On Thu, Feb 3, 2022 at 4:11 PM Nathan Bossart
> wrote:
>> On Thu, Feb 03, 2022 at 04:04:33PM -0500, Robert Haas wrote:
>> > So apparently we need to either skip this test when wal_level=minimal,
>> > or force a higher wal_level to be
On Thu, Feb 3, 2022 at 1:42 PM Robert Haas wrote:
>
> On Thu, Feb 3, 2022 at 1:34 PM John Naylor
> wrote:
> > The word "advice" sounds like people have a choice, rather than the
> > system not accepting commands anymore. It would be much less painful
> > if the system closed connections and
On Thu, Feb 3, 2022 at 4:11 PM Nathan Bossart wrote:
> On Thu, Feb 03, 2022 at 04:04:33PM -0500, Robert Haas wrote:
> > So apparently we need to either skip this test when wal_level=minimal,
> > or force a higher wal_level to be used for this particular test. Not
> > sure what the existing
On Thu, Feb 03, 2022 at 04:04:33PM -0500, Robert Haas wrote:
> So apparently we need to either skip this test when wal_level=minimal,
> or force a higher wal_level to be used for this particular test. Not
> sure what the existing precedents are, if any.
The only precedent I've found so far is
On Thu, Feb 3, 2022 at 2:27 PM Nathan Bossart wrote:
> On Thu, Feb 03, 2022 at 02:11:18PM -0500, Robert Haas wrote:
> > Committed. I'm going to be 0% surprised if the buildfarm turns pretty
> > colors, but I don't know how to know what it's going to be unhappy
> > about except by trying it, so
čt 3. 2. 2022 v 20:21 odesílatel Swaha Miller
napsal:
> Thank you for the feedback Pavel and Julien. I'll try to explain some of
> the issues and points you raise to the best of my understanding.
>
> The reason for modules is that it would serve as an organizational unit
> that can allow setting
Hi,
On 2022-02-02 21:58:28 -0600, Justin Pryzby wrote:
> FYI: I've rebased these against your cirrus/windows changes.
Did you put then on a dedicated branch, or only intermixed with other changes?
> A recent cirrus result is here; this has other stuff in the branch, so you can
> see the
On Thu, Feb 3, 2022 at 2:16 PM Peter Eisentraut
wrote:
> If we want simply an alternative, we had a GnuTLS variant almost done a
> few years ago, but in the end people didn't want it enough. It seems to
> be similar now.
Yeah. I think it's pretty clear that the only real downside of
committing
On Thu, Feb 03, 2022 at 02:11:18PM -0500, Robert Haas wrote:
> Committed. I'm going to be 0% surprised if the buildfarm turns pretty
> colors, but I don't know how to know what it's going to be unhappy
> about except by trying it, so here goes.
Thanks! I'll keep an eye on the buildfarm and will
Thank you for the feedback Pavel and Julien. I'll try to explain some of
the issues and points you raise to the best of my understanding.
The reason for modules is that it would serve as an organizational unit
that can allow setting permissions on those units. So, for example, all
functions in a
On 03.02.22 15:53, Daniel Gustafsson wrote:
I see quite a few valid reasons to want an alternative, a few off the top of my
head include:
- Using trust stores like Keychain on macOS with Secure Transport. There is
AFAIK something similar on Windows and NSS has it's certificate databases.
Hi,
On 2022-02-03 10:44:11 +0100, Fabien COELHO wrote:
> > I'm doubtful that tracking development branches of LLVM is a good
> > investment. Their development model is to do changes in-tree much more than
> > we
> > do. Adjusting to API changes the moment they're made will often end up with
> >
On Wed, Feb 2, 2022 at 5:44 PM Nathan Bossart wrote:
> > I would suggest s/if it eventually/only when it/
>
> Done.
Committed. I'm going to be 0% surprised if the buildfarm turns pretty
colors, but I don't know how to know what it's going to be unhappy
about except by trying it, so here goes.
Greetings,
* Daniel Gustafsson (dan...@yesql.se) wrote:
> > On 3 Feb 2022, at 15:07, Peter Eisentraut
> > wrote:
> >
> > On 28.01.22 15:30, Robert Haas wrote:
> >> I would really, really like to have an alternative to OpenSSL for PG.
> >
> > What are the reasons people want that? With
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Feb 1, 2022 at 01:52:09PM -0800, Andres Freund wrote:
> > There's https://hg.mozilla.org/projects/nspr/file/tip/pr/src - which is I
> > think the upstream source.
> >
> > A project without even a bare-minimal README at the root does
On Thu, Feb 3, 2022 at 1:34 PM John Naylor wrote:
> The word "advice" sounds like people have a choice, rather than the
> system not accepting commands anymore. It would be much less painful
> if the system closed connections and forbade all but superusers to
> connect, but that sounds like a lot
On Thu, Feb 3, 2022 at 1:06 PM Robert Haas wrote:
>
> On Thu, Dec 9, 2021 at 8:56 PM Andres Freund wrote:
> > I think we should move *away* from single user mode, rather than the
> > opposite. It's a substantial code burden and it's hard to use.
>
> Yes. This thread seems to be largely devoted
Hi,
On 2022-02-01 13:31:36 +1100, Peter Smith wrote:
> TEST STEPS - Workload case a
>
> 1. Run initdb pub and sub and start both postgres instances (use the nosync
> postgresql.conf)
>
> 2. Run psql for both instances and create tables
> CREATE TABLE test (key int, value text, data jsonb,
On Thu, Feb 3, 2022 at 12:26 PM Andrew Dunstan wrote:
> I've fixed this using the auth_extra method, which avoids a reload.
Thank you much.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Thu, Dec 9, 2021 at 8:56 PM Andres Freund wrote:
> I think we should move *away* from single user mode, rather than the
> opposite. It's a substantial code burden and it's hard to use.
Yes. This thread seems to be largely devoted to the topic of making
single-user vacuum work better, but I
On Thu, Feb 3, 2022 at 8:50 AM Yugo NAGATA wrote:
> On Thu, 3 Feb 2022 08:48:00 -0800
> Zhihong Yu wrote:
>
> > On Thu, Feb 3, 2022 at 8:28 AM Yugo NAGATA wrote:
> >
> > > Hi,
> > >
> > > On Thu, 13 Jan 2022 18:23:42 +0800
> > > Julien Rouhaud wrote:
> > >
> > > > Hi,
> > > >
> > > > On Thu,
On Tue, Feb 01, 2022 at 04:50:31PM -0500, John Naylor wrote:
> On Thu, Jan 27, 2022 at 8:28 PM Justin Pryzby wrote:
>
> > I'm sure you meant "&" here (fixed in attached patch to appease the cfbot):
> > + if (options | VACOPT_MINIMAL)
>
> Thanks for catching that! That copy-pasto
On 2/2/22 17:52, Tom Lane wrote:
> I wrote:
>> The Windows animals don't like this:
>> pg_basebackup: error: connection to server at "127.0.0.1", port 59539
>> failed: FATAL: SSPI authentication failed for user "backupuser"
>> Not sure whether we have a standard method to get around that.
>
VACUUM's first pass over the heap is implemented by a function called
lazy_scan_heap(), while the second pass is implemented by a function
called lazy_vacuum_heap_rel(). This seems to imply that the first pass
is primarily an examination of what is present, while the second pass
does the real
Hello,
I found a old parameter name 'heapRelation' in the comment
of CheckIndexCompatible. This parameter was removed by 5f173040.
Attached is a patch to remove it from the comment.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/backend/commands/indexcmds.c
On Thu, Feb 3, 2022 at 8:28 AM Yugo NAGATA wrote:
> Hi,
>
> On Thu, 13 Jan 2022 18:23:42 +0800
> Julien Rouhaud wrote:
>
> > Hi,
> >
> > On Thu, Nov 25, 2021 at 04:37:10PM +0900, Yugo NAGATA wrote:
> > > On Wed, 24 Nov 2021 04:31:25 +
> > > "r.takahash...@fujitsu.com" wrote:
> > >
> > > >
Hi,
On Thu, 13 Jan 2022 18:23:42 +0800
Julien Rouhaud wrote:
> Hi,
>
> On Thu, Nov 25, 2021 at 04:37:10PM +0900, Yugo NAGATA wrote:
> > On Wed, 24 Nov 2021 04:31:25 +
> > "r.takahash...@fujitsu.com" wrote:
> >
> > >
> > > I checked the same procedure on v24 patch.
> > > But following
Tom Lane writes:
> I wrote:
>> The Windows animals don't like this:
>> pg_basebackup: error: connection to server at "127.0.0.1", port 59539
>> failed: FATAL: SSPI authentication failed for user "backupuser"
>
>> Not sure whether we have a standard method to get around that.
>
> Ah, right, we
Thinking further about the use of emergency mode, we have this:
"If for some reason autovacuum fails to clear old XIDs from a table,
the system will begin to emit warning messages like this when the
database's oldest XIDs reach forty million transactions from the
wraparound point:
WARNING:
Peter Eisentraut writes:
> Tom, you worked on reorganzing the error message handling in libpq in
> PostgreSQL 14 (commit ffa2e4670123124b92f037d335a1e844c3782d3f). Any
> thoughts on this?
Ah, sorry, I'd not noticed this thread.
I concur with Fabien's analysis: we report the FATAL message
On Thu, Feb 3, 2022 at 3:14 AM Masahiko Sawada wrote:
> + The only other option that may be combined with
> VERBOSE, although in single-user mode no client
> messages are
> + output.
>
> Given VERBOSE with EMERGENCY can work only in multi-user mode, why
> only VERBOSE can be specified
On Sat, Jan 29, 2022 at 11:31 AM Andres Freund wrote:
>
> Hi,
>
> Are there any recent performance evaluations of the overhead of row filters? I
> think it'd be good to get some numbers comparing:
>
> 1) $workload with master
> 2) $workload with patch, but no row filters
> 3) $workload with
> On 3 Feb 2022, at 15:07, Peter Eisentraut
> wrote:
>
> On 28.01.22 15:30, Robert Haas wrote:
>> I would really, really like to have an alternative to OpenSSL for PG.
>
> What are the reasons people want that? With OpenSSL 3, the main reasons --
> license and FIPS support -- have gone away.
Hi,
Just some minor adjustments to the patch:
* Removed call to locale-dependent toupper()
* Cleaned up input normalization
I have been asked to sign up to review a commitfest patch or patches -
unfortunately I've been ill with COVID-19 and it's not until now that
I feel well enough to have a
Tom, you worked on reorganzing the error message handling in libpq in
PostgreSQL 14 (commit ffa2e4670123124b92f037d335a1e844c3782d3f). Any
thoughts on this?
On 25.01.22 09:32, Peter Eisentraut wrote:
This issue was discovered by Fabien in the SHOW_ALL_RESULTS thread. I'm
posting it here
On 28.01.22 15:30, Robert Haas wrote:
I would really, really like to have an alternative to OpenSSL for PG.
What are the reasons people want that? With OpenSSL 3, the main reasons
-- license and FIPS support -- have gone away.
On Thu, Feb 03, 2022 at 06:40:55PM +0530, Bharath Rupireddy wrote:
>
> Isn't complex for anyone to go to the archive location which involves
> extra steps - getting authentication tokens, searching there for the
> required WAL file, downloading it, unzipping it, copying back to
> pg_receivewal
On 29.01.22 15:40, Fabien COELHO wrote:
With this approach results are not available till the last one has been
returned? If so, it loses the nice asynchronous property of getting
results as they come when they come? This might or might not be
desirable depending on the use case. For "psql",
On 29.01.22 15:30, Bharath Rupireddy wrote:
While working on another pg_control patch, I observed that the
pg_controldata output fields such as "Latest checkpoint's
TimeLineID:", "Latest checkpoint's NextOID:'' and so on, are being
used in pg_resetwal.c, pg_controldata.c and
On Wed, Feb 2, 2022 at 9:28 PM Julien Rouhaud wrote:
>
> On Wed, Feb 02, 2022 at 09:14:03PM +0530, Bharath Rupireddy wrote:
> >
> > FYI that thread is closed, it committed the change (f61e1dd [1]) that
> > pg_receivewal can read from its replication slot restart lsn.
> >
> > I know that providing
On Thu, Feb 3, 2022 at 11:34 AM Kyotaro Horiguchi
wrote:
> > > #define PG_CONTROL_FIELD_CHECKPOINT_OLDESTXID "Latest checkpoint's
> > > oldestXID:"
> > > #define PG_CONTROL_FIELD_CHECKPOINT_OLDESTXID_DB "Latest checkpoint's
> > > oldestXID's DB:"
> > > and so on.
> >
> > That seems like a very
On Thu, Feb 3, 2022 at 8:18 AM Tom Lane wrote:
>
> Amit Kapila writes:
> > Tom, is it okay for you if I go ahead with this patch after some testing?
>
> I've been too busy to get back to it, so sure.
>
Thanks. I have tested the patch by generating an invalidation message
for table DDL before
On 28.01.22 13:56, Pavel Borisov wrote:
Makes sense. Here is an updated patch with this change.
I didn't end up renaming anynullkeys. I came up with names like
"anyalwaysdistinctkeys", but in the end that felt too abstract, and
moreover, it would require rewriting a bunch of
On 02.02.22 07:54, Amit Kapila wrote:
Where do you propose to store this information?
pg_subscription_worker
The error message and context is very important. Just make sure it is only non-null when
the worker state is "syncing failed" (or whatever term we use).
We could name the table
Hello Andres,
I'm doubtful that tracking development branches of LLVM is a good
investment. Their development model is to do changes in-tree much more than we
do. Adjusting to API changes the moment they're made will often end up with
further changes to the same / related lines. Once they
On Wed, Feb 2, 2022 at 6:50 AM John Naylor wrote:
>
> On Thu, Jan 27, 2022 at 8:28 PM Justin Pryzby wrote:
>
> > I'm sure you meant "&" here (fixed in attached patch to appease the cfbot):
> > + if (options | VACOPT_MINIMAL)
>
> Thanks for catching that! That copy-pasto was also
On Wed, Feb 2, 2022 at 7:59 AM torikoshia wrote:
>
> 2022-02-01 01:51, Fujii Masao wrote:
> > +Note that nested statements (statements executed inside a
> > function) are not
> > +considered for logging. Only the plan of the most deeply nested
> > query is logged.
> >
> > Now the plan of
81 matches
Mail list logo
