On Sat, Apr 20, 2024 at 12:43:24AM +0300, Heikki Linnakangas wrote:
> On 19/04/2024 19:48, Jacob Champion wrote:
>> On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas wrote:
>>> With direct SSL negotiation, we always require ALPN.
>>
>> (As an aside: I haven't gotten to test the version of the
On Thu, Apr 18, 2024 at 4:26 PM Ajin Cherian wrote:
>
> Attaching the patch for your review and comments. Big thanks to Kuroda-san
> for also working on the patch.
>
>
Looking at this a bit more, maybe rolling back all prepared transactions on
the subscriber when toggling two_phase from true to f
Thanks all!
On Fri, 19 Apr 2024 at 13:59, Daniel Gustafsson wrote:
> > On 19 Apr 2024, at 13:49, Daniel Gustafsson wrote:
> >> On 19 Apr 2024, at 12:31, Aleksander Alekseev
> wrote:
>
> >> Here is the patch.
> >
> > Nice catch, and thanks for the patch. I'll apply it with a backpatch to
> whe
On 22/04/2024 10:19, Michael Paquier wrote:
On Sat, Apr 20, 2024 at 12:43:24AM +0300, Heikki Linnakangas wrote:
On 19/04/2024 19:48, Jacob Champion wrote:
On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas wrote:
With direct SSL negotiation, we always require ALPN.
(As an aside: I haven'
On Mon, 22 Apr 2024 at 06:04, Michael Paquier wrote:
>
> On Fri, Apr 19, 2024 at 12:47:43PM +0300, Aleksander Alekseev wrote:
> > Thanks. I see a few pieces of code that use special FOO_NUMBER enum
> > values instead of a macro. Should we refactor these pieces
> > accordingly? PFA another patch.
>
Hello Peter,
07.04.2024 20:18, Peter Geoghegan wrote:
On Sun, Apr 7, 2024 at 1:00 PM Alexander Lakhin wrote:
SELECT * FROM t WHERE a < ANY (ARRAY[1]) AND b < ANY (ARRAY[1]);
TRAP: failed Assert("so->numArrayKeys"), File: "nbtutils.c", Line: 560, PID:
3251267
I immediately see what's up here
On Sat, Apr 20, 2024 at 2:00 PM Alena Rybakina
wrote:
> Hi, thank you for your work with this subject.
>
> While I was reviewing your code, I noticed that your patch conflicts with
> another patch [0] that been committed.
>
> [0]
> https://www.postgresql.org/message-id/flat/CA%2BhUKGJkOiOCa%2Bmag
hi.
minor issue in guc.c.
set work_mem to '1kB';
ERROR: 1 kB is outside the valid range for parameter "work_mem" (64
.. 2147483647)
should it be
ERROR: 1 kB is outside the valid range for parameter "work_mem" (64
kB .. 2147483647 kB)
?
since the units for work_mem are { "B", "kB", "MB", "GB", an
Hi,
This new thread is a follow-up of [1] and [2].
Problem description:
We have occasionally observed objects having an orphaned dependency, the
most common case we have seen is functions not linked to any namespaces.
Examples to produce such orphaned dependencies:
Scenario 1:
session 1: beg
Hi,
On Wed, Mar 23, 2022 at 12:49:06PM -0400, Tom Lane wrote:
> Realistically, if we want to prevent this type of problem, then all
> creation DDL will have to take a lock on each referenced object that'd
> conflict with a lock taken by DROP. This might not be out of reach:
> I think we do alread
Dear Vitaly,
> I looked at the patch and realized that I can't try it easily in the near
> future
> because the solution I'm working on is based on PG16 or earlier. This patch is
> not easily applicable to the older releases. I have to port my solution to the
> master, which is not done yet.
We
On Fri, Apr 19, 2024 at 6:44 PM jian he wrote:
>
> On Thu, Apr 18, 2024 at 6:58 PM Alexander Korotkov
> wrote:
> >
> > Thank you for the fixes you've proposed. I didn't look much into
> > details yet, but I think the main concern Tom expressed in [1] is
> > whether the feature is reasonable at
Dear hackers,
> Looking at this a bit more, maybe rolling back all prepared transactions on
> the
> subscriber when toggling two_phase from true to false might not be desirable
> for the customer. Maybe we should have an option for customers to control
> whether transactions should be rolled back
Hi,
On Mon, Apr 22, 2024 at 11:32:14AM +0530, shveta malik wrote:
> On Mon, Apr 22, 2024 at 5:57 AM Zhijie Hou (Fujitsu)
> wrote:
> > Attach the V3 patch which also addressed Shveta[1] and Bertrand[2]'s
> > comments.
Thanks!
> Tested the patch, works well.
Same here.
Regards,
--
Bertrand
Hi Bertrand,
22.04.2024 11:45, Bertrand Drouvot wrote:
Hi,
This new thread is a follow-up of [1] and [2].
Problem description:
We have occasionally observed objects having an orphaned dependency, the
most common case we have seen is functions not linked to any namespaces.
...
Looking forwar
Hi Team,
> I have some sympathy for this. The discussion about removing AIX
> support had a very short turnaround and happened in an unrelated thread,
> without any sort of public announcement or consultation. So this report
> of "hey, we were still using that" is timely and fair.
We wou
Hi Alexander,
On 2024-Apr-18, Alexander Lakhin wrote:
> 18.04.2024 16:39, Alvaro Herrera wrote:
> > I have pushed a fix which should hopefully fix this problem
> > (d9f686a72e). Please give this a look. Thanks for reporting the issue.
>
> Please look at an assertion failure, introduced with d9
Hi,
On Mon, Apr 22, 2024 at 01:00:00PM +0300, Alexander Lakhin wrote:
> Hi Bertrand,
>
> 22.04.2024 11:45, Bertrand Drouvot wrote:
> > Hi,
> >
> > This new thread is a follow-up of [1] and [2].
> >
> > Problem description:
> >
> > We have occasionally observed objects having an orphaned depend
On Fri, Apr 19, 2024 at 1:52 PM shveta malik wrote:
>
> Please find v9 with the above comments addressed.
>
I have made minor modifications in the comments and a function name.
Please see the attached top-up patch. Apart from this, the patch looks
good to me.
--
With Regards,
Amit Kapila.
diff
22.04.2024 13:52, Bertrand Drouvot wrote:
That's weird, I just launched it several times with the patch applied and I'm
not
able to see the seg fault (while I can see it constently failing on the master
branch).
Are you 100% sure you tested it against a binary with the patch applied?
Yes, a
On Mon, Apr 22, 2024 at 5:10 PM Amit Kapila wrote:
>
> On Fri, Apr 19, 2024 at 1:52 PM shveta malik wrote:
> >
> > Please find v9 with the above comments addressed.
> >
>
> I have made minor modifications in the comments and a function name.
> Please see the attached top-up patch. Apart from this
> Dear Vitaly,
>
> > I looked at the patch and realized that I can't try it easily in the near
> > future
> > because the solution I'm working on is based on PG16 or earlier. This patch
> > is
> > not easily applicable to the older releases. I have to port my solution to
> > the
> > master, whi
On Sat, 20 Apr 2024 at 01:36, Tom Lane wrote:
> Japin Li writes:
>> I see [1] has already implemented on login event trigger, why not implement
>> the logoff event trigger?
>
> What happens if the session crashes, or otherwise fails unexpectedly?
>
I am currently unsure how to handle such situ
On Mon, Apr 22, 2024 at 2:36 AM Michael Paquier wrote:
> I'd like to think about this stuff in a different way: this is useful
> if enabled by default because it can also help in finding out error
> paths that should not use the internal errcode. Normally, there
> should be zero backtraces produc
On Mon, Apr 22, 2024 at 9:02 PM shveta malik wrote:
>
> On Mon, Apr 22, 2024 at 5:10 PM Amit Kapila wrote:
> >
> > On Fri, Apr 19, 2024 at 1:52 PM shveta malik wrote:
> > >
> > > Please find v9 with the above comments addressed.
> > >
> >
> > I have made minor modifications in the comments and a
Hey folks,
Any news, comments, etc. about this thread?
Best regards
Majid Garoosi
On Mon, 12 Feb 2024 at 01:10, Michael Paquier wrote:
> On Sun, Feb 11, 2024 at 04:32:20PM +0330, Majid Garoosi wrote:
> > On Fri, 9 Feb 2024 at 22:33, Andres Freund wrote:
> >> The way we read the WAL data is pe
Hi,
On Thu, Apr 4, 2024 at 9:23 PM Bharath Rupireddy
wrote:
>
> On Thu, Apr 4, 2024 at 4:35 PM Amit Kapila wrote:
> >
> > > Thanks for the changes. v34-0001 LGTM.
> >
> > I was doing a final review before pushing 0001 and found that
> > 'inactive_since' could be set twice during startup after pr
On Sun, Apr 21, 2024 at 8:47 PM David Steele wrote:
> > I figured that wouldn't be particularly meaningful, and
> > that's pretty much the only kind of validation that's even
> > theoretically possible without a bunch of extra overhead, since we
> > compute checksums on entire files rather than, s
Hi,
On Mon, 22 Apr 2024 at 11:44, jian he wrote:
>
> hi.
> minor issue in guc.c.
>
> set work_mem to '1kB';
> ERROR: 1 kB is outside the valid range for parameter "work_mem" (64
> .. 2147483647)
> should it be
> ERROR: 1 kB is outside the valid range for parameter "work_mem" (64
> kB .. 2147483
On Fri, Apr 19, 2024 at 4:29 PM Nathan Bossart wrote:
> I certainly don't want to hold up $SUBJECT for a larger rewrite of
> autovacuum scheduling, but I also don't want to shy away from a larger
> rewrite if it's an idea whose time has come. I'm looking forward to
> hearing your ideas in your pg
Dear Hayato,
On Monday, April 22, 2024 15:54 MSK, "Hayato Kuroda (Fujitsu)"
wrote:
> Dear Vitaly,
>
> > I looked at the patch and realized that I can't try it easily in the near
> > future
> > because the solution I'm working on is based on PG16 or earlier. This patch
> > is
> > not easily a
On Thu, Apr 18, 2024 at 5:36 PM Jelte Fennema-Nio wrote:
> To clarify: My proposed approach is to use a protocol extension
> parameter for to enable the new messages that the server can send
> (like Peter is doing now). And **in addition to that** gate the new
> Bind format type behind a feature s
On Sat Apr 20, 2024 at 10:42 AM CDT, Peter Eisentraut wrote:
3. We leave it out of PG17 and consider a new AIX port for PG18 on its
own merits.
Note that such a "new" port would probably require quite a bit of
development and research work, to clean up all the cruft that had
accumulated ove
On Mon, Apr 22, 2024 at 4:00 AM Alexander Lakhin wrote:
> Please look at another case, where a similar Assert (but this time in
> _bt_preprocess_keys()) is triggered:
> CREATE TABLE t (a text, b text);
> INSERT INTO t (a, b) SELECT 'a', repeat('b', 100) FROM generate_series(1,
> 500) g;
> CREATE
Hi,
While working on the 'reduce nodeToString output' patch, I noticed
that my IDE marked one field in the TidScanState node as 'unused'.
After checking this seemed to be accurate, and I found a few more such
fields in Node structs.
PFA some patches that clean this up: 0001 is plain removal of fi
Matthias van de Meent writes:
> 0001 removes two old fields that are not in use anywhere anymore, but
> at some point these were used.
+1. They're not being initialized, so they're useless and confusing.
> 0002/0004 remove fields in ExecRowMark which were added for FDWs to
> use, but there are
jian he writes:
> set work_mem to '1kB';
> ERROR: 1 kB is outside the valid range for parameter "work_mem" (64
> .. 2147483647)
> should it be
> ERROR: 1 kB is outside the valid range for parameter "work_mem" (64
> kB .. 2147483647 kB)
> ?
> since the units for work_mem are { "B", "kB", "MB", "G
On Mon, Apr 15, 2024 at 11:17:54AM +0530, Amit Kapila wrote:
> On Thu, Apr 11, 2024 at 6:58 PM Kirill Reshke wrote:
> >
> > While working on [0] i have noticed this comment in
> > TerminateOtherDBBackends function:
> >
> > /*
> > * Check whether we have the necessary rights to terminate other
> >
On Mon, 22 Apr 2024 at 17:41, Tom Lane wrote:
>
> Matthias van de Meent writes:
> > 0002/0004 remove fields in ExecRowMark which were added for FDWs to
> > use, but there are no FDWs which use this: I could only find two FDWs
> > who implement RefetchForeignRow, one being BlackHoleFDW, and the ot
On Thu, Apr 18, 2024 at 5:39 AM Tomas Vondra
wrote:
>
> On 4/18/24 09:10, Michael Paquier wrote:
> > On Sun, Apr 07, 2024 at 10:54:56AM -0400, Melanie Plageman wrote:
> >> I've added an open item [1], because what's one open item when you can
> >> have two? (me)
> >
> > And this is still an open i
Hi,
On 2024-04-19 13:57:41 -0400, Robert Haas wrote:
> Have others seen this? Is there something we can/should do about it?
Yes, I've also seen this - but never quite reproducible enough to properly
tackle it.
The first thing I'd like to do is to make the wait_for_catchup routine
regularly log t
On Wed, 2024-04-17 at 11:50 -0500, Nathan Bossart wrote:
> It looks like the problem is that the ACLs are getting dumped in the
> data
> section when we are also dumping stats. I'm able to get the tests to
> pass
> by moving the call to dumpRelationStats() that's in dumpTableSchema()
> to
> dumpTa
On Mon, Apr 22, 2024 at 11:13 AM Peter Geoghegan wrote:
> I'm pretty sure that I could fix this by simply removing the
> assertion. But I need to think about it a bit more before I push a
> fix.
>
> The test case you've provided proves that _bt_preprocess_keys's
> new no-op path isn't just used du
On Thu, Apr 18, 2024 at 3:25 PM Daniel Gustafsson wrote:
> > On 18 Apr 2024, at 20:11, Robert Haas wrote:
> > 2. As (1), but make check_control_files() emit a warning message when
> > the problem case is detected.
>
> Being in the post-freeze part of the cycle, this seems like the best option.
H
I noticed that there are some existing examples of this sort of thing in
pg_dump (e.g., commit d5e8930), so I adjusted the patch to match the
surrounding style a bit better.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 80dd3233730422298ffe3b4523a7c58d7e9b55b9 Mon Sep 17 00:
On Tue, Apr 16, 2024 at 7:20 PM Jeff Davis wrote:
> We maintain the invariant:
>
>XLogCtl->logFlushResult <= XLogCtl->logWriteResult
>
> and the non-shared version:
>
>LogwrtResult.Flush <= LogwrtResult.Write
>
> and that the requests don't fall behind the results:
I had missed the fact t
Hey,
The attached patch addresses four somewhat related aspects of the create
table reference page that bother me.
This got started with Bug# 15954 [1] (unlogged on a partitioned table
doesn't make sense) and I've added a paragraph under "unlogged" to address
it.
While doing that, it seemed desi
I used to do this step when I first started hacking on Postgres because
that's what it says to do, but I've only ever used the in-tree one for many
years now, and I'm not aware of any scenario where I might need to download
a new version from the buildfarm. I see that the in-tree copy wasn't added
I reworked the test cases so that they don't (I think) rely on
symlinks working as they do on normal platforms.
Here's a patch. I'll go create a CommitFest entry for this thread so
that cfbot will look at it.
...Robert
v1-0001-Try-again-to-add-test-coverage-for-pg_combineback.patch
Description:
Nathan Bossart writes:
> I used to do this step when I first started hacking on Postgres because
> that's what it says to do, but I've only ever used the in-tree one for many
> years now, and I'm not aware of any scenario where I might need to download
> a new version from the buildfarm. I see th
Jeff Davis writes:
> Would it make sense to have a new SECTION_STATS?
Perhaps, but the implications for pg_dump's API would be nontrivial,
eg would we break any applications that know about the current
options for --section. And you still have to face up to the question
"does --data-only include
On Mon, Apr 22, 2024 at 04:08:08PM -0400, Tom Lane wrote:
> I think the actual plan now is that we'll sync the in-tree copy
> with the buildfarm's results (and then do a tree-wide pgindent)
> every so often, probably shortly before beta every year.
Okay. Is this just to resolve the delta between
Nathan Bossart writes:
> On Mon, Apr 22, 2024 at 04:08:08PM -0400, Tom Lane wrote:
>> I think the actual plan now is that we'll sync the in-tree copy
>> with the buildfarm's results (and then do a tree-wide pgindent)
>> every so often, probably shortly before beta every year.
> Okay. Is this jus
> On 21 Apr 2024, at 23:08, Tom Lane wrote:
> ... were you going to look at it? I can take a whack if it's too far down
> your priority list.
Yeah, I’m working on a patchset right now.
./daniel
On Tue, Apr 23, 2024 at 8:05 AM Robert Haas wrote:
> I reworked the test cases so that they don't (I think) rely on
> symlinks working as they do on normal platforms.
Cool.
(It will remain a mystery for now why perl readlink() can't read the
junction points that PostgreSQL creates (IIUC), but th
On Mon, 22 Apr 2024 at 16:26, Robert Haas wrote:
> That's a fair point, but I'm still not seeing much practical
> advantage. It's unlikely that a client is going to set a random bit in
> a format parameter for no reason.
I think you're missing an important point of mine here. The client
wouldn't
Thoughts anyone?
On Thu, Feb 1, 2024 at 3:47 PM David G. Johnston
wrote:
> Motivated by a recent complaint [1] I found the hostssl related material
> in our docs quite verbose and even repetitive. Some of that is normal
> since we have both an overview/walk-through section as well as a referenc
Hi,
On 2024-04-23 09:15:27 +1200, Thomas Munro wrote:
> I find myself wondering if symlinks should go on the list of "things
> we pretended Windows had out of convenience, that turned out to be
> more inconvenient than we expected, and we'd do better to tackle
> head-on with a more portable idea".
Any thoughts?
On Thu, Jan 25, 2024 at 1:59 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> Hey,
>
> In a nearby user complaint email [1] some missing information regarding
> ownership reassignment came to light. I took that and went a bit further
> to add what I felt was further miss
On Mon, Apr 22, 2024 at 5:16 PM Thomas Munro wrote:
> On Tue, Apr 23, 2024 at 8:05 AM Robert Haas wrote:
> > I reworked the test cases so that they don't (I think) rely on
> > symlinks working as they do on normal platforms.
>
> Cool.
cfbot is giving me a bunch of green check marks, so I plan to
Hi!
On Thu, Apr 18, 2024 at 1:57 PM Alexander Korotkov wrote:
> Thank you for the fixes you've proposed. I didn't look much into
> details yet, but I think the main concern Tom expressed in [1] is
> whether the feature is reasonable at all. I think at this stage the
> most important thing is to
On 22/04/2024 10:47, Heikki Linnakangas wrote:
On 22/04/2024 10:19, Michael Paquier wrote:
On Sat, Apr 20, 2024 at 12:43:24AM +0300, Heikki Linnakangas wrote:
On 19/04/2024 19:48, Jacob Champion wrote:
On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas wrote:
With direct SSL negotiation, we
On Mon, Apr 22, 2024 at 03:40:01PM +0200, Majid Garoosi wrote:
> Any news, comments, etc. about this thread?
FWIW, I'd still be in favor of doing a GUC-ification of this part, but
at this stage I'd need more time to do a proper study of a case where
this shows benefits to prove your point, or some
On Tue, May 24, 2016 at 03:01:13PM -0400, Tom Lane wrote:
> Also, I notice another problem in vac_truncate_clog() now that I'm looking
> at it: it's expecting that the pg_database datfrozenxid and datminmxid
> values will hold still while it's looking at them. Since
> vac_update_datfrozenxid updat
On Mon, Apr 22, 2024 at 06:46:27PM +0200, Matthias van de Meent wrote:
> On Mon, 22 Apr 2024 at 17:41, Tom Lane wrote:
>> Matthias van de Meent writes:
>>> 0002/0004 remove fields in ExecRowMark which were added for FDWs to
>>> use, but there are no FDWs which use this: I could only find two FDWs
Hi,
On 2024-04-22 18:10:17 -0400, Robert Haas wrote:
> cfbot is giving me a bunch of green check marks, so I plan to commit
> this version, barring objections.
Makes sense.
> I shall leave redesign of the symlink mess as a matter for others to
> ponder; I'm not in love with what we have, but I
On Mon, 2024-04-22 at 16:19 -0400, Tom Lane wrote:
> Loading data without stats, and hoping
> that auto-analyze will catch up sooner not later, is exactly the
> current behavior that we're doing all this work to get out of.
That's the disconnect, I think. For me, the main reason I'm excited
about
On Sun, Mar 31, 2024 at 8:12 PM Andrey M. Borodin wrote:
>
>
>
> > On 15 Aug 2023, at 07:38, Peter Smith wrote:
> >
> > A rebase was needed due to a recent push [1].
> >
> > PSA v3.
>
>
> > On 14 Jan 2024, at 10:43, vignesh C wrote:
> >
> > I have changed the status of the patch to "Waiting on A
hi.
/*
* clamp_row_est
* Force a row-count estimate to a sane value.
*/
double
clamp_row_est(double nrows)
{
/*
* Avoid infinite and NaN row estimates. Costs derived from such values
* are going to be useless. Also force the estimate to be at least one
* row, to make explain output look bette
On Mon, Apr 22, 2024 at 7:04 PM Masahiko Sawada wrote:
>
> On Mon, Apr 22, 2024 at 9:02 PM shveta malik wrote:
> >
> > Thanks for the patch, the changes look good Amit. Please find the merged
> > patch.
> >
>
> I've reviewed the patch and have some comments:
>
> ---
> /*
> -* Early initi
Jeff Davis writes:
> On Mon, 2024-04-22 at 16:19 -0400, Tom Lane wrote:
>> Loading data without stats, and hoping
>> that auto-analyze will catch up sooner not later, is exactly the
>> current behavior that we're doing all this work to get out of.
> That's the disconnect, I think. For me, the mai
jian he writes:
> if (nrows > MAXIMUM_ROWCOUNT || isnan(nrows))
> nrows = MAXIMUM_ROWCOUNT;
> else if (nrows <= 1.0)
> nrows = 1.0;
> else
> nrows = rint(nrows);
> The comments say `Avoid infinite and NaN`
> but actually we only avoid NaN.
Really? The IEEE float arithmetic standard
> FWIW, I'd like to think that we could improve the situation, requiring
> a mix of calling pgstat_report_query_id() while feeding on some query
> IDs retrieved from CachedPlanSource->query_list. I have not in
> details looked at how much could be achieved, TBH.
I was dealing with this today and f
On 23/4/2024 11:16, Imseih (AWS), Sami wrote:
FWIW, I'd like to think that we could improve the situation, requiring
a mix of calling pgstat_report_query_id() while feeding on some query
IDs retrieved from CachedPlanSource->query_list. I have not in
details looked at how much could be achieved, T
Hi all,
While analyzing the use of internal error codes in the code base, I've
some problems, and that's a mixed bag of:
- Incorrect uses, for errors that can be triggered by users with
vallid cases.
- Expected error cases, wanted by the tests like corruption cases or
just to keep some code simp
Hi,
On Mon, Apr 22, 2024 at 03:00:00PM +0300, Alexander Lakhin wrote:
> 22.04.2024 13:52, Bertrand Drouvot wrote:
> >
> > That's weird, I just launched it several times with the patch applied and
> > I'm not
> > able to see the seg fault (while I can see it constently failing on the
> > master
On Mon, Apr 22, 2024 at 09:25:15AM -0400, Robert Haas wrote:
> That's long been my feeling about this. So, if we revert this for now,
> what we ought to do is put it back right ASAP after feature freeze and
> then clean all that up.
In the 85 backtraces I can find in the tests, we have a mixed bag
Hi,
I'm proposing a patch that making COPY format extendable:
https://www.postgresql.org/message-id/20231204.153548.2126325458835528809.kou%40clear-code.com
https://commitfest.postgresql.org/48/4681/
It's based on the discussion at:
https://www.postgresql.org/message-id/flat/3741749.1655952...@ss
On Mon, Apr 22, 2024 at 10:47:51AM +0300, Heikki Linnakangas wrote:
> On 22/04/2024 10:19, Michael Paquier wrote:
>> As a whole, I can get behind a unique GUC that forces the use of
>> direct. Or, we could extend the existing "ssl" GUC with a new
>> "direct" value to accept only direct connections
On Tue, Apr 23, 2024 at 11:42:41AM +0700, Andrei Lepikhov wrote:
> On 23/4/2024 11:16, Imseih (AWS), Sami wrote:
>> + pgstat_report_query_id(linitial_node(Query,
>> psrc->query_list)->queryId, true);
>> set_ps_display("BIND");
>> @@ -2146,6 +2147,7 @@ exec_execute_message(const char
On Sat, 20 Apr 2024 at 10:30, Alexander Lakhin wrote:
>
> Hello Michael and Robert,
>
> 20.04.2024 05:57, Michael Paquier wrote:
> > On Fri, Apr 19, 2024 at 01:57:41PM -0400, Robert Haas wrote:
> >> It looks to me like in the first run it took 3 minutes for the
> >> replay_lsn to catch up to the d
Hi hackers,
I proposal adding privileges test to improve
test coverage of pg_stat_statements.
## test procedure
./configure --enable-coverage --enable-tap-tests --with-llvm CFLAGS=-O0
make check-world
make coverage-html
## coverage
before Line Coverage 74.0 %(702/949 lines)
after Line Coverag
82 matches
Mail list logo
