Peter Eisentraut writes:
> On 31.07.24 20:39, Andres Freund wrote:
>> I Wonder if I should also should add -Wno-clobbered to serinus' config.
>> Afaict
>> -Wclobbered is pretty useless once optimizations are used. I've long added
>> that to my local dev environment flags because it's so noisy
On 02.08.24 19:51, Jacob Champion wrote:
But it sounds like we agree that we shouldn't be using fe_memutils at
all in shlib builds. (If you can't use palloc -- it calls exit -- then
you can't use pfree either.) Is 0002 still worth pursuing, once I've
correctly wordsmithed the commit? Or did I
On 01.08.24 23:38, Andrew Dunstan wrote:
Not totally opposed, and I will probably give it a try very soon, but
I'm wondering if this really needs to go in the core repo. We've
generally shied away from doing much in the way of editor / devenv
support, trying to be fairly agnostic. It's true we
On Fri, Aug 2, 2024 at 10:40 AM Robert Haas wrote:
> My belief is that nearly everything in unsafe. We ship with very
> little marked leakproof right now, and that might be too conservative,
> but probably not by much.
Then to me, that seems like the best-case scenario for a "maybe"
On Fri, Aug 2, 2024 at 10:13 AM Peter Eisentraut wrote:
> You shouldn't use pfree() interchangeably with free(), even if that is
> not enforced because it's the same thing underneath. First, it just
> makes sense to keep the alloc and free pairs matched up. And second, on
> Windows there is
On Fri, Aug 2, 2024 at 12:33 PM Jacob Champion
wrote:
> (Now, if there aren't that many cases where we can all agree on
> "unsafe", then the proposal loses pretty much all value, because we'll
> never shrink the uncertainty.)
My belief is that nearly everything in unsafe. We ship with very
On 31.07.24 20:39, Andres Freund wrote:
On 2024-07-31 11:32:56 -0700, Andres Freund wrote:
On 2024-07-31 10:11:07 -0400, Tom Lane wrote:
It looks like serinus needs this fix too.
Added to both. I've forced runs for both animals, so the bf should show
results of that soon.
I Wonder if I
On 30.07.24 00:30, Jacob Champion wrote:
But under what circumstances does "the linker doesn't strip out" happen?
If this happens accidentally, then we should have seen some buildfarm
failures or something?
On my machine, for example, I see differences with optimization
levels. Say you
Hello, Amit!
> I think it is rather less likely or not possible in a parallel apply
> case because such conflicting updates (updates on the same tuple)
> should be serialized at the publisher itself. So one of the updates
> will be after the commit that has the second update.
Glad to hear! But
> On 18 Jul 2024, at 03:55, Michael Paquier wrote:
>
> If there is anything else you would like to see adjusted in this area,
> please let me know.
I’ve tried to switch my multixact test to new INJECTION_POINT_CACHED… and it
does not work for me. Could you please take a look?
2024-08-02
On Fri, Aug 2, 2024 at 12:51 PM Tom Lane wrote:
> That absolutely is the expectation, and we'd better be careful not
> to break it.
I have every intention of not breaking it. :-)
--
Robert Haas
EDB: http://www.enterprisedb.com
Robert Haas writes:
> On Fri, Aug 2, 2024 at 9:13 AM David Rowley wrote:
>> ... That way you maintain the
>> existing behaviour of not optimising for disabled node types and don't
>> risk plan changes if the final cost comes out cheaper than the initial
>> cost.
> All three initial_cost_XXX
We did run our application under valgrind on Linux. We did not see any
leaks. There is no platform dependent code in our application. We are
seeing gradual memory growth only on windows.
That is what lead me to believe the leak may be present in postgresql. I
will run under available memory tools
On Fri, Aug 2, 2024 at 9:22 AM Robert Haas wrote:
> I'll be honest: I don't like it, either. I don't even like
> proleakproof=true/false/maybe; I asked about that to understand if
> that was what Jacob was proposing, not because I actually think we
> should do it. The problem is that there's
On Fri, Aug 2, 2024 at 11:07 AM Tom Lane wrote:
> Joe Conway writes:
> >
> > Hmmm, and then have "leakproof_mode" = strict/lax/off where 'strict' is
> > current behavior, 'lax' allows the 'maybe's to get pushed down, and
> > 'off' ignores the leakproof attribute entirely and pushes down
On Fri, Aug 2, 2024 at 9:13 AM Joe Conway wrote:
>
> On 8/2/24 11:07, Tom Lane wrote:
> > Joe Conway writes:
> >>
> >> Hmmm, and then have "leakproof_mode" = strict/lax/off where 'strict' is
> >> current behavior, 'lax' allows the 'maybe's to get pushed down, and
> >> 'off' ignores the
Em sex., 2 de ago. de 2024 às 11:54, Rajesh Kokkonda <
rajeshk.kokko...@gmail.com> escreveu:
> Okay. I will try to create one sample program and send it to you sometime
> next week. In the meantime, I am listing down all the methods we are
> consuming from libpq.
>
> PQconnectdbParams
> PQstatus
On 8/2/24 11:07, Tom Lane wrote:
Joe Conway writes:
Hmmm, and then have "leakproof_mode" = strict/lax/off where 'strict' is
current behavior, 'lax' allows the 'maybe's to get pushed down, and
'off' ignores the leakproof attribute entirely and pushes down anything
that merits being pushed?
Hello,
On 2024-Aug-02, Kyotaro Horiguchi wrote:
> I found that pg_createsubscriber doesn't use NLS files. This is due to
> the wrong reference name "pg_createsubscriber" being passed to
> set_pglocale_pgservice(). It should be "pg_basebackup" instead. See
> the attached patch.
Absolutely right.
On Fri, Aug 2, 2024 at 9:13 AM David Rowley wrote:
> I now think neither of us got it right. I now think what you'd need to
> do to be aligned to the current behaviour is have
> initial_cost_nestloop() add the disabled_nodes for the join's subnodes
> *only* and have final_cost_nestloop() add the
On Tue, 9 Jul 2024 at 03:18, Andy Fan wrote:
>> and later we called 'tuplesort_performsort(state->bs_sortstate);'. Even
>> we have some CTID merges activity in '(1)', the tuples are still
>> ordered, so the sort (in both tuplesort_putgintuple and
>> 'tuplesort_performsort) are not
Joe Conway writes:
>
> Hmmm, and then have "leakproof_mode" = strict/lax/off where 'strict' is
> current behavior, 'lax' allows the 'maybe's to get pushed down, and
> 'off' ignores the leakproof attribute entirely and pushes down anything
> that merits being pushed?
>
So in other words, we
Okay. I will try to create one sample program and send it to you sometime
next week. In the meantime, I am listing down all the methods we are
consuming from libpq.
PQconnectdbParams
PQstatus
PQerrorMessage
PQpingParams
PQfinish
PQresultStatus
PQclear
PQsetSingleRowMode
PQntuples
PQnfields
On Fri, Aug 2, 2024 at 6:58 AM Joe Conway wrote:
> On 8/2/24 09:48, Jacob Champion wrote:
> > On Thu, Aug 1, 2024 at 6:03 PM Robert Haas
> wrote:
> >>
> >> On Thu, Aug 1, 2024 at 4:45 PM Jacob Champion
> >> wrote:
> >> > Would it provide enough value for effort to explicitly mark leaky
> >> >
On Aug 1, 2024, at 18:54, Thomas Munro wrote:
> Done (e52a44b8, 91f498fd).
>
> Any elucidation on how and why Windows machines have started using
> UTF-8 would be welcome.
Haven’t been following this thread, but this post reminded me of an issue I saw
with locales on Windows[1]. Could it be
On 8/2/24 09:48, Jacob Champion wrote:
On Thu, Aug 1, 2024 at 6:03 PM Robert Haas wrote:
On Thu, Aug 1, 2024 at 4:45 PM Jacob Champion
wrote:
> Would it provide enough value for effort to explicitly mark leaky
> procedures as such? Maybe that could shrink the grey area enough to be
>
Peter Eisentraut writes:
> I propose to remove the obsolete RECHECK keyword completely. This used
> to be part of CREATE OPERATOR CLASS and ALTER OPERATOR FAMILY, but it
> has done nothing (except issue a NOTICE) since PostgreSQL 8.4. Commit
> 30e7c175b81 removed support for dumping from
Rajesh Kokkonda writes:
> Are you looking for a fully functional sample program or only the APIs from
> libpq library that our product uses? I am asking this because if the
> requirement is to have a sample code, then I will have to work on creating
> one on the same lines as our product.
Just
On Thu, Aug 1, 2024 at 6:03 PM Robert Haas wrote:
>
> On Thu, Aug 1, 2024 at 4:45 PM Jacob Champion
> wrote:
> > Would it provide enough value for effort to explicitly mark leaky
> > procedures as such? Maybe that could shrink the grey area enough to be
> > protective?
>
> You mean like
On Fri, Apr 19, 2024 at 11:47 AM Robert Haas wrote:
> Hmm, that's an interesting perspective. I've always been very
> skeptical of doing verification only around missing files and not
> anything else. I figured that wouldn't be particularly meaningful, and
> that's pretty much the only kind of
On Sat, 3 Aug 2024 at 00:17, Robert Haas wrote:
>
> On Thu, Aug 1, 2024 at 11:34 PM David Rowley wrote:
> > I'm not planning on pushing this any further. I've just tried to
> > highlight that there's the possibility of a behavioural change. You're
> > claiming there isn't one. I claim there is.
n the code and re-ran test1-case2 (which initially took
~6 minutes). Without conflict logging, the duration was reduced to
"2min 56sec 758 ms".
Test4 - Code Profiling
To narrow down the cause of the time overhead in T
On Thu, Aug 1, 2024 at 11:34 PM David Rowley wrote:
> I'm not planning on pushing this any further. I've just tried to
> highlight that there's the possibility of a behavioural change. You're
> claiming there isn't one. I claim there is.
I don't know what to tell you. The original version of the
Hi,
I have read the entire thread discussion. I understood the importance of
this enhancement related to /conninfo+ meta command. I really appreciate
the efforts of Maiquel and suggestions made by the reviewers. According to
best of my understanding, libpq API should be used instead of creating
On Fri, Aug 2, 2024 at 1:53 PM Rajesh Kokkonda
wrote:
> Hi Yasir,
>
> Are you looking for a fully functional sample program or only the APIs
> from libpq library that our product uses? I am asking this because if the
> requirement is to have a sample code, then I will have to work on creating
>
Hi Yasir,
Are you looking for a fully functional sample program or only the APIs from
libpq library that our product uses? I am asking this because if the
requirement is to have a sample code, then I will have to work on creating
one on the same lines as our product.
Rajesh
On Thu, Aug 1, 2024
re a lock
+ * is acquired, we will retry to find the conflicting tuple again.
*/
static bool
FindConflictTuple(ResultRelInfo *resultRelInfo, EState *estate,
@@ -528,25 +528,15 @@ retry:
}
/*
- * Re-check all the unique indexes in 'recheckIndexes' to see if there are
- * potential conflicts wit
Thanks for review!
On Fri, 2 Aug 2024 at 14:31, Ashutosh Bapat
wrote:
>
> On Fri, Aug 2, 2024 at 1:55 PM Kirill Reshke wrote:
> >
> > I hate to be "that guy", but there are many places in sources where we use
> > LOCKMODE lockmode; variable and exactly one where we use LOCKMODE
> > lmode: it is
I've been looking at cases where there are grouping-set keys that
reduce to Consts, and I noticed a plan with v11 patch that is not very
great.
explain (verbose, costs off)
select 1 as one group by rollup(one) order by one nulls first;
QUERY PLAN
---
Sort
On Fri, Aug 2, 2024 at 1:55 PM Kirill Reshke wrote:
>
> I hate to be "that guy", but there are many places in sources where we use
> LOCKMODE lockmode; variable and exactly one where we use LOCKMODE
> lmode: it is vacuum_open_relation function.
There are more instances of LOCKMODE lmode; I
> On 24 Jul 2024, at 17:42, Marat Bukharov wrote:
>
> V5 patch. I've added more tests with different bytea sizes
Hi Marat!
This looks like a nice feature to have.
I’ve took a look into the patch and have few suggestions:
0. Please write more descriptive commit message akin to [0]
1. Use
On Fri, Aug 2, 2024 at 2:24 PM shveta malik wrote:
>
> On Thu, Aug 1, 2024 at 9:26 AM shveta malik wrote:
> >
> > On Mon, Jul 29, 2024 at 4:17 PM vignesh C wrote:
> > >
> > > Thanks for reporting this, these issues are fixed in the attached
> > > v20240730_2 version patch.
> > >
>
> I was
01.08.2024 06:41, Tom Lane wrote:
But beside that, I've found a separate regression. Bisecting for this
degradation:
Best pg-src-17--.* worse than pg-src-16--.* by 105.0 percents (356.63 >
173.96): s64da_tpcds.query95
Average pg-src-17--.* worse than pg-src-16--.* by 105.2 percents (357.79 >
On Thu, Aug 1, 2024 at 9:26 AM shveta malik wrote:
>
> On Mon, Jul 29, 2024 at 4:17 PM vignesh C wrote:
> >
> > Thanks for reporting this, these issues are fixed in the attached
> > v20240730_2 version patch.
> >
I was reviewing the design of patch003, and I have a query. Do we need
to even
Thanks, I have set my name in the Authors column of CF.
Steven
Junwang Zhao 于2024年8月2日周五 13:22写道：
> Hi Steven,
>
> On Fri, Aug 2, 2024 at 12:12 PM Steven Niu wrote:
> >
> > Hi, Junwang,
> >
> > Thank you for the review and excellent summary in commit message!
> >
> > This is my first
On Fri, 2 Aug 2024 at 11:09, Antonin Houska wrote:
>
> Kirill Reshke wrote:
> > However, in general, the 3rd patch is really big, very hard to
> > comprehend. Please consider splitting this into smaller (and
> > reviewable) pieces.
>
> I'll try to move some preparation steps into separate
On Thu, Aug 1, 2024 at 7:33 PM Dean Rasheed wrote:
>
> On Mon, 29 Jul 2024 at 11:22, Dean Rasheed wrote:
> >
> > Trivial rebase, following c7301c3b6f.
> >
>
> Rebased version, forced by a7f107df2b. Evaluating the input parameters
> of correlated SubPlans in the referencing ExprState simplifies
On Thu, 01 Aug 2024 11:31:53 -0700
Jeff Davis wrote:
> On Wed, 2024-07-31 at 18:20 +0900, Yugo NAGATA wrote:
> > I agree that it might not be important, but I think adding the flag
> > would be
> > also helpful for improving code-readability because it clarify the
> > function
> > is used in the
Hi,
I've added a CF entry for this patch:
https://commitfest.postgresql.org/49/5148/
Not sure why CFbot CI fails on macOS/Windows while it works with the Github
CI on my fork (
https://cirrus-ci.com/github/pgstef/postgres/partial-walseg-recovery).
Many thanks in advance for your feedback and
On Sat, 2024-07-27 at 21:08 -0400, Corey Huinker wrote:
>
> > I don't like the idea of mixing statistics and control parameters
> > in
> > the same list.
> >
>
>
> There's no way around it, at least now we need never worry about a
> confusing order for the parameters in the _restore_ functions
Kirill Reshke wrote:
> What is the size of the biggest relation successfully vacuumed
> via pg_squeeze?
> Looks like in case of big relartion or high insertion load,
> replication may lag and never catch up...
Users reports problems rather than successes, so I don't know. 400 GB was
reported in
Dear Fujii-san,
> Thanks for updating the patch!
>
> > - Changed the name of new API from `GetUserMappingFromOid` to
> `GetUserMappingByOid`
> >to keep the name consistent with others.
>
> If we expose this function as an FDW helper function, it should return
> a complete UserMapping
Nathan Bossart writes:
> I've recently committed some optimizations for dumping sequences and
> pg_class information (commits 68e9629, bd15b7d, and 2329cad), and I noticed
> that we are also executing a query per function in pg_dump. Commit be85727
> optimized this by preparing the query ahead
Hi Steven,
On Fri, Aug 2, 2024 at 12:12 PM Steven Niu wrote:
>
> Hi, Junwang,
>
> Thank you for the review and excellent summary in commit message!
>
> This is my first contribution to community, and not so familiar with the
> overall process.
> After reading the process again, it looks like
On Thu, Aug 1, 2024 at 2:55 PM Michail Nikolaev
wrote:
>
> > Thanks for pointing out the issue!
>
> Thanks for your attention!
>
> > IIUC, the issue can happen when two concurrent transactions using
> > DirtySnapshot access
> > the same tuples, which is not specific to the parallel apply
>
> Not
Hi, Junwang,
Thank you for the review and excellent summary in commit message!
This is my first contribution to community, and not so familiar with the
overall process.
After reading the process again, it looks like that I'm not qualified to
submit the patch to commitfest as I never had reviewed
Richard Guo writes:
> Yeah, it's not the fault of the plan cache. I noticed this because in
> check_ungrouped_columns, both Const and Param are treated as always
> acceptable. However, in setrefs.c these two expression types are
> handled differently: Const is never matched to the lower tlist,
Hello Euler,
01.08.2024 21:09, Euler Taveira wrote:
According to this discussion, there isn't a clue about the root cause.
If you have a test case, share it (mainly if you are observing it in
version 16+ that exposes some data which may be useful for analysis).
Please take a look at [1],
On Fri, 2 Aug 2024 at 06:03, Robert Haas wrote:
> I think this may be a bit hard to understand, so let me give a
> concrete example. Suppose we're planning some join where one side can
> only be planned with a sequential scan and sequential scans are
> disabled. We have ten paths in the path list
On Thu, Jul 25, 2024 at 8:38 PM Michael Paquier wrote:
> On Wed, Jul 24, 2024 at 01:09:22PM +0200, Alvaro Herrera wrote:
> > Hmm, it appears that these symbols did not exist in 1.1.1g, and since
> > neither of them is invoked directly by the Postgres code, maybe the
> > reason for this is that
On Thu, Aug 1, 2024 at 10:34 PM Tom Lane wrote:
> Richard Guo writes:
> > While working on the grouping sets patches for queries with GROUP BY
> > items that are constants, I noticed $subject on master. As an
> > example, consider
>
> This particular example seems like it's just an illustration
On Thu, Aug 1, 2024 at 4:45 PM Jacob Champion
wrote:
> Would it provide enough value for effort to explicitly mark leaky
> procedures as such? Maybe that could shrink the grey area enough to be
> protective?
You mean like proleakproof = true/false/maybe?
--
Robert Haas
EDB:
Maciek Sakrejda writes:
> Oddly, it looks like you only get a null if you use the '->>'
> operator. With '->' and a subsequent cast to text, you get the string
> "null":
> maciek=# select (('{"a":null}'::jsonb)->'a')::text;
> text
> --
> null
> (1 row)
> Is that expected?
I think what is
On Thu, Aug 1, 2024 at 3:52 PM Tom Lane wrote:
> I complained in the discussion of bug #18564 [1] that it's quite
> inconsistent that you can cast a jsonb null to text and get
> a SQL NULL:
>
> =# select ('{"a": null}'::jsonb)->>'a';
> ?column?
> --
>
> (1 row)
Oddly, it looks like you
On Wed, Jul 31, 2024 at 11:27 PM Anthonin Bonnefoy
wrote:
>
> On Wed, Jul 31, 2024 at 9:36 PM Masahiko Sawada wrote:
> > Meanwhile, I think we can push 0001 and 0002 patches since they are in
> > good shape. I've updated commit messages to them and slightly changed
> > 0002 patch to write
On Fri, Aug 2, 2024 at 1:37 AM Oleg Tselebrovskiy
wrote:
> I would appreciate if you would backpatch this change to 15 and 16
> branches.
Done (e52a44b8, 91f498fd).
Any elucidation on how and why Windows machines have started using
UTF-8 would be welcome.
soon as we need to copy paths, I've
enabled native copy of paths. Now, we can do just copyObject() over
path in caller. Looks much cleaner for me. What do you think?
Other notes:
1) I think we need to cover the cases, which
is_inner_rel_safe_for_asymmetric_join() filters out, by regression
t
On Thu, Aug 01, 2024 at 12:44:35PM -0500, Nathan Bossart wrote:
> On Wed, Jul 31, 2024 at 10:55:33PM +0100, Ilya Gladyshev wrote:
>> I like your idea of parallelizing these checks with async libpq API, thanks
>> for working on it. The patch doesn't apply cleanly on master anymore, but
>> I've
On 2024-08-01 Th 10:56 AM, Junwang Zhao wrote:
Stack Overflow 2024 developer survey[1] said VSCode
is the most used development environment.
In a PostgreSQL Hacker Mentoring discussion, we talked
about how to use vscode to debug and running postgres,
Andrey(ccd) has tons of tips for new
On 2024-08-01 Th 5:00 AM, Alexander Lakhin wrote:
I also wrote a simple script (see attached) to check for unknown
buildfarm
failures using "HTML API", to make sure no failures missed. Surely, it
could be improved in many ways, but I find it rather useful as-is.
I think we can improve
On Sun, Jul 28, 2024 at 10:03:56PM +0200, Dmitry Dolgov wrote:
> So far I've got nothing against :)
I've looked again at the first patch of this series, and applied the
first one. Another last-minute edit I have done is to use more
consistently PgStat_Kind in the loops for the stats kinds across
On Thu, Aug 1, 2024 at 7:26 AM Tom Lane wrote:
> Are you proposing that we invent two levels of leakproofness
> with different guarantees? That seems like a mess, not least
> because there are going to be varying opinions about where we
> should set the bar for the lower level.
It kind of
On Wed, Jul 31, 2024 at 1:26 PM Robert Haas wrote:
> However, the risk is that an end-user is going to be much less able to
> evaluate what is and isn't safe than we are. I think some people are
> going to be like -- well the core project doesn't mark enough stuff
> leakproof, so I'll just go add
On Fri, 2024-08-02 at 00:13 +0500, Kirill Reshke wrote:
> On Thu, 1 Aug 2024 at 23:27, Jeff Davis wrote:
> >
> > EXPLAIN ANALYZE CREATE MATERIALIZED VIEW doesn't go through
> > ExecCreateTableAs(), but does use CreateIntoRelDestReceiver().
>
> EXPLAIN ANALYZE and regular query goes through
Jeff Davis wrote:
> > col LIKE 'smith%' collate "nd"
> >
> > is equivalent to:
> >
> > col >= 'smith' collate "nd" AND col < U&'smith\' collate "nd"
>
> That logic seems to assume something about the collation. If you have a
> collation that orders strings by their sha256 hash,
On Thu, 1 Aug 2024 at 23:27, Jeff Davis wrote:
>
> EXPLAIN ANALYZE CREATE MATERIALIZED VIEW doesn't go through
> ExecCreateTableAs(), but does use CreateIntoRelDestReceiver().
EXPLAIN ANALYZE and regular query goes through create_ctas_internal
(WITH NO DATA case too). Maybe we can simply move
Hi!
On Tue, Apr 2, 2024 at 6:07 AM Andrei Lepikhov
wrote:
> On 15/10/2023 13:25, Alexander Korotkov wrote:
> > Great! I'm looking forward to the revised patch.
> Revising the code and opinions before restarting this work, I found two
> different possible strategies mentioned in the thread:
> 1.
On Thu, 1 Aug 2024 at 23:27, Jeff Davis wrote:
> Relatedly, if we can EXPLAIN a CREATE MATERIALIZED VIEW, perhaps we
> should be able to EXPLAIN a REFRESH MATERIALIZED VIEW, too?
Sure
> Comments?
Seems like this is indeed inconsistent behaviour and should be fixed
in all PGDG-supported versions
On Wed, 2024-07-31 at 18:20 +0900, Yugo NAGATA wrote:
> I agree that it might not be important, but I think adding the flag
> would be
> also helpful for improving code-readability because it clarify the
> function
> is used in the two cases. I attached patch for this fix (patch 0003).
Committed
On Thu, Aug 1, 2024, at 6:59 AM, Pradeep Kumar wrote:
> Any update on this?
Are you using version 11? This version is obsolete and is not supported
anymore. Consider a supported version [1].
Per the following commit (in version 16), this Assert was replaced by
elog.
commit:
On Wed, Jul 31, 2024 at 10:01 PM David Rowley wrote:
> I've reviewed both patches, here's what I noted down during my review:
Thanks.
> 0. I've not seen any mention so far about postgres_fdw's
> use_remote_estimate. Maybe changing the costs is fixing an issue that
> existed before. I'm just
On Wed, Jul 31, 2024 at 10:55:33PM +0100, Ilya Gladyshev wrote:
> I like your idea of parallelizing these checks with async libpq API, thanks
> for working on it. The patch doesn't apply cleanly on master anymore, but
> I've rebased locally and taken it for a quick spin with a pg16 instance of
>
Hi,
On Thu, 1 Aug 2024 at 18:44, Andres Freund wrote:
> On 2024-08-01 12:45:16 +0200, Matthias van de Meent wrote:
> > Here's one that covers both master and the v17 backbranch.
>
> FWIW, I find it quite ugly to use BlockNumber to indicate the number of blocks
> to be written. It's just further
On 2024/07/29 12:58, Hayato Kuroda (Fujitsu) wrote:
Dear Fujii-san,
IIUC, the patch which adds user_name attribute to get_connection() can be
discussed
in later stage, is it right?
No, let's work on the patch at this stage :)
OK, here is a rebased patch.
Thanks for updating the
On Tue, Jul 30, 2024 at 08:53:48AM +, Bertrand Drouvot wrote:
> Did a quick check and still LGTM.
Applied 0003 for now to add the redo LSN to the pgstats file, adding
the redo LSN to the two DEBUG2 entries when reading and writing while
on it, that I forgot. (It was not 01:57 where I am
Hi,
On 2024-08-01 12:45:16 +0200, Matthias van de Meent wrote:
> On Tue, 30 Jul 2024 at 14:32, Thomas Munro wrote:
> >
> > On Tue, Jul 30, 2024 at 11:24 PM Matthias van de Meent
> > wrote:
> > > While working on rebasing the patches of Neon's fork onto the
> > > REL_17_STABLE branch, I noticed
On Thu, 1 Aug 2024 at 16:56, Junwang Zhao wrote:
> I post my daily used devcontainer config[2] , Jelte(ccd)
> suggested that it might be a good idea we integrate the
> config into postgres repo so that the barrier to entry for
> new developers will be much lower.
In my experience adding a
+/*
+ * Calculate CRC32 of the given data.
+ */
+static inline pg_crc32
+crc32_sz(const char *buf, int size)
+{
+ pg_crc32crc;
+ const char *p = buf;
+
+ INIT_TRADITIONAL_CRC32(crc);
+ while (size > 0)
+ {
+ charc = (char) (*p);
+
+
On Thu, Aug 1, 2024 at 10:05 AM Joe Conway wrote:
> Sure. Of course you should be monitoring your production servers for
> anomalous workloads, no? "Gee, why is Joe running the same query
> millions of times that keeps throwing errors? Maybe we should go see
> what Joe is up to"
I think it's
Richard Guo writes:
> While working on the grouping sets patches for queries with GROUP BY
> items that are constants, I noticed $subject on master. As an
> example, consider
This particular example seems like it's just an illustration of
our known bugs with grouping sets using non-Var columns.
Joe Conway writes:
> On 8/1/24 07:17, Laurenz Albe wrote:
>> But what do you tell the users who would not accept that risk?
> Document that the option should not be used if that is the case
Are you proposing that we invent two levels of leakproofness
with different guarantees? That seems like
On 8/1/24 07:57, Robert Haas wrote:
On Wed, Jul 31, 2024 at 4:42 PM Joe Conway wrote:
You are assuming that everyone allows direct logins with the ability to
create procedures. Plenty don't.
Well, if you can send queries, then you can do the same thing, driven
by client-side logic.
Sure.
On 8/1/24 07:17, Laurenz Albe wrote:
On Wed, 2024-07-31 at 14:43 -0400, Joe Conway wrote:
I still maintain that there is a whole host of users that would accept
the risk of side channel attacks via existence of an error or not, if
they could only be sure nothing sensitive leaks directly into
Thomas Munro wrote 2024-05-12 06:31:
Hamerkop is already green on the 15 and 16 branches, apparently
because it's using the pre-meson test stuff that I guess just didn't
run the relevant test. In other words, nobody would notice the
difference anyway, and a master-only fix would be enough to
Hi Steven,
On Wed, Jul 31, 2024 at 11:16 AM Steven Niu wrote:
>
> Hello, hackers,
>
> I think there may be some duplicated codes.
> Function smgrDoPendingDeletes() calls both smgrdounlinkall() and smgrclose().
> But both functions would close SMgrRelation object, it's dupliacted behavior?
>
> So
On Wed, Jul 31, 2024 at 4:42 PM Joe Conway wrote:
> You are assuming that everyone allows direct logins with the ability to
> create procedures. Plenty don't.
Well, if you can send queries, then you can do the same thing, driven
by client-side logic.
If you can't directly send queries in any
Hi Rajesh,
Can you please attach a sample code snippet showing libpq's functions being
called? It will help to identify the libpq's functions to investigate
further for a potential mem leak.
Regards...
Yasir Hussain
On Thu, Aug 1, 2024 at 4:30 PM Rajesh Kokkonda
wrote:
> Hi,
>
> We are
On Thu, Aug 1, 2024 at 2:26 PM Hayato Kuroda (Fujitsu)
wrote:
>
> 04. general
>
> According to the documentation [1], there is another constraint "exclude",
> which
> can cause another type of conflict. But this pattern cannot be logged in
> detail.
>
As per docs, "exclusion constraints can
čt 1. 8. 2024 v 13:22 odesílatel Laurenz Albe
napsal:
> On Thu, 2024-08-01 at 08:12 +0200, Pavel Stehule wrote:
> > fresh rebase + fix format in doc
>
> Thanks!
>
> I'm curious, but too lazy to build the patch now, so I'm asking:
> what did you do about this error?
>
I try to investigate this
On Thu, 2024-08-01 at 08:12 +0200, Pavel Stehule wrote:
> fresh rebase + fix format in doc
Thanks!
I'm curious, but too lazy to build the patch now, so I'm asking:
what did you do about this error?
> CREATE VARIABLE var AS date;
> LET var = current_date;
> PREPARE stmt(date) AS SELECT $1;
>
1 - 100 of 161774 matches
Mail list logo
