Hi Tom, hi Alvaro,
> On 27 Nov 2024, at 19:52, Tom Lane wrote:
>
> Okay, so I was able to reproduce this from scratch on HEAD:
great, thanks.
> I doubt that there's anything actually wrong with the catalog state at
> this point (perhaps Alvaro would confirm that). That leads to the
> conclusi
Hi, ALL,
In April of 2017 I got the source code of the Postgresql, build the libpq
and then deleted everything else.
I was using MSVC 3010 at the time.
Now I moved to MSVC 2017 but unfortunately I can't reuse the library built,
since MSVC changed one of its headers.
Is it possible to find what
On Thu, Nov 28, 2024 at 11:35 PM Tom Lane wrote:
> I wrote:
> > Thanks for the test case! A quick "git bisect" says I broke it at
> > cb8e50a4a09fe541e32cd54ea90a97f2924121a1 is the first bad commit
> > commit cb8e50a4a09fe541e32cd54ea90a97f2924121a1
> > Author: Tom Lane
> > Date: Fri Aug 30
I wrote:
> Thanks for the test case! A quick "git bisect" says I broke it at
> cb8e50a4a09fe541e32cd54ea90a97f2924121a1 is the first bad commit
> commit cb8e50a4a09fe541e32cd54ea90a97f2924121a1
> Author: Tom Lane
> Date: Fri Aug 30 12:42:12 2024 -0400
> Avoid inserting PlaceHolderVars in ca
Hello,
My doubt here is, in a master - slave (streaming replication) set up, when I
run a long running delete query for deleting 80 million records, . All queries
in slave started running 2- 5 mins all of a sudden. When I check SQL analyse,
most of the queries, planner used to choose seq scan,
Bertrand Mamasam writes:
> Ok thank you, here is a short version of the query that works before 16.5
> but not in 16.5+ anymore.
Thanks for the test case! A quick "git bisect" says I broke it at
cb8e50a4a09fe541e32cd54ea90a97f2924121a1 is the first bad commit
commit cb8e50a4a09fe541e32cd54ea90a
On Thu, Nov 28, 2024 at 5:15 PM Tom Lane wrote:
> Bertrand Mamasam writes:
> > I get this error in PG16.5, 16.6 and 17 :
> > wrong varnullingrels (b 3) (expected (b)) for Var 1/19
>
> Please provide a self-contained test case. A fragmentary query
> with no underlying tables is useless for inves
Bertrand Mamasam writes:
> I get this error in PG16.5, 16.6 and 17 :
> wrong varnullingrels (b 3) (expected (b)) for Var 1/19
Please provide a self-contained test case. A fragmentary query
with no underlying tables is useless for investigation.
https://wiki.postgresql.org/wiki/Guide_to_reportin
Hello,
My query has been working fine in 16.4 and before, but not anymore in 16.5,
16.6 and 17. It is a query with multiple CTE, some of which are using
values of the previous ones, and the end of the query sort of make a mix of
found values with aggregation from a LATERAL JOIN. Something like thi
