On Wed, Oct 18, 2023 at 04:45:46PM -0400, Tom Lane wrote:
> > On Wed, Oct 18, 2023 at 12:02 PM Tom Lane wrote:
> >> Probably. Independent of that, it's fair to ask why we're still
> >> testing against xlc 12.1 and not the considerably-more-recent xlclang,
> >> or at least xlc 16.1. (I also
Hi,
On 2023-10-18 15:53:30 -0400, Stephen Frost wrote:
> > Here how pg_backend_memory_contexts would look like with this patch:
> >
> > postgres=# SELECT name, id, parent, parent_id, path
> > FROM pg_backend_memory_contexts
> > ORDER BY total_bytes DESC LIMIT 10;
> > name |
Andres Freund writes:
> It turns out that updating the in-tree typedefs.list would be very noisy. On
> my local linux system I get
> 1 file changed, 422 insertions(+), 1 deletion(-)
> On a mac mini I get
> 1 file changed, 351 insertions(+), 1 deletion(-)
That seems like it needs a considerably
Here are some review comments for v52-0001
==
src/bin/pg_upgrade/t/003_upgrade_logical_replication_slots.pl
1.
+ # 2. max_replication_slots is set to smaller than the number of slots (2)
+ # present on the old cluster
SUGGESTION
2. Set 'max_replication_slots' to be less than the number of
On 10/18/23 08:39, Robert Haas wrote:
On Tue, Oct 17, 2023 at 4:17 PM David Steele wrote:
Given that the above can't be back patched, I'm thinking we don't need
backup_label at all going forward. We just write the values we need for
recovery into pg_control and return *that* from
On Wednesday, October 18, 2023, David Steele wrote:
> On 10/18/23 08:39, Robert Haas wrote:
>
>> On Tue, Oct 17, 2023 at 4:17 PM David Steele wrote:
>>
>>> Given that the above can't be back patched, I'm thinking we don't need
>>> backup_label at all going forward. We just write the values we
On Wed, Oct 18, 2023 at 05:59:19PM +0200, Christoph Berg wrote:
> I'm not entirely sure this is the commit to blame, but it's certainly
> close:
That would be in this area, thanks for the report.
> A Debian user is complaining that in PG17, the installed
>
Hi,
On 2023-10-18 12:15:51 -0700, Andres Freund wrote:
> I still think that one of the more important things we ought to do is to make
> it trivial to check if code is correctly indented and reindent it for the
> user. I've posted a preliminary patch to add a 'indent-tree' target a few
> months
On 10/19/23 06:17, Peter Smith wrote:
In short, maybe the whole comment should just be
/*
* boolin - input function for type boolean
*/
How about "boolin - converts a boolean string value to 1 or 0"
Personally, I do not like exposing the implementation of a boolean (it
is a base
On Wed, Oct 18, 2023 at 8:23 PM Tomas Vondra
wrote:
>
> I did use that many values to actually force "compaction" and merging of
> points into ranges. We only keep 32 values per page range, so with 2
> values we'll not build a range. You're right it may still trigger the
> overflow (we probably
On Wednesday, October 18, 2023 5:26 PM Kuroda, Hayato/黒田 隼人
wrote:
>
> Thank you for reviewing! PSA new version.
> Note that 0001 and 0002 are combined into one patch.
Thanks for updating the patch, here are few comments for the test.
1.
>
# The TAP Cluster.pm assigns default
On Tue, Oct 17, 2023 at 11:21 AM wrote:
>
>
> thanks for the really good suggestion. Here is the newer version:
>
--- a/src/backend/optimizer/path/meson.build
+++ b/src/backend/optimizer/path/meson.build
@@ -10,4 +10,5 @@ backend_sources += files(
'joinrels.c',
'pathkeys.c',
Hi,
On 2023-10-18 19:18:13 -0700, Andres Freund wrote:
> On 2023-10-18 21:29:37 -0400, Tom Lane wrote:
> Ah, I see. If I interpret that correctly, the code filters out symbols it
> doesn't find in in some .[chly] file in the *source* directory. This code is,
> uh, barely readable and massively
On Thu, Oct 19, 2023 at 3:26 PM Vik Fearing wrote:
>
> On 10/19/23 06:17, Peter Smith wrote:
> >> In short, maybe the whole comment should just be
> >>
> >> /*
> >> * boolin - input function for type boolean
> >> */
> >>
> > How about "boolin - converts a boolean string value to 1 or 0"
On Tue, Oct 17, 2023 at 10:56 AM David E. Wheeler wrote:
>
>
> Oh, I thought it would report issues from the files they were found in.
> You’re right, I forgot a title. Fixed in v4.
>
> David
>
+Returns the result of a JSON path
+predicate
+check for the specified JSON
On Wed, Oct 18, 2023 at 02:56:42PM +0900, Michael Paquier wrote:
> Thanks for the new versions. I have applied 0001 and backpatched it
> for now. 0002 and 0003 look in much cleaner shape than previously.
0002 and 0003 have now been applied. I have split 0003 into two parts
at the end, mainly
On Wed, Oct 18, 2023 at 10:24:50AM -0400, Robert Haas wrote:
> I added a variant of this test case. Here's v10.
+-- Verify that an XLOG_CHECKPOINT_REDO record begins at precisely the redo LSN
+-- of the checkpoint we just performed.
+SELECT redo_lsn FROM pg_control_checkpoint() \gset
+SELECT
Hi,
On 2023-10-18 21:29:37 -0400, Tom Lane wrote:
> Andres Freund writes:
> > It turns out that updating the in-tree typedefs.list would be very noisy. On
> > my local linux system I get
> > 1 file changed, 422 insertions(+), 1 deletion(-)
> > On a mac mini I get
> > 1 file changed, 351
Hi.
I happened upon a function comment referring to non-existent code
(that code was moved to another location many years ago).
Probably better to move that comment too. Thoughts?
PSA.
==
Kind Regards,
Peter Smith.
Fujitsu Australia
v1-0001-Relocate-old-comment.patch
Description: Binary
On Thu, Oct 19, 2023 at 10:35 AM Peter Smith wrote:
> Hi.
>
> I happened upon a function comment referring to non-existent code
> (that code was moved to another location many years ago).
>
> Probably better to move that comment too. Thoughts?
Agreed. +1 to move that comment.
Thanks
Richard
On 19/10/2023 01:50, Alexander Korotkov wrote:
On Mon, Oct 16, 2023 at 11:28 AM Andrei Lepikhov
wrote:
On 12/10/2023 18:32, Alexander Korotkov wrote:
On Thu, Oct 5, 2023 at 12:17 PM Andrei Lepikhov
wrote:
On 4/10/2023 14:34, Alexander Korotkov wrote:
> Relid replacement machinery is the
On Mon, 16 Oct 2023 at 10:33, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Vignesh,
>
> Thank you for reviewing! PSA new version.
>
> >
> > Few comments:
> > 1) Most of the code in binary_upgrade_set_next_oid is similar to
> > SetNextObjectId, but SetNextObjectId has the error handling to report
> >
On 18/10/2023 16:59, Ashutosh Bapat wrote:
On Wed, Oct 18, 2023 at 10:55 AM Andrei Lepikhov
wrote:
But the clauses of A parameterized by P will produce different
translations for each of the partitions. I think we will need
different RelOptInfos (for A) to store these translations.
Does
On Thu, Oct 19, 2023 at 2:55 PM Tom Lane wrote:
>
> Richard Guo writes:
> > On Thu, Oct 19, 2023 at 10:35 AM Peter Smith wrote:
> >> I happened upon a function comment referring to non-existent code
> >> (that code was moved to another location many years ago).
> >>
> >> Probably better to move
On Tue, Oct 03, 2023 at 12:44:36PM -0400, Robert Haas wrote:
> My first thought was to wonder whether this was even a bug. I
> remembered that EXPLAIN treats shared, local, and temp buffers as
> three separate categories of things. But it seems that someone decided
> to conflate two of them for
On 19/10/2023 02:00, Stephen Frost wrote:
Greetings,
* Andrei Lepikhov (a.lepik...@postgrespro.ru) wrote:
On 29/9/2023 09:52, Andrei Lepikhov wrote:
On 22/5/2023 22:59, reid.thomp...@crunchydata.com wrote:
Attach patches updated to master.
Pulled from patch 2 back to patch 1 a change that
On Wed, 18 Oct 2023 at 14:55, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Peter,
>
> Thank you for reviewing! PSA new version.
> Note that 0001 and 0002 are combined into one patch.
>
> > Here are some review comments for v51-0001
> >
> > ==
> > src/bin/pg_upgrade/check.c
> >
> > 0.
> >
Richard Guo writes:
> On Thu, Oct 19, 2023 at 10:35 AM Peter Smith wrote:
>> I happened upon a function comment referring to non-existent code
>> (that code was moved to another location many years ago).
>>
>> Probably better to move that comment too. Thoughts?
> Agreed. +1 to move that
On Wed, Oct 18, 2023 at 07:27:45AM +, Zhijie Hou (Fujitsu) wrote:
> The test is to confirm the output file has been removed for pg_upgrade
> --check while
> the message here is not consistent. Attach a small patch to fix it.
Indeed, will fix. Thanks!
--
Michael
signature.asc
Description:
On 10/17/23 22:25, Tomas Vondra wrote:
> Hi,
>
> Here's a couple cleaned-up patches fixing the various discussed here.
> I've tried to always add a regression test demonstrating the issue
> first, and then fix it in the next patch.
>
> In particular, this deals with these issues:
>
> 1)
On 2023-10-16 18:46, Ashutosh Bapat wrote:
On Thu, Oct 12, 2023 at 6:51 PM torikoshia
wrote:
On 2023-10-11 16:22, Ashutosh Bapat wrote:
>
> Considering the similarity with auto_explain I wondered whether this
> function should be part of auto_explain contrib module itself? If we
> do that
On 10.10.23 10:03, Peter Eisentraut wrote:
On 09.10.23 11:20, Alvaro Herrera wrote:
I tried this out. I agree it's a good change. BTW, this made me
realize that "unlike" is not a good name: maybe it should be called
"except".
right
I would add quotes to the words "like" and "unlike"
On Thu, Oct 12, 2023 at 04:46:02PM -0700, Andres Freund wrote:
> The machine skink is hosted on runs numerous buildfarm animals (24 I think
> right now, about to be 28). While it has plenty resources (16 cores/32
> threads, 128GB RAM), test runtime is still pretty variable depending on what
>
On Wed, Oct 18, 2023 at 02:59:52AM +, Hayato Kuroda (Fujitsu) wrote:
> While discussing [1], I found that in tap tests, wal_level was set to logical
> for
> subscribers too. The setting is not needed for subscriber side, and it may
> cause
> misunderstanding for newcomers. Therefore, I
On 16.10.23 17:15, David Steele wrote:
I also do wonder with recovery_control is really a better name. Maybe
I just have backup_label too firmly stuck in my head, but is what that
file does really best described as recovery control? I'm not so sure
about that.
The thing it does that describes
On 18.10.23 06:40, David Rowley wrote:
I agree that it's not nice to add yet another way of breaking the
buildfarm and even more so when the committer did make check-world
before committing. We have --enable-tap-tests, we could have
--enable-indent-checks and have pgindent check the code is
Hi,
There is one hint message in 002_pg_upgrade.pl that is not consistent with the
testing purpose.
# --check command works here, cleans up pg_upgrade_output.d.
command_ok(
[
'pg_upgrade', '--no-sync', '-d', $oldnode->data_dir,
...
ok(!-d $newnode->data_dir .
On Tue, Oct 17, 2023 at 11:07 PM Tom Lane wrote:
>
> Magnus Hagander writes:
> > If it doesn't know how to rebuild it, aren't we going to be stuck in a
> > catch-22 if we need to change it in certain ways? Since an old version
> > of pg_bsd_indent would reject the patch that might include
Here are some comments for the patch v51-0002
==
src/bin/pg_upgrade/t/003_upgrade_logical_replication_slots.pl
1.
+# Set max_wal_senders to a lower value if the old cluster is prior to PG12.
+# Such clusters regard max_wal_senders as part of max_connections, but the
+# current TAP tester
On Fri, Oct 13, 2023 at 6:18 PM Andrei Lepikhov
wrote:
> On 23/8/2023 12:37, Richard Guo wrote:
> > To fix it we may need to modify RelOptInfos for Path, BitmapHeapPath,
> > ForeignPath and CustomPath, and modify IndexOptInfos for IndexPath. It
> > seems that that is not easily done without
On Wed, 18 Oct 2023 at 06:40, David Rowley wrote:
> How many of the committers who have broken koel are repeat offenders?
I just checked the commits and there don't seem to be real repeat
offenders. The maximum number of times someone broke koel since its
inception is two. That was the case for
Thanks for the patch.
I tested the v6 patch using the test script attached on [1], old primary
has succeeded to become new standby.
I have very minor questions on the regression tests mainly regarding the
consistency with other tests for pg_rewind:
+setup_cluster;
+create_standby;
On Tue, 17 Oct 2023 at 23:01, Magnus Hagander wrote:
> And unless we're only enforcing it on master, we'd also need to make
> provisions for different versions of it on different branches, I
> think?
Only enforcing on master sounds fine to me, that's what koel is doing
too afaik. In practice
Dear Peter,
Thank you for reviewing! New patch is available in [1].
> ==
> src/bin/pg_upgrade/t/003_upgrade_logical_replication_slots.pl
>
> 1.
> +# Set max_wal_senders to a lower value if the old cluster is prior to PG12.
> +# Such clusters regard max_wal_senders as part of
On Wed, Oct 18, 2023 at 10:55 AM Andrei Lepikhov
wrote:
>
> > But the clauses of A parameterized by P will produce different
> > translations for each of the partitions. I think we will need
> > different RelOptInfos (for A) to store these translations.
>
> Does the answer above resolved this
I pushed the first patch, for LLVM 16, and the build farm told me that
some old LLVM versions don't like it. The problem seems to be the
function LLVMGlobalGetValueType(). I can see that that was only added
to the C API in 2018, so it looks like I may need to back-port that
(trivial) wrapper
On Fri, Oct 6, 2023 at 7:47 PM Peter Eisentraut wrote:
>
> On 29.08.23 09:05, Jeevan Chalke wrote:
> > v1-0001-Implement-jsonpath-.bigint-.integer-and-.number-m.patch
> >
> > This commit implements jsonpath .bigint(), .integer(), and .number()
> > methods. The JSON string or a numeric value is
Note that this patch falsifies the comment in SetNextObjectId that
taking the lock is pro forma only -- it no longer is, since in upgrade
mode there can be multiple subprocesses running -- so I think it should
be updated.
--
Álvaro Herrera PostgreSQL Developer —
On 10/18/23 03:07, Peter Eisentraut wrote:
On 16.10.23 17:15, David Steele wrote:
I also do wonder with recovery_control is really a better name. Maybe
I just have backup_label too firmly stuck in my head, but is what that
file does really best described as recovery control? I'm not so sure
On 10/17/23 22:13, Kyotaro Horiguchi wrote:
At Tue, 17 Oct 2023 16:16:42 -0400, David Steele wrote in
Given that the above can't be back patched, I'm thinking we don't need
backup_label at all going forward. We just write the values we need
for recovery into pg_control and return *that* from
On 2023-Oct-18, Robert Haas wrote:
> Without FFI::Platypus, we have to write Perl code that can speak the
> wire protocol directly. Basically, we're writing our own PostgreSQL
> driver for Perl, though we might need only a subset of the things a
> real driver would need to handle, and we might
Tom Lane writes:
> Robert Haas writes:
>> On Sat, Sep 2, 2023 at 2:42 PM Andrew Dunstan wrote:
How much burden is it? Would anyone actually mind?
>
>> ... At the same time, fallbacks can be a problem too,
>> because then you can end up with things that work one way on one
>> developer's
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Tom Lane writes:
>> gfortran? Really?? I mean, I don't care about the disk space,
>> but this is not promising for anyone who has to build it themselves.
> The Fortran support for FFI::Platypus is in a separate CPAN distribution
>
Robert Haas writes:
> On Wed, Oct 18, 2023 at 10:28 AM Tom Lane wrote:
>> I did a bit of research on this on my favorite platforms, and did
>> not like the results:
> Hmm. That's unfortunate. Is perl -MCPAN -e 'install Platypus::FFI' a
> viable alternative?
Probably, see my followup.
On Wed, Oct 18, 2023 at 11:43 AM Tom Lane wrote:
> Having said that ... I read the man page for FFI::Platypus,
> and I'm failing to draw a straight line between what it can do
> and what we need. Aren't we going to need a big chunk of new
> Perl code anyway? If so, why not write a big chunk of
Re: Michael Paquier
> Generate automatically code and documentation related to wait events
Hi,
I'm not entirely sure this is the commit to blame, but it's certainly
close:
A Debian user is complaining that in PG17, the installed
/usr/include/postgresql/17/server/utils/wait_event.h file is
On Sat, Sep 2, 2023 at 2:42 PM Andrew Dunstan wrote:
> I confess I'm a little reluctant to impose this burden on buildfarm owners.
> We should think about some sort of fallback in case this isn't supported on
> some platform, either due to technological barriers or buildfarm owner
>
On Wed, Oct 18, 2023 at 3:21 AM Peter Eisentraut wrote:
> On 18.10.23 06:40, David Rowley wrote:
> > I agree that it's not nice to add yet another way of breaking the
> > buildfarm and even more so when the committer did make check-world
> > before committing. We have --enable-tap-tests, we could
On Tue, Oct 17, 2023 at 8:35 PM Michael Paquier wrote:
> Suggestion is from here, with a test for pg_walinspect after it runs
> its online checkpoint (see the full-page case):
> https://www.postgresql.org/message-id/ZOvf1tu6rfL/b...@paquier.xyz
>
> +-- Check presence of REDO record.
> +SELECT
On 10/18/23 12:13, Dean Rasheed wrote:
> On Tue, 17 Oct 2023 at 21:25, Tomas Vondra
> wrote:
>>
>> Here's a couple cleaned-up patches fixing the various discussed here.
>> I've tried to always add a regression test demonstrating the issue
>> first, and then fix it in the next patch.
>>
>
>
On Tue, Oct 17, 2023 at 7:35 PM Tom Lane wrote:
> Thomas Munro writes:
> > On Wed, Oct 18, 2023 at 11:54 AM Tom Lane wrote:
> >> Should we be testing against xlclang instead?
>
> > I hesitated to suggest it because it's not my animal/time we're
> > talking about but it seems to make more sense.
Robert Haas writes:
> On Tue, Oct 17, 2023 at 7:35 PM Tom Lane wrote:
>> Discounting the Windows animals, it looks like the xlc animals are
>> our only remaining ones that use anything except gcc or clang.
> After some research I determined that the release date for xlc 12.1
> seems to be June
Robert Haas writes:
> On Sat, Sep 2, 2023 at 2:42 PM Andrew Dunstan wrote:
>>> How much burden is it? Would anyone actually mind?
> ... At the same time, fallbacks can be a problem too,
> because then you can end up with things that work one way on one
> developer's machine (or BF machine) and
On 10/18/23 12:47, Ashutosh Bapat wrote:
> On Wed, Oct 18, 2023 at 1:55 AM Tomas Vondra
> wrote:
>>
>> Hi,
>>
>> Here's a couple cleaned-up patches fixing the various discussed here.
>> I've tried to always add a regression test demonstrating the issue
>> first, and then fix it in the next patch.
On Wed, Oct 18, 2023 at 10:28 AM Tom Lane wrote:
> I did a bit of research on this on my favorite platforms, and did
> not like the results:
Hmm. That's unfortunate. Is perl -MCPAN -e 'install Platypus::FFI' a
viable alternative?
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Oct 17, 2023 at 2:01 PM shveta malik wrote:
>
> On Tue, Oct 17, 2023 at 12:44 PM Peter Smith wrote:
> >
> > FYI - the latest patch failed to apply.
> >
> > [postgres@CentOS7-x64 oss_postgres_misc]$ git apply
> >
On Thu, Oct 19, 2023 at 12:02 AM Thomas Munro wrote:
> I pushed the first patch, for LLVM 16, and the build farm told me that
> some old LLVM versions don't like it. The problem seems to be the
> function LLVMGlobalGetValueType(). I can see that that was only added
> to the C API in 2018, so it
On 10/17/23 16:23, Tom Lane wrote:
An alternative I was thinking about after reading your earlier email was
going back to the status quo ante, but doing the manual tree-wide
reindents significantly more often than once a year. Adding one at the
conclusion of each commitfest would be a natural
Dear Peter,
Thank you for reviewing! PSA new version.
Note that 0001 and 0002 are combined into one patch.
> Here are some review comments for v51-0001
>
> ==
> src/bin/pg_upgrade/check.c
>
> 0.
> +check_old_cluster_for_valid_slots(bool live_check)
> +{
> + char output_path[MAXPGPATH];
> +
On Tue, 17 Oct 2023 at 21:25, Tomas Vondra
wrote:
>
> Here's a couple cleaned-up patches fixing the various discussed here.
> I've tried to always add a regression test demonstrating the issue
> first, and then fix it in the next patch.
>
This looks good to me.
> 2) incorrect subtraction in
On Wed, Oct 18, 2023 at 1:55 AM Tomas Vondra
wrote:
>
> Hi,
>
> Here's a couple cleaned-up patches fixing the various discussed here.
> I've tried to always add a regression test demonstrating the issue
> first, and then fix it in the next patch.
It will be good to commit the test changes as
On Wed, 18 Oct 2023 at 09:16, Tomas Vondra
wrote:
>
> BTW when adding the tests with extreme values, I noticed this:
>
> test=# select '5874897-01-01'::date;
>date
> ---
>5874897-01-01
> (1 row)
>
> test=# select '5874897-01-01'::date + '1 second'::interval;
>
On Wed, 18 Oct 2023 at 22:07, Jelte Fennema wrote:
> But based on the contents of the fixup commits a commonality seems to
> be that the fixup only fixes a few lines, quite often touching only
> comments. So it seems like the main reason for breaking koel is
> forgetting to re-run pgindent after
On Wed, Oct 18, 2023 at 10:20 AM Amit Kapila wrote:
>
> On Tue, Oct 17, 2023 at 9:06 PM Drouvot, Bertrand
> wrote:
> >
> > On 10/13/23 10:35 AM, shveta malik wrote:
> > > On Thu, Oct 12, 2023 at 9:18 AM shveta malik
> > > wrote:
> > >>
> >
> > Code:
> >
> > + True if this logical slot is
Hi Alexander,
Sorry for my long offline and thanks for the activity. So should we close
the patch on the commitfest page now?
By the way I had one more issue with the login trigger tests (quite a rare
one though). A race condition may occur on some systems, when oidjoins test
starts a moment
On Tue, Oct 17, 2023 at 4:17 PM David Steele wrote:
> Given that the above can't be back patched, I'm thinking we don't need
> backup_label at all going forward. We just write the values we need for
> recovery into pg_control and return *that* from pg_backup_stop() and
> tell the user to store it
Hi!
Thank you for your work on the subject.
I reviewed your patch and found that your commit message does not fully
explain your code, in addition, I found several spelling mistakes.
I think it's better to change to:
With parallel seqscan, we should consider materializing the cheapest
On 18/10/2023 13:39, Richard Guo wrote:
On Fri, Oct 13, 2023 at 6:18 PM Andrei Lepikhov
mailto:a.lepik...@postgrespro.ru>> wrote:
On 23/8/2023 12:37, Richard Guo wrote:
> To fix it we may need to modify RelOptInfos for Path, BitmapHeapPath,
> ForeignPath and CustomPath, and
On Wed, Oct 18, 2023 at 11:39 AM torikoshia wrote:
> >
> > I am more interested in avoiding the duplication of code, esp. the
> > first comment in my reply
>
> If there are no objections, I will try porting it to auto_explain and
> see its feasibility.
If you want it in core, you will need to
Hi, Mikhail.
On Wed, Oct 18, 2023 at 1:30 PM Mikhail Gribkov wrote:
> Sorry for my long offline and thanks for the activity. So should we close the
> patch on the commitfest page now?
I have just done this.
> By the way I had one more issue with the login trigger tests (quite a rare
> one
On Tue, 2023-10-17 at 22:52 -0400, Stephen Frost wrote:
> Reading back through the thread, from a user perspective, the primary
> one seems to be that passwords are expected to be named. I'm
> surprised
> this is being brought up as such a serious concern. Lots and lots
> and
> lots of things
Hi,
On 2023-10-19 06:20:26 +1300, Thomas Munro wrote:
> On Thu, Oct 19, 2023 at 1:06 AM Thomas Munro wrote:
> > On Thu, Oct 19, 2023 at 12:02 AM Thomas Munro
> > wrote:
> > > I pushed the first patch, for LLVM 16, and the build farm told me that
> > > some old LLVM versions don't like it. The
Greetings,
* Andrei Lepikhov (a.lepik...@postgrespro.ru) wrote:
> On 29/9/2023 09:52, Andrei Lepikhov wrote:
> > On 22/5/2023 22:59, reid.thomp...@crunchydata.com wrote:
> > > Attach patches updated to master.
> > > Pulled from patch 2 back to patch 1 a change that was also pertinent
> > > to
On Thu, Sep 21, 2023 at 12:27 PM Devrim Gündüz wrote:
> Even though older LLVM versions exist on both RHEL and Fedora, they
> don't provide older Clang packages, which means we have to link to the
> latest release anyway (like currently Fedora 38 packages are waiting for
> LLVM 16 patch, as they
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I wrote:
> > Why are we marking extension member objects as being subject to SECLABEL
> > or POLICY dumping? As the comment notes, that isn't really sensible
> > unless what we are dumping is a delta from the extension's initial
> >
Greetings,
* Melih Mutlu (m.melihmu...@gmail.com) wrote:
> Melih Mutlu , 16 Haz 2023 Cum, 17:03 tarihinde şunu
> yazdı:
>
> > With this change, here's a query to find how much space used by each
> > context including its children:
> >
> > > WITH RECURSIVE cte AS (
> > > SELECT id,
Robert Haas writes:
> On Wed, Oct 18, 2023 at 12:02 PM Tom Lane wrote:
>> Probably. Independent of that, it's fair to ask why we're still
>> testing against xlc 12.1 and not the considerably-more-recent xlclang,
>> or at least xlc 16.1. (I also wonder why we're still testing AIX 7.1
>> rather
Stephen Frost writes:
> Greetings,
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I wrote:
>>> Why are we marking extension member objects as being subject to SECLABEL
>>> or POLICY dumping?
> This change would mean that policies added by a user after the extension
> is created would just be lost
On Wed, Oct 18, 2023 at 2:09 AM torikoshia wrote:
>
> On 2023-10-16 18:46, Ashutosh Bapat wrote:
> > On Thu, Oct 12, 2023 at 6:51 PM torikoshia
> > wrote:
> >>
> >> On 2023-10-11 16:22, Ashutosh Bapat wrote:
> >> >
> >> > Considering the similarity with auto_explain I wondered whether this
> >>
On Wed, Oct 18, 2023 at 12:02 PM Tom Lane wrote:
> Probably. Independent of that, it's fair to ask why we're still
> testing against xlc 12.1 and not the considerably-more-recent xlclang,
> or at least xlc 16.1. (I also wonder why we're still testing AIX 7.1
> rather than an OS version that's
*rouge
On Thu, Oct 19, 2023 at 1:06 AM Thomas Munro wrote:
> On Thu, Oct 19, 2023 at 12:02 AM Thomas Munro wrote:
> > I pushed the first patch, for LLVM 16, and the build farm told me that
> > some old LLVM versions don't like it. The problem seems to be the
> > function LLVMGlobalGetValueType(). I
Hi,
On Thu, 2023-10-19 at 06:20 +1300, Thomas Munro wrote:
> Pushed, after digging up some old LLVM skeletons to test, and those
> "old LLVM" animals are turning green now. I went ahead and pushed the
> much smaller and simpler patch for LLVM 17.
Thank you! I can confirm that RPMs built fine
On Mon, Oct 16, 2023 at 11:28 AM Andrei Lepikhov
wrote:
> On 12/10/2023 18:32, Alexander Korotkov wrote:
> > On Thu, Oct 5, 2023 at 12:17 PM Andrei Lepikhov
> > wrote:
> >> On 4/10/2023 14:34, Alexander Korotkov wrote:
> >>> > Relid replacement machinery is the most contradictory code here. We
On Tue, Oct 17, 2023 at 08:39:49AM +1100, Timothy Nelson wrote:
> Great! I'm not surprised it's been around a long time -- I didn't think I
> could be the only one to think of it.
>
> Thanks for the heads-up on Postgres-XL -- I'd missed that one somehow.
>
> I'm going to include the words
Hi hackers,
After committing the on-login trigger
(e83d1b0c40ccda8955f1245087f0697652c4df86) the event_trigger regress test
became sensible to any other parallel tests, not only DDL. Thus it should
be placed in a separate parallel schedule group.
The current problem is that a race condition may
On Tue, Oct 17, 2023 at 11:01:44AM -0400, Robert Haas wrote:
> In fact, that particular experience is one of the worst things about
> being a committer. It actively discourages me, at least, from trying
> to get other people's patches committed. This particular problem is
> minor, but the overall
Greetings,
* Jeff Davis (pg...@j-davis.com) wrote:
> On Tue, 2023-10-17 at 22:52 -0400, Stephen Frost wrote:
>
> > Reading back through the thread, from a user perspective, the primary
> > one seems to be that passwords are expected to be named. I'm
> > surprised
> > this is being brought up as
Hi,
On 2023-10-16 20:45:00 -0400, Tom Lane wrote:
> Peter Geoghegan writes:
> 2. We could raise awareness of this issue by adding indent verification
> to CI testing. I hesitate to suggest that, though, for a couple of
> reasons:
>2a. It seems fairly expensive, though I might be misjudging.
99 matches
Mail list logo
