On Sat, Mar 22, 2025 at 2:21 AM Tom Lane wrote:
> Ugh, no, that is *completely* unworkable. Suppose that the user
> does CREATE VIEW, and the parse tree recorded for that claims that
> column X is not-nullable. Then the user drops the not-null
> constraint, and then asks to execute the view. We
On 3/22/25 23:49, Tom Lane wrote:
I spent awhile reviewing the v5 patch, and here's a proposed v6.
Some notes:
* I didn't like depending on offsetof(Pg_magic_struct, module_extra)
to determine which parts of the struct are checked for compatibility.
It just seems way too easy to break that with
Hi,
I stumbled upon a problem with the scram_iterations GUC where setting
scram_iterations to INT_MAX and then creating a user causes the command to
hang indefinitely.
postgres=# SET scram_iterations=2147483647;
SET
postgres=# CREATE ROLE maxscram WITH PASSWORD 'forever';
I looked into the rele
Hello hackers,
A recent buildfarm failure [1] with the following diagnostics:
72/72 postgresql:postgres_fdw-running / postgres_fdw-running/regress
ERROR 19.04s exit status 1
postgres_fdw-running/regress/results/postgres_fdw.out
--- /home/bf/bf-build/culicidae/HEAD/pgsql
On 2025/03/21 21:29, torikoshia wrote:
Hi,
On 2025-03-21 02:15, Fujii Masao wrote:
Thanks for your review!
Personally, I feel 1st patch may be sufficient, but I would appreciate any
feedback.
Agreed.
- errdetail("Consistent recovery state has not been yet
re
> > but the opposite may be
> > not necessarily true: a query ID could be associated with multiple
> > plan patterns (aka multiple plan IDs). What this offers is that we
> > know about which plan one query is currently using in live, for a
> > given query ID.
> Okay, as I've said before, it seems
On 2025/03/21 10:07, Hayato Kuroda (Fujitsu) wrote:
Dear Fujii-san,
Unless there are any objections, I plan to push your patch with
the following commit message and back-patch it to all supported versions.
...
Thanks for updating the commit message. LGTM.
I've committed the patch with th
Hi,
On 2025-03-22 17:20:56 -0700, Noah Misch wrote:
> On Thu, Mar 20, 2025 at 09:58:37PM -0400, Andres Freund wrote:
> > Not sure yet how to best disable testing io_uring in this case. We can't
> > just query EXEC_BACKEND from pg_config.h unfortunately. I guess making
> > the
> > initdb no
On 3/23/25 15:56, Sami Imseih wrote:
Hmm, queryId generation code lies in the core and we already came to
terms that this field has only a statistical purpose. Do you want to
commit planId generation code?
But, extensions don't necessarily need to rely on the core queryId. They
can generate the
On Sat, Mar 22, 2025 at 5:04 PM Andres Freund wrote:
>
> The problem is that sometimes recheck is performed for pending empty
> tuples. The comment about empty tuples says:
>
> /*
> * Bitmap is exhausted. Time to emit empty tuples if relevant. We emit
> * all empty tuples
On Wed, Mar 19, 2025 at 04:00:49PM +0800, Xuneng Zhou wrote:
> Hi,
> Moving the other two provides a more complete view of the settings. For
> newcomers(like me) to the codebase, seeing all three related values in one
> place helps avoid a narrow view of the settings.
>
> But I am not sure that I
On 3/23/25 01:01, Michael Paquier wrote:
On Sat, Mar 22, 2025 at 11:50:06PM +0100, Andrei Lepikhov wrote:
planId actually looks less controversial than queryId or plan_node_id. At
the same time, it is not free from the different logic that extensions may
incorporate into this value: I can imagin
On 3/23/25 04:22, Sami Imseih wrote:
On Sat, Mar 22, 2025 at 11:50:06PM +0100, Andrei Lepikhov wrote:
planId actually looks less controversial than queryId or plan_node_id. At
the same time, it is not free from the different logic that extensions may
incorporate into this value: I can imagine, f
Hi,
On 2025-03-19 18:11:18 -0700, Noah Misch wrote:
> On Wed, Mar 19, 2025 at 06:17:37PM -0400, Andres Freund wrote:
> > On 2025-03-19 14:25:30 -0700, Noah Misch wrote:
> > Hm, we retry more frequently that that if there are new connections...
> > Maybe
> > just "try again next time"?
>
> Work
čt 20. 3. 2025 v 22:30 odesílatel Pavel Stehule
napsal:
> Hi
>
> út 18. 3. 2025 v 21:33 odesílatel Álvaro Herrera
> napsal:
>
>> On 2025-Mar-18, Pavel Stehule wrote:
>>
>> > Maybe I found a bug
>> >
>> > (2025-03-18 19:28:06) postgres=# create table foo(a int constraint gzero
>> > check(a > 10)
On Sat, Mar 22, 2025 at 7:16 AM Melanie Plageman
wrote:
>
> On Thu, Mar 20, 2025 at 4:36 AM Masahiko Sawada wrote:
> >
> > When testing the multi passes of table vacuuming, I found an issue.
> > With the current patch, both leader and parallel workers process stop
> > the phase 1 as soon as the s
On Thu, Mar 20, 2025 at 3:47 PM David G. Johnston
wrote:
> While trying to find postgres.bki in my build directory searching for the
> file name didn't work because there is no comment in the file containing the
> file name; like there is in every other file we write or generate, including
> th
On Sun, Mar 23, 2025 at 04:30:04PM +0100, Andrei Lepikhov wrote:
> So, it may be not an issue in a cloud provider predefined installations, but
> a headache for custom configurations.
Sure, I mean, but it's not really related to the issue discussed on
this thread, so..
It sounds like we could imp
Hi Bilal,
I have a couple of comments, I have only reviewed 0001 so far.
>
Thank you for reviewing!
>
> You may need to run pgindent, it makes some changes.
>
Attached v4-patch has been updated after running pgindent.
+ * If table is shared, calculate the offset at which to find the
On Sat, Mar 22, 2025 at 1:12 AM Robert Haas wrote:
> However, I'm a bit concerned about the overall premise of the patch
> set. It feels like it is moving something that really ought to happen
> at optimization time back to parse time. I have a feeling that's going
> to break something, although I
On Wed, Mar 19, 2025 at 6:25 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Wed, 19 Mar 2025 17:49:49 -0700,
> "David G. Johnston" wrote:
>
> >> And could someone help (take over if possible) writing a
> >> document for
hi.
you may like the attached. it's based on your idea: attnotnullvalid.
I came across a case, not sure if it's a bug.
CREATE TABLE ttchk (a INTEGER);
ALTER TABLE ttchk ADD CONSTRAINT cc check (a is NOT NULL) NOT VALID;
CREATE TABLE ttchk_child(a INTEGER) INHERITS(ttchk);
ttchk_child's constraint
vignesh C writes:
> On Wed, 19 Mar 2025 at 18:12, David Rowley wrote:
>> While VACUUM ONLY on a partitioned table has no effect, the same isn't
>> true for inheritance parents. 62ddf7ee9 did change the behaviour of
>> VACUUM for these so that vacuuming the inheritance parent now vacuums
>> all of
commit 247ce06b wrote:
> + pgaio_io_reopen(ioh);
> +
> + /*
> + * To be able to exercise the reopen-fails path, allow
> injection
> + * points to trigger a failure at this point.
> + */
> +
On Mon, Mar 24, 2025 at 5:59 AM Andres Freund wrote:
> On 2025-03-23 08:55:29 -0700, Noah Misch wrote:
> > An IO in PGAIO_HS_STAGED clearly blocks closing the IO's FD, and an IO in
> > PGAIO_HS_COMPLETED_IO clearly doesn't block that close. For
> > io_method=worker,
> > closing in PGAIO_HS_SUBMI
On Mon, 24 Mar 2025 at 15:23, Michael Paquier wrote:
> And here we get 18564.06 (head) vs 16667.92 (patch) so a 10.7%
> difference in this run. Hence the automatic addition of NULL to the
> jumbling is disappointing here, even if this is what I'd see this as a
> worst case scenario, unlikely what
On Fri, 21 Mar 2025 at 22:02, Andrei Lepikhov wrote:
> In cases
> I have seen before, the main question is how effective was (or maybe) a
> Memoize node == how often the incoming key fits the cache. In that case,
> the hit ratio fraction is more understandable for a broad audience.
> That's why ac
On Mon, Mar 24, 2025 at 07:42:21PM +1300, David Rowley wrote:
> Can you share which patch you tested here? There are many patches on
> this thread and I don't want to make assumptions about which one these
> are the results for.
The patch tested is the latest one that has been posted on this
thre
David Rowley 于2025年3月24日周一 05:28写道：
> Over in [1], there was some uncertainty about whether locking an
> unrelated partition was expected behaviour or not for the particular
> use-case which used a generic plan to scan a partitioned table and all
> of the partitions.
>
> I noticed that we don't m
On Mon, 17 Mar 2025 at 09:26, vignesh C wrote:
>
Here's a quick commitfest status report as of today:
status | start | 10th | 17th | 24th
+-+-+-+-
Needs review: | 198 | 182 | 134 | 12
Thank you, Robert and Tom, for sharing your valuable insights, and
apologies for the slight delay in my response. From the discussion,
what I understand is that we aim to extend the current DROP ROLE
syntax to include the CASCADE/RESTRICT option, which has been
introduced in the latest SQL standard
On Tue, 18 Mar 2025 at 03:14, Aleksander Alekseev
wrote:
> Here is the corrected patch.
I had a look at this and it all seems good to me.
Pushed.
David
On Sat, Mar 22, 2025 at 1:25 AM Tom Lane wrote:
>
> Robert Haas writes:
> > I'm happy to have you tidy up here in whatever way seems best to you.
>
> Cool, done.
>
Thanks for taking care of this, and sorry for not digging deeper to
find the appropriate fix.
--
With Regards,
Amit Kapila.
Dear Shubham,
> I have reviewed and merged the proposed changes into the patch. The
> attached patches contain the suggested changes.
Thanks for updating the patch! Few comments:
01.
```
+ /*
+* Fetch all databases from the source (publisher) if --all is
specified.
+*/
+
hi.
https://git.postgresql.org/cgit/postgresql.git/commit/?id=11bd8318602fc2282a6201f714c15461dc2009c6
+ Adding a column with a volatile DEFAULT
+ (e.g., clock_timestamp()), a generated column
+ (e.g., GENERATED BY DEFAULT AS IDENTITY), a domain
+ data type with constraints will require the entir
Thank you for addressing those comments.
On Mon, 24 Mar 2025 at 12:24, Yuya Watari wrote:
> It is true that currently, indexes for EquivalenceMembers do not store
> information about base rels. However, the subsequent commit (v35-0004)
> introduces indexes for base rels to enable faster RestrictI
Dear Bertrand,
> > SIGSTOP signal for pg_recvlogical may do the idea,
>
> Yeah, but would we be "really" testing an "active" slot?
Yeah, this is also a debatable point.
> At the end we want to produce an invalidation that may or not happen on a real
> environment. The corner case is in the test
On Sun, Mar 23, 2025 at 11:11:53AM -0400, Andres Freund wrote:
> On 2025-03-22 17:20:56 -0700, Noah Misch wrote:
> > On Thu, Mar 20, 2025 at 09:58:37PM -0400, Andres Freund wrote:
> > > Not sure yet how to best disable testing io_uring in this case. We can't
> > > just query EXEC_BACKEND from p
On Mon, Mar 24, 2025 at 09:50:36AM +0900, Richard Guo wrote:
> Nice catch. The fix looks good to me. It seems to me that it's fine
> to go without a test case, since the fix is quite straightforward.
One could argue about using an injection point to force trick the
iteration loop to be cheaper,
On Sun, Mar 23, 2025 at 10:41 PM Kevin K Biju wrote:
> int i;
> ...
> for (i = 2; i <= iterations; i++)
> {
> ...
> }
>
> For iterations = INT_MAX, the loop will never terminate since the condition
> is <= and adding 1 to INT_MAX will lead to i wrapping around to INT_MIN.
>
> I've fixed this
On Mon, Mar 24, 2025 at 9:54 AM Michael Paquier wrote:
> On Mon, Mar 24, 2025 at 09:50:36AM +0900, Richard Guo wrote:
> > Nice catch. The fix looks good to me. It seems to me that it's fine
> > to go without a test case, since the fix is quite straightforward.
>
> One could argue about using an
Hi, Alexander!
On Tue, Mar 18, 2025 at 6:04 PM Alexander Pyhalov
wrote:
> This shouldn't. When semi-join is found below left/right join, it's
> deparsed as subquery.
> Interesting enough, this mechanics (deparsing as subquery) is used
> 1) for semi-joins under left/right join,
> 2) for full outer
Looks good, the code is more readable now.
> For both Neon and SVE, I do see improvements with looping over 4
> registers at a time, so IMHO it's worth doing so even if it performs the
> same as 2-register blocks on some hardware.
There was no regression on Graviton 3 when using the 4-register
On Sat, Mar 22, 2025 at 10:22:37PM -0500, Sami Imseih wrote:
> I think plan_node_id is probably the least controversial because that value
> comes straight from core, and different extensions cannot have their own
> interpretation of what that value could be.
Depends. An extension can plug in wha
44 matches
Mail list logo
