Hi,
On Tue, May 13, 2025 at 3:48 PM shveta malik wrote:
>
>
> With the given script, the problem reproduces on Head and PG17. We are
> trying to reproduce the issue on PG16 and below where injection points
> are not there.
>
The issue can also be reproduced on PostgreSQL versions 13 through 16.
Hi,
I noticed this recent BF failure:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=leafhopper&dt=2025-05-15%2008%3A10%3A04
=== dumping
/home/bf/proj/bf/build-farm-17/HEAD/pgsql.build/src/test/recovery/tmp_check/regression.diffs
===
diff -U3
/home/bf/proj/bf/build-farm-17/HEAD/pgsql.
Hello, while compiling my c extension with PG 17,2 I am getting
postgresql-17.2/pgsql/include/server/port/pg_iovec.h:93:10: error: call to
undeclared function 'pwritev'; ISO C99 and later do not support implicit
function declarations [-Wimplicit-function-declaration]
93 | retur
On Fri, 16 May 2025 at 09:12, Daniel Gustafsson wrote:
> As was briefly discussed in the developers meeting, and the hallway track,
> at
> PGConf.dev we have a few variations on the organization wording which
> really
> should be aligned with the wording defined by -core in pgweb commit
> 2d764db
On Fri, May 16, 2025 at 12:12 PM Tom Lane wrote:
> That outcome seems entirely horrible to me. If you want to flag the lack
> of a commit message somehow, fine, but don't prevent CI from running.
Personally I also prefer nudges to gates. Just like people already
deprioritize "Waiting on Author"
On Fri, May 16, 2025 at 9:11 PM Fujii Masao
wrote:
> Hi,
>
> When multiple subscribers connect to different publisher servers,
> it can be useful to set different wal_receiver_timeout values for
> each connection to better detect failures. However, this isn't
> currently possible, which limits fl
Gentle ping on this.
---
Hari Krishna Sunder
On Wed, May 14, 2025 at 1:30 PM Hari Krishna Sunder
wrote:
> Thanks Nathan.
> Here is the patch with a comment.
>
> On Wed, May 14, 2025 at 8:53 AM Nathan Bossart
> wrote:
>
>> On Tue, May 13, 2025 at 05:01:02PM -0700, Hari Krishna Sunder wrote:
>>
I wrote:
> We lack that #define, which results in not supplying
> the declaration. AFAICT the requirement for this is in the C11
> standard, this is not just Apple doing something weird.
> Aside from this compilation error, we're probably failing to use
> memset_s on some platforms where it's ava
On 16/05/2025 15:01, Tom Lane wrote:
Aleksander Alekseev writes:
If I'm right about the limitations of aggregate functions and SRFs
this leaves us the following options:
1. Changing the constraints of aggregate functions or SRFs. However I
don't think we want to do it for such a single niche
Vik Fearing writes:
> On 16/05/2025 15:01, Tom Lane wrote:
>> Seems to me the obvious answer is to extend TABLESAMPLE (or at least, some
>> of the tablesample methods) to allow it to work on a subquery.
> Isn't this a job for ?
> FETCH SAMPLE FIRST 10 ROWS ONLY
How is that an improvement on TABL
On 16/05/2025 23:21, Tom Lane wrote:
Vik Fearing writes:
On 16/05/2025 15:01, Tom Lane wrote:
Seems to me the obvious answer is to extend TABLESAMPLE (or at least, some
of the tablesample methods) to allow it to work on a subquery.
Isn't this a job for ?
FETCH SAMPLE FIRST 10 ROWS ONLY
How
On Fri, May 16, 2025 at 09:01:50AM -0400, Tom Lane wrote:
> Seems to me the obvious answer is to extend TABLESAMPLE (or at least, some
> of the tablesample methods) to allow it to work on a subquery.
The key here is that we need one bit of state between rows: the count of
rows seen so far.
On Fri, May 16, 2025 at 11:10:49PM +0200, Vik Fearing wrote:
> Isn't this a job for ?
>
> Example:
>
> SELECT ...
> FROM ... JOIN ...
> FETCH SAMPLE FIRST 10 ROWS ONLY
>
> Then the nodeLimit could do some sort of reservoir sampling.
The query might return fewer than N rows. What reservoir samp
Here are a couple new isolation tests for foreign keys, based on
feedback from the Advanced Patch Review session at PGConf.dev.
The goal is to show that temporal foreign keys do not violate
referential integrity under concurrency. Non-temporal foreign keys use
a crosscheck snapshot to avoid this.
On Thu, May 15, 2025 at 02:41:15AM +0300, Aleksander Alekseev wrote:
> SELECT t.ts, t.city, t.temperature, h.humidity
> FROM temperature AS t
> LEFT JOIN LATERAL
> ( SELECT * FROM humidity
> WHERE city = t.city AND ts <= t.ts
> ORDER BY ts DESC LIMIT 1
> ) AS h ON TRUE
> WHERE t.ts < '2
It's my understanding that right now when you run pg_upgrade it creates the
extension from what exists in the to be upgraded databases.
Is there a reason why we can't have some sort of switch option that allows
the CREATE EXTENSION from the scripts instead of what is loaded in the db.
The reason
On Fri, 16 May 2025 at 12:24, Jacob Champion
wrote:
>
> On Fri, May 16, 2025 at 12:12 PM Tom Lane wrote:
> > That outcome seems entirely horrible to me. If you want to flag the lack
> > of a commit message somehow, fine, but don't prevent CI from running.
>
> Personally I also prefer nudges to g
Jelte Fennema-Nio writes:
> Okay, reasonable feedback. How about we add a CI job that does a
> "quality check". That's much less strong, as all the other tests will
> still run, but people would get a failing CI job which tells them that
> something is wrong. We could also include a pgindent in th
Hi Ilia Evdokimov,
While it's true that no arithmetic or logical operations are performed on
queryid after the assignment, the overflow technically occurs at the point of
assignment itself. For example, entry->key.queryid holds the value
12747288675711951805 as a uint64, but after assigning it
On Fri, 16 May 2025 at 12:05, Daniel Gustafsson wrote:
>
> > On 16 May 2025, at 11:52, Jelte Fennema-Nio wrote:
>
> > Does anyone have strong opposition to this? To be clear, it means we don't
> > run CI on patches created by piping "git diff" to a file anymore, as a way
> > to nudge submitter
On Fri, May 16, 2025 at 12:01 PM shveta malik wrote:
>
> On Fri, May 16, 2025 at 11:15 AM Amit Kapila wrote:
> >
> >
> > BTW, another related point is that when we decide to stop retaining
> > dead tuples (via should_stop_conflict_info_retention), should we also
> > consider the case that the app
On 15.05.2025 10:08, Shaik Mohammad Mujeeb wrote:
Hi Developers,
In pg_stat_statements.c, the function /pg_stat_statements_internal()/
declares the /queryid/ variable as *int64*, but assigns it a value of
type *uint64*. At first glance, this might appear to be an overflow
issue. However, I t
Hello,
When I trying to compiling postgres 17.2 with -std=c11 I am getting the
below error on mac
explicit_bzero.c:22:9: error: call to undeclared function 'memset_s'; ISO
C99 and later do not support implicit function declarations
[-Wimplicit-function-declaration]
22 | (void) memset_
Dave Page writes:
> On Fri, 16 May 2025 at 09:12, Daniel Gustafsson wrote:
>> As was briefly discussed in the developers meeting, and the hallway track,
>> at
>> PGConf.dev we have a few variations on the organization wording which
>> really
>> should be aligned with the wording defined by -core
Aleksander Alekseev writes:
> If I'm right about the limitations of aggregate functions and SRFs
> this leaves us the following options:
> 1. Changing the constraints of aggregate functions or SRFs. However I
> don't think we want to do it for such a single niche scenario.
> 2. Custom syntax and
As was briefly discussed in the developers meeting, and the hallway track, at
PGConf.dev we have a few variations on the organization wording which really
should be aligned with the wording defined by -core in pgweb commit 2d764dbc08.
--
Daniel Gustafsson
v1-0001-Align-organization-wording-in-c
Hi,
The pgoutput plugin options are documented in the logical streaming
replication protocol, but their default values are not mentioned.
This can be inconvenient for users - for example, when using pg_recvlogical
with pgoutput plugin and needing to know the default behavior of each option.
https
Hi Shaik
> While it's true that no arithmetic or logical operations are performed on
queryid after the assignment, the overflow technically > occurs at the
point of assignment itself. For example, *entry->key.queryid* holds the
value *12747288675711951805* as a
> *uint64*, but after assigning it to
Hi,
> A custom SRF seems great to me. You may propose such an aggregate in the
> core - it seems it doesn't even need any syntax changes. For example:
> SELECT * FROM (SELECT sample(q, 10, ) FROM (SELECT ...) AS q);
> or something like that.
I experimented with this idea a bit and it looks like t
On 2025/05/16 15:33, Dilip Kumar wrote:
On Fri, May 16, 2025 at 11:51 AM Masahiro Ikeda
wrote:
Thank you for your comments!
I updated the patch to use RELKIND_HAS_STORAGE() as done in
commit 4623d7144. Please see the v2-0001 patch for the changes.
Thanks for updating the patch!
You adde
On Thu, May 15, 2025 at 6:02 PM Amit Kapila wrote:
>
> Few minor comments on 0001:
> 1.
> + if (TimestampDifferenceExceeds(data->reply_time,
> +data->candidate_xid_time, 0))
> + ereport(ERROR,
> + errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
> + errmsg("oldest_nonremovable_xid transactio
Hi,
When multiple subscribers connect to different publisher servers,
it can be useful to set different wal_receiver_timeout values for
each connection to better detect failures. However, this isn't
currently possible, which limits flexibility in managing subscriptions.
To address this, I'd like
> On 16 May 2025, at 10:40, Daniel Gustafsson wrote:
> I will go ahead and push this to all supported branches.
Done. I also ensured that the text in the legal notice match the OSI license
text while in there.
--
Daniel Gustafsson
In the "Scaling PostgreSQL Development" unconference session. One of the
problems that came up was that people don't follow "best practices". The
response to that was that people don't know what the best practices are
(nor that they are important to follow), because we don't enforce them.
Based on
Lakshmi Narayana Velayudam writes:
> When I trying to compiling postgres 17.2 with -std=c11 I am getting the
> below error on mac
> explicit_bzero.c:22:9: error: call to undeclared function 'memset_s'; ISO
> C99 and later do not support implicit function declarations
> [-Wimplicit-function-declar
On Fri, 16 May 2025 at 11:50, Daniel Gustafsson wrote:
> > On 16 May 2025, at 10:40, Daniel Gustafsson wrote:
>
> > I will go ahead and push this to all supported branches.
>
> Done. I also ensured that the text in the legal notice match the OSI
> license
> text while in there.
>
Great, thank
> On 16 May 2025, at 11:52, Jelte Fennema-Nio wrote:
> Does anyone have strong opposition to this? To be clear, it means we don't
> run CI on patches created by piping "git diff" to a file anymore, as a way
> to nudge submitters into providing useful commit messages.
Disclaimer: I wasn't in t
Lakshmi Narayana Velayudam writes:
> Hello, while compiling my c extension with PG 17,2 I am getting
> postgresql-17.2/pgsql/include/server/port/pg_iovec.h:93:10: error: call to
> undeclared function 'pwritev'; ISO C99 and later do not support implicit
> function declarations [-Wimplicit-function-
is there different tables "Seq Scan on tenk1 t2" and "Seq Scan on tenk1
t1", so it might not be a bug, isn't it?
On 16.05.2025 09:19, Andres Freund wrote:
Hi,
I noticed this recent BF failure:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=leafhopper&dt=2025-05-15%2008%3A10%3A04
===
Jelte Fennema-Nio writes:
> Based on the discussion there I'm planning to make the cfbot fail to apply
> a patch in the following two cases:
> ...
> To be clear, it means we don't
> run CI on patches created by piping "git diff" to a file anymore, as a way
> to nudge submitters into providing use
On Fri, May 16, 2025 at 12:17 PM Amit Kapila wrote:
>
> On Fri, Apr 25, 2025 at 10:08 AM shveta malik wrote:
> >
> > On Thu, Apr 24, 2025 at 6:11 PM Zhijie Hou (Fujitsu)
> > wrote:
> >
> > > > Few comments for patch004:
> > > > Config.sgml:
> > > > 1)
> > > > +
> > > > +Maximum du
On Fri, May 16, 2025 at 2:40 PM Amit Kapila wrote:
>
> On Fri, May 16, 2025 at 12:01 PM shveta malik wrote:
> >
> > On Fri, May 16, 2025 at 11:15 AM Amit Kapila
> > wrote:
> > >
> > >
> > > BTW, another related point is that when we decide to stop retaining
> > > dead tuples (via should_stop_co
> On 16 May 2025, at 10:00, Tom Lane wrote:
>
> Dave Page writes:
>> On Fri, 16 May 2025 at 09:12, Daniel Gustafsson wrote:
>>> As was briefly discussed in the developers meeting, and the hallway track,
>>> at
>>> PGConf.dev we have a few variations on the organization wording which
>>> really
On Fri, May 16, 2025 at 1:00 PM Alexander Lakhin wrote:
> I've discovered yet another way to trigger that error:
> create table vt (a int, b int generated always as (a * 2), c int);
> insert into vt values(1);
> alter table vt alter column c type bigint using b + c;
>
> ERROR: XX000: unexpected v
Hey,
I noticed a couple of small clarity issues in the current version of patch
for potential clean up:
1. Commit message wording
Right now it says:
“The pg_buffercache_mark_dirty_all() function provides an efficient way to
dirty the entire buffer pool (e.g., ~550 ms vs. ~70 ms for 16 GB of sha
On Fri, May 16, 2025 at 3:26 PM Richard Guo wrote:
>
> On Fri, May 16, 2025 at 1:00 PM Alexander Lakhin wrote:
> > I've discovered yet another way to trigger that error:
> > create table vt (a int, b int generated always as (a * 2), c int);
> > insert into vt values(1);
> > alter table vt alter c
46 matches
Mail list logo
