On Wed, Aug 21, 2024 at 03:18:49PM +0200, Tomas Vondra wrote:
> +1 to just close it
Sounds good to me. Thanks.
--
Michael
signature.asc
Description: PGP signature
On Thu, 22 Aug 2024 11:38:49 +0800
jian he wrote:
> On Wed, Aug 21, 2024 at 4:57 PM Peter Eisentraut wrote:
> >
>
> + /*
> + * Cannot specify USING when altering type of a generated column, because
> + * that would violate the generation expression.
> + */
> + if (attTup->attgenerated && def->c
On 15.08.24 08:38, Peter Eisentraut wrote:
On 08.08.24 19:42, Robert Haas wrote:
I'm thinking pg_upgrade could have a mode where it adds the
checksum during the upgrade as it copies the files (essentially a subset
of pg_checksums). I think that would be useful for that middle tier of
users who
On Mon, Aug 19, 2024 at 8:00 AM jian he wrote:
>
> On Mon, Apr 1, 2024 at 8:00 PM jian he wrote:
> >
> rebased.
> minor cosmetic error message change.
>
> I think all the issues in this thread have been addressed.
hi.
I did some minor changes based on the v11.
mainly changing some error code fr
On Mon, Aug 19, 2024 at 12:40 PM Peter Smith wrote:
>
> Hi Shubham, here are my review comments for the TAP tests patch v27-0002
>
> ==
> Commit message
>
> Tap tests for 'include-generated-columns'
>
> ~
>
> But, it's more than that-- these are the TAP tests for all
> combinations of replicat
On Mon, Aug 19, 2024 at 11:01 AM Peter Smith wrote:
>
> Hi, Here are my review comments for v27-0001.
>
> ==
> contrib/test_decoding/expected/generated_columns.out
> contrib/test_decoding/sql/generated_columns.sql
>
> +-- By default, 'include-generated-columns' is enabled, so the values
> for
On Fri, Aug 16, 2024 at 2:47 PM vignesh C wrote:
>
> On Fri, 16 Aug 2024 at 10:04, Shubham Khanna
> wrote:
> >
> > On Thu, Aug 8, 2024 at 12:43 PM Peter Smith wrote:
> > >
> > > Hi Shubham,
> > >
> > > I think the v25-0001 patch only half-fixes the problems reported in my
> > > v24-0001 review.
I have had hard times understanding what RIR rules are while reading
some threads in pgsql-hackers. One example is 'Virtual generated
columns'. I was trying to grep 'RIR rules', when I just started to
read kernel sources. And I only today I finally bumped into this note
in rewriteHandler.c
```
* N
On Thu, 22 Aug 2024 at 07:48, jian he wrote:
>
> On Wed, Aug 21, 2024 at 6:37 AM Alena Rybakina
> wrote:
> >
> > We check it there: "tabentry->vacuum_ext.type != type". Or were you talking
> > about something else?
> >
> > On 19.08.2024 12:32, jian he wrote:
> >
> > in pg_stats_vacuum
> > if
On Thu, Aug 22, 2024 at 11:02 jian he wrote:
> On Tue, Jul 30, 2024 at 12:59 PM Amit Langote
> wrote:
> >
> > Hi,
> >
> > On Fri, Jul 26, 2024 at 11:19 PM jian he
> wrote:
> > > On Fri, Jul 26, 2024 at 4:53 PM Amit Langote
> wrote:
> > > >
> > > >
> > > > Pushed 0003-0005 ahead of 0001-0002.
On Wed, Aug 21, 2024 at 4:57 PM Peter Eisentraut wrote:
>
+ /*
+ * Cannot specify USING when altering type of a generated column, because
+ * that would violate the generation expression.
+ */
+ if (attTup->attgenerated && def->cooked_default)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_TABLE_DEF
On Wed, Aug 21, 2024 at 3:04 PM Zhijie Hou (Fujitsu)
wrote:
>
>
> Attach the V20 patch set which addressed above, Shveta[1][2] and
> Kuroda-san's[3]
> comments.
>
Thank You for the patch. Few comments:
1)
+ The key section includes the key values of the local tuple that
violated a unique constr
On Thu, Aug 22, 2024 at 8:54 AM Peter Smith wrote:
>
> On Wed, Aug 21, 2024 at 8:48 PM Amit Kapila wrote:
> >
> > On Fri, Aug 16, 2024 at 9:45 AM vignesh C wrote:
> > >
> > > On Thu, 15 Aug 2024 at 12:55, Peter Smith wrote:
> > > >
> > > > Hi Hackers,
> > > >
> > > > While reviewing another log
Alvaro Herrera 于2024年8月22日周四 06:00写道：
> On 2024-Aug-19, Alvaro Herrera wrote:
>
> > I haven't pushed it yet, mostly because of being unsure about not doing
> > anything for the oldest branches (14 and back).
>
> Last night, after much mulling on this, it occurred to me that one easy
> way out of
HI Hous-San,. Here is my review of the v20-0001 docs patch.
1. Restructure into sections
> I think that's a good idea. But I preferred to do that in a separate
> patch(maybe a third patch after the first and second are RFC), because AFAICS
> we would need to adjust some existing docs which falls
Richard Guo 于2024年8月22日周四 10:53写道：
> On Wed, Aug 21, 2024 at 6:25 PM Tender Wang wrote:
> >Oversight in 7ff9afbbd; I think we can do the same way for the
> ATExecAddColumn().
>
> LGTM. Pushed.
>
Thanks for pushing.
--
Tender Wang
On Wed, Aug 21, 2024 at 6:25 PM Tender Wang wrote:
>Oversight in 7ff9afbbd; I think we can do the same way for the
> ATExecAddColumn().
LGTM. Pushed.
Thanks
Richard
On Wed, Aug 21, 2024 at 6:37 AM Alena Rybakina
wrote:
>
> We check it there: "tabentry->vacuum_ext.type != type". Or were you talking
> about something else?
>
> On 19.08.2024 12:32, jian he wrote:
>
> in pg_stats_vacuum
> if (type == PGSTAT_EXTVAC_INDEX || type == PGSTAT_EXTVAC_HEAP)
> {
On Thu, 22 Aug 2024 at 13:38, Michael Harris wrote:
> Would we want to apply that change to VACUUM too? That might be a
> bit drastic, especially if you had a multi-level inheritance structure
> featuring
> large tables.
I think they'd need to work the same way as for "VACUUM (ANALYZE)", it
woul
On Tue, Jul 30, 2024 at 12:59 PM Amit Langote wrote:
>
> Hi,
>
> On Fri, Jul 26, 2024 at 11:19 PM jian he wrote:
> > On Fri, Jul 26, 2024 at 4:53 PM Amit Langote
> > wrote:
> > >
> > >
> > > Pushed 0003-0005 ahead of 0001-0002. Will try to push them over the
> > > weekend. Rebased for now.
>
On Mon, Aug 19, 2024 at 03:21:30PM +0900, Michael Paquier wrote:
> I won't hide that I've wanted that in the past..
And I have bumped into a case where this has been helpful today, so
applied. Thanks!
--
Michael
signature.asc
Description: PGP signature
Tom Lane wrote:
> Yeah, my thought was to change the behavior so it's consistent in
> that case too. This doesn't seem to me like a change that'd
> really cause anybody serious problems: ANALYZE without ONLY would
> do more than before, but it's work you probably want done anyway.
Would we want
Hello,
Sometimes user want to measure the server's IO performance during some
troubleshooting *without* the access to postgresql server. Is there any
good way to measure it in such sistuation?
Measuring it with SELECT .. FROM t WHERE xxx, both shared_buffer in PG
and file system buffer bothers.
David Rowley writes:
> I feel like we might need to either bite the bullet and make ONLY work
> consistently with both, or think of another way to have ANALYZE not
> recursively gather stats for each partition on partitioned tables.
> Could we possibly get away with changing inheritance parent beh
On Thu, 22 Aug 2024 at 11:32, Michael Harris wrote:
> One other thing I noticed when reading the code. The function
> expand_vacuum_rel in vacuum.c seems to be responsible for adding the
> partitions. If I am reading it correctly, it only adds child tables in
> the case of a partitioned table, not
On Wed, Aug 21, 2024 at 10:48:38AM -0400, Joe Conway wrote:
> On 8/21/24 09:01, Peter Eisentraut wrote:
>> Is anything -- other than this inquiry -- preventing this patch set from
>> getting committed?
>
> The overwhelming consensus seemed to be "just do it", so FWIW consider my
> reservations wit
On Wed, Aug 21, 2024 at 01:55:06PM -0400, Alvaro Herrera wrote:
> I find it's strange that the information that stats cannot be used with
> injection points that have dependency on critical sections (?), is only
> in the commit message and not in the code.
A comment close to where inj_stats_enable
Thank you all for the replies & discussion.
It sounds like more are in favour of using the ONLY syntax attached to
the tables is the best way to go, with the main advantages being:
- consistency with other commands
- flexibility in allowing to specify whether to include partitions
for individual
On Thu, 22 Aug 2024 at 08:00, Gabriele Bartolini
wrote:
>
> Hi everyone,
>
> Apologies for only starting to look into this now. Thanks, David, for pushing
> this forward.
100%. I've wanted this for some time but never had time to cook up a patch.
> I want to emphasize the importance of this p
On Wed, Aug 21, 2024 at 8:48 PM Amit Kapila wrote:
>
> On Fri, Aug 16, 2024 at 9:45 AM vignesh C wrote:
> >
> > On Thu, 15 Aug 2024 at 12:55, Peter Smith wrote:
> > >
> > > Hi Hackers,
> > >
> > > While reviewing another logical replication thread [1], I found an
> > > ERROR scenario that seems
On 2024-Aug-19, Alvaro Herrera wrote:
> I haven't pushed it yet, mostly because of being unsure about not doing
> anything for the oldest branches (14 and back).
Last night, after much mulling on this, it occurred to me that one easy
way out of this problem for the old branches, without having to
Mark Dilger writes:
>> On Aug 21, 2024, at 12:34 PM, Kirill Reshke wrote:
>> Hi! Why is the patch attached as .tar.bz2? Usually raw patches are sent
>> here...
> I worried the patch set, being greater than 1 MB, might bounce or be held up
> in moderation.
I'm +1 for doing it like this with su
On Tue, Jun 25, 2024 at 12:12:33PM +0200, Alvaro Herrera wrote:
> archive_command and so on: we could disable these too. Nathan did some
> work to implement those using dynamic libraries, so it shouldn't be too
> much of a loss; anything that is done with a shell script can also be
> done with a s
On Wed, Jun 19, 2024 at 10:58:02AM -0500, Nathan Bossart wrote:
> On Wed, Jun 19, 2024 at 05:34:52PM +0200, Peter Eisentraut wrote:
>> I'm not really sure all this here is worth solving. I think requiring
>> things like --single or --boot to be first seems ok, and the alternatives
>> just make thi
On 2024-08-21 We 4:09 PM, Mark Dilger wrote:
On Aug 21, 2024, at 12:34 PM, Kirill Reshke wrote:
Hi! Why is the patch attached as .tar.bz2? Usually raw patches are sent here...
I worried the patch set, being greater than 1 MB, might bounce or be held up in
moderation.
Yes, it would have
> On Aug 21, 2024, at 12:34 PM, Kirill Reshke wrote:
>
> Hi! Why is the patch attached as .tar.bz2? Usually raw patches are sent
> here...
I worried the patch set, being greater than 1 MB, might bounce or be held up in
moderation.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The
Hi everyone,
Apologies for only starting to look into this now. Thanks, David, for
pushing this forward.
I want to emphasize the importance of this patch for the broader adoption
of extensions in immutable container environments, such as those used by
the CloudNativePG operator in Kubernetes.
To
On Aug 21, 2024 19:17, Robert Haas wrote:On Wed, Aug 21, 2024 at 12:31 PM Tomas Vondra wrote:
> Anyway, I took a look and the basic idea is simple - when shuffling
> tuples between batches in a hash join, we're currently deforming the
> tuple (->slot) we just read from a batch, only to immedia
On Thu, 22 Aug 2024 at 00:25, Mark Dilger wrote:
>
> Hackers,
>
> The index access method API mostly encapsulates the functionality of in-core
> index types, with some lingering oversights and layering violations. There
> has been an ongoing discussion for several release cycles concerning how
If there are no remaining concerns, I'd like to move forward with
committing v9 in September's commitfest.
--
nathan
On Tue, Aug 20, 2024 at 3:17 PM Jelte Fennema-Nio wrote:
>
> On Tue, 20 Aug 2024 at 23:48, Jacob Champion
> wrote:
> > That guarantee (if adopted) would also make it possible for my use
> > case to proceed correctly, since a libpq client can still speak 3.0
> > packets on the socket safely.
>
> N
On 2024-Aug-21, Michael Paquier wrote:
> From fd8ab7b6845a2c56aa2c8d9c60f404f6b3407338 Mon Sep 17 00:00:00 2001
> From: Michael Paquier
> Date: Wed, 21 Aug 2024 15:16:06 +0900
> Subject: [PATCH 2/3] injection_point: Add injection_points.stats
> This GUC controls if statistics should be used or n
On Wed, Aug 21, 2024 at 12:31 PM Tomas Vondra wrote:
> Anyway, I took a look and the basic idea is simple - when shuffling
> tuples between batches in a hash join, we're currently deforming the
> tuple (->slot) we just read from a batch, only to immediately form it
> (slot->) again and write it to
On 19.08.24 16:10, Aleksander Alekseev wrote:
To clarify, supporting bytea<->integer (and/or bytea<->numeric) casts
doesn't strike me as a terrible idea but it doesn't address the issue
I'm proposing to solve.
What is the issue you are proposing to solve?
You linked to a couple of threads and
Hi,
On 8/21/24 03:49, bucoo wrote:
> Avoid unnecessary form and deform tuple.
>
Thanks for the patch. Generally speaking, it's usually a good idea to
briefly explain what the patch does, why is that beneficial, in what
circumstances, etc. It's sometimes not quite obvious from the patch
itself (e
On 8/8/24 13:48, Jelte Fennema-Nio wrote:
> SUMMARY OF THREAD
>
> The design of patch 0001 is agreed upon by everyone on the thread (so
> far). This adds the PARTIAL_AGGREGATE label for aggregates, which will
> cause the finalfunc not to run. It also starts using PARTIAL_AGGREGATE
> for pushdow
On Wed, Aug 21, 2024 at 10:00:00AM +0300, Alexander Lakhin wrote:
> I'd like to add some info to show how big the iceberg is.
Hm. It seems pretty clear that removing -fwrapv won't be happening anytime
soon. I don't mind trying to fix a handful of cases from time to time, but
unless there's a liv
Hi, Pavel!
On Wed, Aug 21, 2024 at 4:28 PM Pavel Borisov wrote:
> I've looked at patch v8.
>
> 1.
> In function check_insert_rel_type_cache() the block:
>
> +#ifdef USE_ASSERT_CHECKING
> +
> + /*
> +* In assert-enabled builds otherwise check for RelIdToTypeIdCacheHash
> +*
Hi,
On Tue, Aug 20, 2024 at 02:25:19PM -0500, Sami Imseih wrote:
> > As it looks like we have a consensus that reducing the number of interrupts
> > also
> > makes sense, I just provided a rebase version of the 1 Hz version (see [0],
> > that
> > also makes clear in the doc that the new field m
On Sun, Aug 4, 2024 at 11:58 PM David Steele wrote:
> I'm still in favor but if nobody else is interested then I'm not going
> to push on it.
OK, so since this email was sent, Amul reviewed the patch (thanks,
Amul!) but didn't take a position on whether it was a good idea.
Nobody else has respond
On 8/20/24 20:41, Bruce Momjian wrote:
> On Tue, Aug 20, 2024 at 07:03:56PM +0200, Jelte Fennema-Nio wrote:
>> On Tue, 20 Aug 2024 at 18:50, Bruce Momjian wrote:
>>> Okay, so we can do MAX easily, and AVG if the count can be represented
>>> as the same data type as the sum? Is that correct? O
On 8/21/24 09:01, Peter Eisentraut wrote:
On 07.08.24 15:49, Daniel Gustafsson wrote:
On 5 Aug 2024, at 15:36, Joe Conway wrote:
It would not shock me to see complaints from others after we rip out support
for 1.0.2, but maybe not ¯\_(ツ)_/¯
I think it's highly likely that we will see comp
On Wed, Aug 21, 2024 at 4:08 PM Andrei Lepikhov
wrote:
> On 21/8/2024 02:17, Alexander Korotkov wrote:
> > Also, I convert the check you've introduced in the previous message to
> > op_in_opfamily(), and introduced collation check similar to
> > match_opclause_to_indexcol().
> Hi,
> I passed throu
Heikki Linnakangas writes:
> Yeah, I've been slowly upgrading it to a new debian/raspbian version,
> and "ccache" started segfaulting, not sure why. I compiled ccache from
> sources, and now it seems to work when I run it on its own. Not sure why
> the buildfarm run still failed.
Maybe nuking
On Fri, Aug 2, 2024 at 12:53 PM Robert Haas wrote:
> On Fri, Aug 2, 2024 at 12:51 PM Tom Lane wrote:
> > That absolutely is the expectation, and we'd better be careful not
> > to break it.
>
> I have every intention of not breaking it. :-)
I went ahead and committed these patches. I know there's
On 17.05.24 00:54, Thomas Munro wrote:
On Fri, May 17, 2024 at 3:17 AM Nazir Bilal Yavuz wrote:
Actually, 32 bit builds are working but the Perl version needs to be
updated to 'perl5.36-i386-linux-gnu' in .cirrus.tasks.yml. I changed
0001 with the working version of 32 bit builds [1] and the re
Hi
The JSON_OBJECT is by default formatting as text, adding explicit format
type to JSON_OBJECT will solve the problem.
For example
postgres=# SELECT json_object('configd' value item format json) FROM
JSON_TABLE('{"empno":1001}', '$' COLUMNS (item text FORMAT JSON PATH '$'));
json_obje
On 21.08.24 11:28, Thomas Munro wrote:
On Wed, Aug 21, 2024 at 9:04 PM Peter Eisentraut wrote:
REL_15_STABLE is fixed now. REL_16_STABLE now fails with another thing:
...
line 6: meson: command not found
Huh. I don't see that in my own account. And postgres/postgres is
currently out of j
Hi, Alexander!
On Tue, 20 Aug 2024 at 23:01, Alexander Korotkov
wrote:
> On Mon, Aug 5, 2024 at 4:16 AM Alexander Korotkov
> wrote:
> > I've revised the patchset. First of all, I've re-ordered the patches.
> >
> > 0001-0002 (former 0002-0003)
> > Comprises hash_search_with_hash_value() functio
On 19.05.24 00:46, Ole Peder Brandtzæg wrote:
On Wed, May 15, 2024 at 07:20:09AM +0200, Peter Eisentraut wrote:
Yes, let's get that v3-0001 patch into PG17.
Upon seeing this get committed in 4dd29b6833, I noticed that the docs
still advertise the llvm-config-$version search dance. That's still
On 8/21/24 14:58, Robert Haas wrote:
> ...
>
> All we're doing here is taking an incremental backup of 1-table
> database that had 1 row at the time of the full backup and has had 1
> more row inserted since then. On my system, the last time I ran this
> regression test, this step completed in 410m
On Wed, Aug 21, 2024 at 8:45 AM Amit Langote wrote:
> * The replanning aspect of the lock-in-the-executor design would be
> simpler if a CachedPlan contained the plan for a single query rather
> than a list of queries, as previously mentioned. This is particularly
> due to the requirements of the
On 21/8/2024 02:17, Alexander Korotkov wrote:
Also, I convert the check you've introduced in the previous message to
op_in_opfamily(), and introduced collation check similar to
match_opclause_to_indexcol().
Hi,
I passed through the patches with fresh sight. Conceptually, this
approach looks muc
On 07.08.24 15:49, Daniel Gustafsson wrote:
On 5 Aug 2024, at 15:36, Joe Conway wrote:
It would not shock me to see complaints from others after we rip out support
for 1.0.2, but maybe not ¯\_(ツ)_/¯
I think it's highly likely that we will see complaints for any support we
deprecate. OpenS
On Tue, Aug 6, 2024 at 1:49 AM Michael Paquier wrote:
> dikkop has reported a failure with the regression tests of pg_combinebackup:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dikkop&dt=2024-08-04%2010%3A04%3A51
>
> That's in the test 003_timeline.pl, from dc212340058b:
> # Failed
On Sun, Apr 14, 2024 at 3:16 PM Thomas Munro wrote:
> So I'll go ahead and add the storage class to the next version, and
> contemplate a couple of different options for the tss stuff, including
> perhaps leaving it out if that seems doable.
Here is a new attempt at pg_threads.h. Still work in p
On Tue, Aug 20, 2024 at 11:53 PM Robert Haas wrote:
> On Tue, Aug 20, 2024 at 9:00 AM Amit Langote wrote:
> > I think we'd modify plancache.c to postpone the locking of only
> > prunable relations (i.e., partitions), so we're looking at only a
> > handful of concurrent modifications that are goin
On Wed, Aug 21, 2024 at 3:06 PM Pavel Borisov wrote:
> On Wed, 21 Aug 2024 at 15:55, Alexander Korotkov wrote:
>>
>> Hi, Pavel!
>>
>> On Wed, Aug 21, 2024 at 1:48 PM Pavel Borisov wrote:
>> > On Mon, 19 Aug 2024 at 02:24, Alexander Korotkov
>> > wrote:
>> >>
>> >> On Sat, Aug 10, 2024 at 6:57
Hi, Alexander!
On Wed, 21 Aug 2024 at 15:55, Alexander Korotkov
wrote:
> Hi, Pavel!
>
> On Wed, Aug 21, 2024 at 1:48 PM Pavel Borisov
> wrote:
> > On Mon, 19 Aug 2024 at 02:24, Alexander Korotkov
> wrote:
> >>
> >> On Sat, Aug 10, 2024 at 6:57 PM Dmitry Koval
> wrote:
> >> > > Probably
> >> >
Hi, Pavel!
On Wed, Aug 21, 2024 at 1:48 PM Pavel Borisov wrote:
> On Mon, 19 Aug 2024 at 02:24, Alexander Korotkov wrote:
>>
>> On Sat, Aug 10, 2024 at 6:57 PM Dmitry Koval wrote:
>> > > Probably
>> > > QueryCompletion struct fits this purpose best from the existing
>> > > parameters. Attached
st 21. 8. 2024 v 12:20 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> In many jit related bug reports, one of the first questions is often
> "which llvm version is used". How about adding it into the
> PG_VERSION_STR, similar to the gcc version?
>
+1
Pave
On Tue, Aug 20, 2024 at 3:56 PM Amul Sul wrote:
>
> On Sat, Aug 17, 2024 at 1:34 AM Robert Haas wrote:
> >
> > On Fri, Aug 16, 2024 at 3:53 PM Robert Haas wrote:
[...]
> > There's probably more to look at here but I'm running out of energy for
> > today.
> >
>
> Thank you for the review and com
On Wed, 21 Aug 2024 at 08:00, Peter Eisentraut wrote:
>
> On 08.08.24 20:22, Dean Rasheed wrote:
> > Looking at the rewriter changes, it occurred to me that it could
> > perhaps be done more simply using ReplaceVarsFromTargetList() for each
> > RTE with virtual generated columns. That function alr
Hi, Alexander!
On Mon, 19 Aug 2024 at 02:24, Alexander Korotkov
wrote:
> On Sat, Aug 10, 2024 at 6:57 PM Dmitry Koval
> wrote:
> > > Probably
> > > QueryCompletion struct fits this purpose best from the existing
> > > parameters. Attached draft patch implements returning oid of newly
> > > cre
On Fri, Aug 16, 2024 at 9:45 AM vignesh C wrote:
>
> On Thu, 15 Aug 2024 at 12:55, Peter Smith wrote:
> >
> > Hi Hackers,
> >
> > While reviewing another logical replication thread [1], I found an
> > ERROR scenario that seems to be untested.
> >
> > TEST CASE: Attempt CREATE SUBSCRIPTION where t
On Wed, Aug 21, 2024 at 8:35 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Wednesday, August 21, 2024 9:33 AM Jonathan S. Katz
> wrote:
> > On 8/6/24 4:15 AM, Zhijie Hou (Fujitsu) wrote:
> >
> > > Thanks for the idea! I thought about few styles based on the suggested
> > > format, what do you think abou
Hi,
Oversight in 7ff9afbbd; I think we can do the same way for the
ATExecAddColumn().
--
Tender Wang
v1-0001-Small-code-simplification.patch
Description: Binary data
In many jit related bug reports, one of the first questions is often
"which llvm version is used". How about adding it into the
PG_VERSION_STR, similar to the gcc version?
>From 9a4404c0df92f96ab98fca3ff0d7952287c30ece Mon Sep 17 00:00:00 2001
From: Dmitrii Dolgov <9erthali...@gmail.com>
Date: Tue,
David Rowley , 21 Ağu 2024 Çar, 01:53 tarihinde şunu
yazdı:
> On Wed, 21 Aug 2024 at 06:41, Robert Haas wrote:
> > I like trying to use ONLY somehow.
>
> Do you mean as an ANALYZE command option, i.e. ANALYZE (only) table;
> or as a table modifier like gram.y's extended_relation_expr?
>
> Making
Hello hackers,
As a recent failure, produced by drongo [1], shows, pg_ctl stop/start
sequence may break on Windows due to the transient DELETE PENDING state of
posmaster.pid.
Please look at the excerpt from the failure log:
...
pg_createsubscriber: stopping the subscriber
2024-08-19 18:02:47.608
On Tue, Aug 20, 2024 at 2:01 PM shveta malik wrote:
>
> On Tue, Aug 20, 2024 at 11:36 AM Amit Kapila wrote:
> >
> > On Wed, Aug 14, 2024 at 10:26 AM shveta malik
> > wrote:
> > >
> > > >
> > > > Thanks for the detailed analysis. I agree with your analysis that we
> > > > need to reset the origi
On Wednesday, August 21, 2024 2:45 PM Peter Smith wrote:
>
> Here are some review comments for the v19-0001 docs patch.
>
> The content seemed reasonable, but IMO it should be presented quite
> differently.
>
>
>
> 1. Use sub-sections
>
> I expect this logical replication "Conflicts" sec
On Wednesday, August 21, 2024 1:31 PM Kuroda, Hayato/黒田 隼人
wrote:
>
> Dear Hou,
>
> Thanks for updating the patch! I think the patch is mostly good.
> Here are minor comments.
Thanks for the comments !
>
> 02.
> ```
> +
> + The key section in the second sentence of the
> ...
> ```
On Wednesday, August 21, 2024 11:40 AM shveta malik
wrote:
>
> On Tue, Aug 20, 2024 at 4:45 PM Zhijie Hou (Fujitsu)
> wrote:>
Thanks for the comments!
> 4)
> Shall we give an example LOG message in the end?
I feel the current insert_exists log in conflict section seems
sufficient as an exam
On Wed, Aug 21, 2024 at 9:04 PM Peter Eisentraut wrote:
> REL_15_STABLE is fixed now. REL_16_STABLE now fails with another thing:
...
> line 6: meson: command not found
Huh. I don't see that in my own account. And postgres/postgres is
currently out of juice until the end of the month (I know w
On Fri, Aug 16, 2024 at 6:39 PM Dean Rasheed wrote:
>
in Var comments:
* varlevelsup is greater than zero in Vars that represent outer references.
* Note that it affects the meaning of all of varno, varnullingrels, and
* varnosyn, all of which refer to the range table of that query level.
Do
On 19.08.24 01:44, Thomas Munro wrote:
On Mon, Aug 19, 2024 at 10:55 AM Tom Lane wrote:
Thomas Munro writes:
I still don't know what's happening. In case it helps someone else
see it, the error comes from "sudo port unsetrequested installed".
But in any case, switching to 2.10.1 seems to do
On Wed, Aug 21, 2024 at 12:40 PM Heikki Linnakangas wrote:
>
> On 21/08/2024 09:25, Amit Kapila wrote:
> >>
> >> I think this patch makes sense. I'm not sure we've actually made any
> >> promises on it, but it feels wrong that the slot's LSN might be advanced
> >> past the LSN that's been has been
On 21.08.24 09:14, Yugo Nagata wrote:
On Wed, 21 Aug 2024 08:17:45 +0200
Peter Eisentraut wrote:
A USING clause when altering the type of a generated column does not
make sense. It would write the output of the USING clause into the
converted column, which would violate the generation expres
On Wed, Aug 21, 2024 at 12:00 AM Jelte Fennema-Nio wrote:
> @Anthonin are you planning to update the patch accordingly?
Here's the patch with \bindx renamed to \bind_named.
I've also made a small change to Michael's refactoring in 0002 by
initialising success to false in ExecQueryAndProcessResul
On Wed, 21 Aug 2024 08:17:45 +0200
Peter Eisentraut wrote:
> A USING clause when altering the type of a generated column does not
> make sense. It would write the output of the USING clause into the
> converted column, which would violate the generation expression.
>
> This patch adds a chec
On 21/08/2024 09:25, Amit Kapila wrote:
On Wed, Aug 21, 2024 at 2:25 AM Heikki Linnakangas wrote:
On 14/08/2024 16:54, Arseny Sher wrote:
On 8/13/24 06:35, Amit Kapila wrote:
On Mon, Aug 12, 2024 at 3:43 PM Arseny Sher wrote:
Sorry for the poor formatting of the message above, this should
On 08.08.24 20:22, Dean Rasheed wrote:
Looking at the rewriter changes, it occurred to me that it could
perhaps be done more simply using ReplaceVarsFromTargetList() for each
RTE with virtual generated columns. That function already has the
required wholerow handling code, so there'd be less code
Hello Nathan,
21.08.2024 00:21, Nathan Bossart wrote:
I've combined all the current proposed changes into one patch. I've also
introduced signed versions of the negation functions into int.h to avoid
relying on multiplication.
Thank you for taking care of this!
I'd like to add some info to
94 matches
Mail list logo
