On Tue, May 28, 2024 at 5:29 PM Markus Winand wrote:
>
> Hi!
>
> I’ve noticed two “surprising” (to me) behaviors related to
> the “ON ERROR” clause of the new JSON query functions in 17beta1.
>
> 1. JSON parsing errors are not subject to ON ERROR
>Apparently, the functions expect JSONB so that
Hi,
Here are some review comments for patch v5-0002.
==
GENERAL
G1.
IIUC now you are unconditionally allowing all generated columns to be copied.
I think this is assuming that the table sync code (in the next patch
0003?) is going to explicitly name all the columns it wants to copy
(so if i
Hi,
At Fri, 24 May 2024 08:43:01 -0700, Jacob Champion
wrote in
> On Tue, Apr 30, 2024 at 2:29 PM Jacob Champion
> wrote:
> > Attached is a draft patch to illustrate what I mean, but it's
> > incomplete: it only solves the problem for scalar values.
>
> (Attached is a v2 of that patch; in sol
On Mon, May 27, 2024 at 11:19 AM shveta malik wrote:
>
> On Sat, May 25, 2024 at 2:39 AM Tomas Vondra
> wrote:
> >
> > >
> > > Conflict Resolution
> > >
> > > a) latest_timestamp_wins:The change with later commit timestamp wins.
> > > b) earliest_timestamp_wins: The change
Hi,
On 2023-08-29 15:18:29 +0300, Nazir Bilal Yavuz wrote:
> The VS and MinGW Windows images are merged on Andres' pg-vm-images
> repository now [1]. So, the old pg-ci-windows-ci-vs-2019 and
> pg-ci-windows-ci-mingw64 images will not be updated from now on. This
> new merged image (pg-ci-windows-c
Hi,
Here are some review comments for patch v5-0001.
==
GENERAL G.1
The patch changes HEAD behaviour for PUBLICATION col-lists right? e.g.
maybe before they were always ignored, but now they are not?
OTOH, when 'include_generated_columns' is false then the PUBLICATION
col-list will ignore a
[ redirecting to pgsql-hackers ]
I wrote:
> I agree that this looks like a bug, since your example shows that the
> same function works as-expected in an ordinary expression but not in
> a CALL. The dependency on AUTOCOMMIT (that is, being within an outer
> transaction block) seems even odder. I
On Mon, 2024-06-03 at 15:38 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2024-06-03 14:43:17 -0400, David E. Wheeler wrote:
> > > * The ABI is guaranteed to change only in backward compatible ways in
> > > minor
> > > releases. If for some reason it doesn’t it’s a bug that will need to b
On Tue, May 28, 2024 at 04:49:45PM -0700, Jelte Fennema-Nio wrote:
> Two notes after looking at this quickly during the advanced patch
> feedback session:
>
> 1. I would maybe split 0003 into two separate patches. One to make SET
> UNLOGGED fast, which seems quite easy to do because no WAL is need
On Mon, Jan 15, 2024 at 01:34:46PM -0500, Robert Haas wrote:
> This kind of change looks massively helpful to me. I don't know if it
> is exactly right or not, but it would have been a big help to me when
> writing my previous review, so +1 for some change of this general
> type.
During a live rev
Hi,
On 2024-06-03 14:28:13 -0500, Nathan Bossart wrote:
> On Mon, Jun 03, 2024 at 12:08:52PM -0700, Andres Freund wrote:
> > Why do we think that increasing the number of PGPROC slots, heavyweight
> > locks
> > etc by 256 isn't going to cause issues? That's not an insubstantial amount
> > of
>
On Fri, Apr 26, 2024 at 06:38:22PM +0530, Ashutosh Bapat wrote:
> Some points for discussion:
> 1. The test still hardcodes the diffs between two dumps. Haven't found a
> better way to do it. I did consider removing the problematic objects from
> the regression database but thought against it since
Thanks for the testing!
On 01/06/2024 11:00, Alexander Lakhin wrote:
Hello Heikki,
I've stumbled upon yet another anomaly introduced with b8bff07da.
Please try the following script:
SELECT 'init' FROM pg_create_logical_replication_slot('slot',
'test_decoding');
CREATE TABLE tbl(t text);
BE
On Mon, Jun 3, 2024 at 6:55 PM Pavel Borisov wrote:
> On Sun, 2 Jun 2024 at 17:18, Alexander Korotkov wrote:
>>
>> Hi!
>>
>> On Sun, Jun 2, 2024 at 10:55 AM jian he wrote:
>> >
>> > On Fri, May 31, 2024 at 8:12 AM Alexander Korotkov
>> > wrote:
>> > >
>> > > I've revised some grammar including
On Mon, Jun 03, 2024 at 03:24:07PM -0700, Andres Freund wrote:
> I'm confused - isn't using common/int.h entirely sufficient for that? Nearly
> all architectures have more efficient ways to check for 64bit overflows than
> doing actual 128 bit math.
Oh, right. We could just plug in pg_add_u32_ove
Hi,
On 2024-06-04 07:17:51 +0900, Michael Paquier wrote:
> On Sun, May 26, 2024 at 12:08:46AM -0400, Tom Lane wrote:
> > After a few minutes' thought, how about:
> >
> > Assert((uint64) blocknum + (uint64) nblocks <= (uint64) mdnblocks(reln,
> > forknum));
> >
> > This'd stop being helpful
On Sun, May 26, 2024 at 12:08:46AM -0400, Tom Lane wrote:
> After a few minutes' thought, how about:
>
> Assert((uint64) blocknum + (uint64) nblocks <= (uint64) mdnblocks(reln,
> forknum));
>
> This'd stop being helpful if we ever widen BlockNumber to 64 bits,
> but I think that's unlikely
On Jun 3, 2024, at 5:56 PM, Andres Freund wrote:
> I don't see how this would trigger random crashes.
>
> Unfortunately [4] doesn't seem to take me to a relevant message (pruned chat
> history?), so I can't infer more from that context.
You can use [4] to join the Slack (if you haven’t already)
Hi,
On 2024-06-03 15:21:04 -0400, David E. Wheeler wrote:
> > Extensions in general can do lots of stuff, guaranteeing that bug fixes
> > don't
> > cause any problems is just not feasible.
> >
> > It'd be interesting to see a few examples of actual minor-version-upgrade
> > extension breakages, s
On Mon, Jun 3, 2024 at 5:27 PM Masahiko Sawada wrote:
> I've attached the patch to revive num_dead_tuples column back to the
> pg_stat_progress_vacuum view. This requires to bump catalog version.
> We're post-beta1 but it should be okay as it's only for PG17.
>
> Feedback is very welcome.
Can we
On 2024-06-03 18:57 +0200, Tom Lane wrote:
> Erik Wienhold writes:
> > On 2024-06-03 00:15 +0200, Tom Lane wrote:
> >> The new bit of information that this bug report provides is that it's
> >> possible to get a TCL_ERROR result without Tcl having set errorInfo.
> >> That seems a tad odd, and it m
Hi
> You can see, the RDBMS allows different types of session variables,
> different implementations. Usually one system allows more implementation of
> session variables. There is a possibility of emulation implementation
> between RDBMS, but security setting is possible only in Oracle or DB2.
>
Hi,
Commit 667e65aac3 changed num_dead_tuples and max_dead_tuples columns
to dead_tuple_bytes and max_dead_tuple_bytes columns, respectively.
But at PGConf.dev, I got feedback from multiple people that
num_dead_tuples information still can provide meaning insights for
users to understand the vacuu
ne 2. 6. 2024 v 23:31 odesílatel Peter Eisentraut
napsal:
>
> On 25.05.24 12:50, Pavel Stehule wrote:
> > It looks odd - It is not intuitive, it introduces new inconsistency
> > inside Postgres, or with solutions in other databases. No other database
> > has a similar rule, so users coming from Or
On Mon, Jun 3, 2024 at 9:10 AM Justin Pryzby wrote:
>
> On Thu, May 30, 2024 at 10:59:06AM -0700, David Christensen wrote:
> > Hi Justin,
> >
> > Thanks for the patch and the work on it. In reviewing the basic
> > feature, I think this is something that has utility and is worthwhile
> > at the hi
> > I don't think it's common for such new-fields-in-padding to cause problems
> > when using an earlier minor PG version. For that the extension would need to
> > actually rely on the presence of the new field, but typically that'd not be
> > the case when we introduce a new field in a minor versi
Andres Freund writes:
> On 2024-06-03 14:43:17 -0400, David E. Wheeler wrote:
>> * The ABI is guaranteed to change only in backward compatible ways in minor
>> releases. If for some reason it doesn’t it’s a bug that will need to be
>> fixed.
> Thus I am not really on board with this statement as-
On Mon, Jun 03, 2024 at 12:08:52PM -0700, Andres Freund wrote:
> I don't have time to read through the entire thread right now - it'd be good
> for the commit message of a patch like this to include justification for why
> it's ok to make such a change. Even before actually committing it, so
> revi
On Jun 3, 2024, at 14:58, Andres Freund wrote:
> Hi,
Hello Andres.
> Are there notes for the session?
Yes, but not posted yet. Here’s what Andreas 'ads' Scherbaum sent me for that
bit of the conversation:
* Core is focused on core ABI stability
* David: No "statement of stability" in Cor
Hi,
On 2024-06-03 13:52:29 -0500, Nathan Bossart wrote:
> Here is an updated patch that uses 256 as the upper limit.
I don't have time to read through the entire thread right now - it'd be good
for the commit message of a patch like this to include justification for why
it's ok to make such a cha
On Mon, Jun 03, 2024 at 12:18:21PM -0500, Nathan Bossart wrote:
> On Tue, May 21, 2024 at 11:15:14PM +, Imseih (AWS), Sami wrote:
>> As far as backpatching the present inconsistencies in the docs,
>> [0] looks good to me.
>
> Committed.
Of course, as soon as I committed this, I noticed anothe
Hi,
On 2024-06-03 14:43:17 -0400, David E. Wheeler wrote:
> At the PGConf Unconference session on improving extension support in core,
> we talked quite a bit about the recent anxiety among extension developers
> about a lack of an ABI compatibility guarantee in Postgres.
Are there notes for the
On Thu, May 16, 2024 at 09:16:46PM -0500, Nathan Bossart wrote:
> On Thu, May 16, 2024 at 04:37:10PM +, Imseih (AWS), Sami wrote:
>> I thought 256 was a good enough limit. In practice, I doubt anyone will
>> benefit from more than a few dozen autovacuum workers.
>> I think 1024 is way too hig
Hackers,
At the PGConf Unconference session on improving extension support in core, we
talked quite a bit about the recent anxiety among extension developers about a
lack of an ABI compatibility guarantee in Postgres. Yurii Rashkovskii did a
little header file spelunking and talked[1] about a f
Hi,
On 2024-06-03 17:07:22 +0200, Wolfgang Walther wrote:
> Peter Eisentraut:
> > It's probably worth clarifying that this option is needed on macOS only
> > if LTO is also enabled. For standard (non-LTO) builds, the
> > export-dynamic behavior is already the default on macOS (otherwise
> > nothi
On Wed, May 29, 2024 at 12:37:21PM +, Maiquel Grassi wrote:
> Is there someone willing to help me with this development and guide the
> patch so that it can be committed one day?
>From a quick skim of the latest messages in this thread, it sounds like
there are a couple of folks who think \con
On Mon, Jun 03, 2024 at 07:36:51PM +0200, Hannu Krosing wrote:
> For at least last two years we have had Developers Conference
> Unconference notes in PostgreSQL Wiki
>
> https://wiki.postgresql.org/wiki/PgCon_2022_Developer_Unconference
> https://wiki.postgresql.org/wiki/PgCon_2023_Developer_Unco
Hello Everybody!
For at least last two years we have had Developers Conference
Unconference notes in PostgreSQL Wiki
https://wiki.postgresql.org/wiki/PgCon_2022_Developer_Unconference
https://wiki.postgresql.org/wiki/PgCon_2023_Developer_Unconference
And I know that people took notes at least at
Peter Eisentraut writes:
> On 02.06.24 21:46, Tom Lane wrote:
>> If you don't
>> like our current behavior, then either you have to say that RETURNING
>> with a length-limited target type is illegal (which is problematic
>> for the spec, since they have no such type) or that the cast behaves
>> li
On Tue, May 21, 2024 at 11:15:14PM +, Imseih (AWS), Sami wrote:
>> Any concerns with doing something like this [0] for the back-branches? The
>> constant would be 6 instead of 7 on v14 through v16.
>
> As far as backpatching the present inconsistencies in the docs,
> [0] looks good to me.
Com
Wolfgang Walther:
Peter:
I don't think we explicitly offer LTO builds as part of the make build
system, so anyone trying this would do it sort of self-service, by
passing additional options to configure or make. In which case they
might as well pass the -export_dynamic option along in the sam
Erik Wienhold writes:
> On 2024-06-03 00:15 +0200, Tom Lane wrote:
>> The new bit of information that this bug report provides is that it's
>> possible to get a TCL_ERROR result without Tcl having set errorInfo.
>> That seems a tad odd, and it must happen only in weird corner cases,
>> else we'd h
On Sun Jun 2, 2024 at 12:25 AM CDT, Tom Lane wrote:
"Tristan Partin" writes:
> On Fri May 31, 2024 at 12:02 PM CDT, Ashutosh Bapat wrote:
>> We talked this off-list at the conference. It seems we have to somehow
>> avoid passing pg_regress --schedule argument and instead pass the list of
>> test
On 2024-06-03 00:15 +0200, Tom Lane wrote:
> The new bit of information that this bug report provides is that it's
> possible to get a TCL_ERROR result without Tcl having set errorInfo.
> That seems a tad odd, and it must happen only in weird corner cases,
> else we'd have heard of this decades ago
Hi, Alexander!
On Sun, 2 Jun 2024 at 17:18, Alexander Korotkov
wrote:
> Hi!
>
> On Sun, Jun 2, 2024 at 10:55 AM jian he
> wrote:
> >
> > On Fri, May 31, 2024 at 8:12 AM Alexander Korotkov
> wrote:
> > >
> > > I've revised some grammar including the sentence you've proposed.
> > >
> >
> > -stat
On Wed, May 29, 2024 at 06:49:57AM -0700, Peter Eisentraut wrote:
> On 25.05.24 04:01, Jelte Fennema-Nio wrote:
>> Is this the only reason why you're suggesting adding fsync=full,
>> instead of simply always setting F_FULLFSYNC when fsync=true on MacOS.
>> If so, I'm not sure we really gain anythin
hi
based on gram.y and function transformJsonValueExpr.
gram.y:
| JSON_QUERY '('
json_value_expr ',' a_expr json_passing_clause_opt
json_returning_clause_opt
json_wrapper_behavior
json_quotes_clause_opt
json_behavior_clause_opt
')'
| JSON_EXISTS '('
json_value_expr ',' a_expr json_passing_clause_
+Andres
On Thu, May 16, 2024 at 12:07:32PM +0200, Peter Eisentraut wrote:
> This patch version looks good to me.
At pgconf.dev, Andres opined that it would be better to put these files in
the top-level directory so that they would be more visible to non-GitHub
users. I personally don't have any
Peter Eisentraut:
It's probably worth clarifying that this option is needed on macOS only
if LTO is also enabled. For standard (non-LTO) builds, the
export-dynamic behavior is already the default on macOS (otherwise
nothing in PostgreSQL would work).
Right, man page say this:
> Preserves al
On Sun, Jun 02, 2024 at 03:17:21PM -0400, Neil Conway wrote:
> master @ 8fea1bd541:
>
> $ for i in ~/*.sql; do hyperfine --warmup 5 "./psql -f $i"; done
> Benchmark 1: ./psql -f /Users/neilconway/copy-out-bench-long-quotes.sql
> Time (mean ± σ): 2.027 s ± 0.075 s[User: 0.001 s, System:
po 3. 6. 2024 v 16:10 odesílatel Justin Pryzby
napsal:
> On Thu, May 30, 2024 at 10:59:06AM -0700, David Christensen wrote:
> > Hi Justin,
> >
> > Thanks for the patch and the work on it. In reviewing the basic
> > feature, I think this is something that has utility and is worthwhile
> > at the
On 03.06.24 16:22, Wolfgang Walther wrote:
Building with clang and -flto on macOS currently fails with errors
similar to [1]. This is because the --export-dynamic flag is called
-export_dynamic [2] instead and we have not been passing this variant to
the linker, so far.
It's probably worth cl
Building with clang and -flto on macOS currently fails with errors
similar to [1]. This is because the --export-dynamic flag is called
-export_dynamic [2] instead and we have not been passing this variant to
the linker, so far.
Attached patch fixes that for configure/make.
CC: Tom, who hit th
When testing my own patches or review other's patches, I want to know if
the new code has been tested, however our current 'make coverage-html'
shows all the codes rather than the 'new code', so is there a good way
to get the answer for the above question?
I searched lcov at [1] and the options
On Mon, Jun 3, 2024 at 9:22 AM Joe Conway wrote:
> Welcome back!
>
Thanks Joe! It's been a minute :)
Neil
On Thu, May 30, 2024 at 10:59:06AM -0700, David Christensen wrote:
> Hi Justin,
>
> Thanks for the patch and the work on it. In reviewing the basic
> feature, I think this is something that has utility and is worthwhile
> at the high level.
Thanks for looking.
> A few more specific notes:
>
>
On 6/2/24 15:17, Neil Conway wrote:
Inspired by David Rowley's work [1]
Welcome back!
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Tue, 21 May 2024 at 15:08, Ranier Vilela wrote:
>
> Em ter., 21 de mai. de 2024 às 05:18, Nazir Bilal Yavuz
> escreveu:
>>
>> Hi,
>>
>> On Thu, 16 May 2024 at 17:47, Robert Haas wrote:
>> >
>> > On Thu, May 16, 2024 at 9:43 AM Nazir Bilal Yavuz
>> > wrote:
>> > > Actually, the documen
>
> The attached Patch contains the suggested changes.
>
Hi,
Currently, COPY command does not work for generated columns and
therefore, COPY of generated column is not supported during tablesync
process. So, in patch v4-0001 we added a check to allow replication of
the generated column only if 'c
Hi Robert,
On Mon, May 27, 2024 at 09:10:13AM -0400, Robert Haas wrote:
> Hi Bertrand,
>
> It would be helpful to me if the reasons why we're splitting out
> relfilenodestats could be more clearly spelled out. I see Andres's
> comment in the thread to which you linked, but it's pretty vague about
On Mon, 3 Jun 2024 at 13:03, Shubham Khanna wrote:
>
> On Thu, May 16, 2024 at 11:35 AM Peter Smith wrote:
> >
> > Here are some review comments for the patch v1-0001.
> >
> > ==
> > GENERAL
> >
> > G.1. Use consistent names
> >
> > It seems to add unnecessary complications by having differen
On Fri, May 24, 2024 at 8:26 AM Peter Smith wrote:
>
> Hi,
>
> Here are some review comments for the patch v3-0001.
>
> I don't think v3 addressed any of my previous review comments for
> patches v1 and v2. [1][2]
>
> So the comments below are limited only to the new code (i.e. the v3
> versus v2
On Thu, May 23, 2024 at 5:56 PM vignesh C wrote:
>
> On Thu, 23 May 2024 at 09:19, Shubham Khanna
> wrote:
> >
> > > Dear Shubham,
> > >
> > > Thanks for creating a patch! Here are high-level comments.
> >
> > > 1.
> > > Please document the feature. If it is hard to describe, we should change
>
On Thu, May 23, 2024 at 10:56 AM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Shubham,
>
> Thanks for updating the patch! I checked your patches briefly. Here are my
> comments.
>
> 01. API
>
> Since the option for test_decoding is enabled by default, I think it should
> be renamed.
> E.g., "skip-gen
On Tue, May 21, 2024 at 12:23 PM Peter Smith wrote:
>
> Hi,
>
> AFAICT this v2-0001 patch differences from v1 is mostly about adding
> the new CREATE SUBSCRIPTION option. Specifically, I don't think it is
> addressing any of my previous review comments for patch v1. [1]. So
> these comments below
On 02.06.24 21:46, Tom Lane wrote:
If you don't
like our current behavior, then either you have to say that RETURNING
with a length-limited target type is illegal (which is problematic
for the spec, since they have no such type) or that the cast behaves
like an implicit cast, with errors for over
Hi,
Am Samstag, dem 18.05.2024 um 12:22 +0200 schrieb Tomas Vondra:
> > It was committed once [0], but then reverted, vardata opclasses
> > were
> > implemented wrong. Now it's on CF[1], Bernd is actively responding
> > in
> > the thread, but currently patch lacks tests.
> >
> > Thanks for raisin
On Thu, May 16, 2024 at 11:35 AM Peter Smith wrote:
>
> Here are some review comments for the patch v1-0001.
>
> ==
> GENERAL
>
> G.1. Use consistent names
>
> It seems to add unnecessary complications by having different names
> for all the new options, fields and API parameters.
>
> e.g. som
On Sat, May 25, 2024 at 2:39 AM Tomas Vondra
wrote:
>
> On 5/23/24 08:36, shveta malik wrote:
> >
> > Conflict Resolution
> >
> > a) latest_timestamp_wins:The change with later commit timestamp wins.
> > b) earliest_timestamp_wins: The change with earlier commit timestamp wi
Hi,
> VS should work, and if not, we should fix it. It's slow, so I'd not use it
> for scheduled builds, but for people developing using visual studio.
Since no one complained, should we assume that there are actually no
such people? If this is the case then VS arguably doesn't give any
value th
70 matches
Mail list logo
