Dear PostgreSQL Hackers,
I hope this email finds you well. As I delve into the codebase, I've
encountered some challenges understanding how routes are implemented within
the application.
As I navigate through the codebase, I've encountered some challenges
understanding how routes are implemented
On 3/5/2024 20:55, Robert Haas wrote:
One of my most embarrassing gaffes in this area personally was
a448e49bcbe40fb72e1ed85af910dd216d45bad8. I don't know how I managed
to commit the original patch without realizing it was going to cause
an increase in the WAL size, but I can tell you that when
On Sun, 5 May 2024 at 04:57, Tom Lane wrote:
>
> David Rowley writes:
> > That doesn't get you the benefits of fewer CPU cycles, but where did
> > that come from as a motive to change this? There's no shortage of
> > other ways to make the planner faster if that's an issue.
>
> The concern was
This fixes bug #18456 [1]. Since we're in back-branch release freeze,
I'll just park it for the moment. But I think we should shove it in
once the freeze lifts so it's in 17beta1.
regards, tom lane
[1]
> On Tue, Apr 30, 2024 at 04:29:11PM +0530, Ashutosh Bapat wrote:
> On Sun, Apr 28, 2024 at 12:29 PM Alexander Lakhin
> wrote:
>
> > 27.04.2024 18:00, Alexander Lakhin wrote:
> > >
> > > Please look also at another script, which produces the same error:
> >
> > I've discovered yet another
On Sat, May 4, 2024 at 11:29 AM Tom Lane wrote:
> I think we intentionally did not bother with preventing this,
> on the grounds that if you were silly enough to name a column
> that way then you deserve any ensuing problems.
Fair enough.
> If we were going to expend any code on the scenario,
David Rowley writes:
> I don't think you'd need to wait longer than where we do set_cheapest
> and find no paths to find out that there's going to be a problem.
At a base relation, yes, but that doesn't work for joins: it may be
that a particular join cannot be formed, yet other join sequences
Hi Team,
There are couple of updates, firstly we got an AIX node on the OSU lab.
Please feel free to reach me, so that we can provide access to the node.
We have started working on setting up the buildfarm on that node.
Secondly, as part of the buildfarm setup on our local nodes, we are hitting
Hello, Matthias!
> We can just release the current snapshot, and get a new one, right? I
> mean, we don't actually use the transaction for much else than
> visibility during the first scan, and I don't think there is a need
> for an actual transaction ID until we're ready to mark the index entry
Joseph Koshakow writes:
> There's a rare edge case in `alter table` that can prevent users from
> dropping a column as shown below
> # create table atacc1(a int, "pg.dropped.1" int);
> CREATE TABLE
> # alter table atacc1 drop column a;
> ERROR: duplicate key
Hi all,
There's a rare edge case in `alter table` that can prevent users from
dropping a column as shown below
# create table atacc1(a int, "pg.dropped.1" int);
CREATE TABLE
# alter table atacc1 drop column a;
ERROR: duplicate key value violates unique constraint
On Sat, 4 May 2024 at 08:34, Robert Haas wrote:
> Another idea is to remove the ERROR mentioned above from
> set_cheapest() and just allow planning to continue even if some
> relations end up with no paths. (This would necessitate finding and
> fixing any code that could be confused by a pathless
On Thu, May 02, 2024 at 01:52:20PM +0500, Andrey M. Borodin wrote:
> As far as I understand this will effectively forbid calling
> injection_points_detach() for local injection point of other
> backend. Do I get it right?
Yes, that would be the intention. Noah has other use cases in mind
with
On Fri, May 03, 2024 at 03:49:08PM -0500, Nathan Bossart wrote:
> On Wed, May 01, 2024 at 12:39:53PM +0900, Michael Paquier wrote:
>> By the way, shouldn't we also change the function to return NULL for a
>> failed permission check? It would be possible to remove the
>> has_sequence_privilege()
On Fri, May 03, 2024 at 05:22:06PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> IIUC this would cause other sessions' temporary sequences to appear in the
>> view. Is that desirable?
>
> I assume Michael meant to move the test into the C code, not drop
> it entirely --- I agree we don't
On 2024-May-03, Justin Pryzby wrote:
> But if it's created with LIKE:
> postgres=# CREATE TABLE t1 (LIKE t);
> postgres=# ALTER TABLE t ATTACH PARTITION t1 DEFAULT ;
>
> ..one also sees:
>
> Not-null constraints:
> "t1_i_not_null" NOT NULL "i"
Hmm, I think the problem here is not ATTACH;
> On 3 May 2024, at 21:21, Tom Lane wrote:
>
> Peter Eisentraut writes:
>> On 03.05.24 10:39, Daniel Gustafsson wrote:
>>> They are no-ops when linking against v18, but writing an extension which
>>> targets all supported versions of postgres along with their respective
>>> supported OpenSSL
> On 3 May 2024, at 11:18, Andrey M. Borodin wrote:
>
Here's the documentation from ClickHouse [0] for their implementation. It's
identical to provided patch in this thread, with few notable exceptions:
1. Counter is 42 bits, not 18. The counter have no guard bits, every bit is
18 matches
Mail list logo
