On Mon, Dec 05, 2022 at 08:27:15AM +0100, Drouvot, Bertrand wrote:
> On 12/4/22 6:32 PM, Nathan Bossart wrote:
>> Alright. I marked this as ready-for-committer.
>
> Thanks!
Well, that's kind of nice:
5 files changed, 139 insertions(+), 396 deletions(-)
And I like removing code, so..
In the
Hi,
On 12/4/22 6:32 PM, Nathan Bossart wrote:
On Sun, Dec 04, 2022 at 06:07:37AM +0100, Drouvot, Bertrand wrote:
On 12/3/22 9:16 PM, Nathan Bossart wrote:
Thanks. I editorialized a bit in the attached v3. I'm not sure that my
proposed names for the macros are actually an improvement. WDYT?
On Sat, Dec 03, 2022 at 11:45:30AM +0900, Michael Paquier wrote:
> While this is correct in checking that the contents are compressed
> under --with-zlib, this also removes the coverage where we make sure
> that this command is able to complete under --without-zlib without
> compressing any of the
Hi,
I see that in the archiver code, in the function pgarch_MainLoop,
the archiver sleeps for a certain time or until there's a signal. The time
it sleeps for is represented by:
timeout = PGARCH_AUTOWAKE_INTERVAL - (curtime - last_copy_time);
It so happens that last_copy_time and curtime are
At Thu, 1 Dec 2022 19:23:28 -0800, Andres Freund wrote in
> > AtEOXact_PgStat_DroppedStats() visits a relation that has been dropped
> > then wiped (when CLOBBER_FREED_MEMORY) by AtEOXact_RelationCache()
> > called just before. Since the relcache content directly pointed from
> > stats module
On Mon, Dec 5, 2022 at 12:00 PM Amit Langote wrote:
> On Fri, Dec 2, 2022 at 7:40 PM Amit Langote wrote:
> > Thought it might be good for PartitionPruneResult to also have
> > root_parent_relids that matches with the corresponding
> > PartitionPruneInfo. ExecInitPartitionPruning() does a sanity
On Fri, Dec 02, 2022 at 11:09:15AM +, Niyas Sait wrote:
> I've attached a new revision of the patch (v5) and includes following
> changes,
>
> 1. Add support for meson build system
> 2. Extend MSVC scripts to handle ARM64 platform.
> 3. Add arm64 definition of spin_delay function.
> 4.
On Sun, Dec 4, 2022 at 9:37 PM Pavel Stehule
wrote:
>
> po 5. 12. 2022 v 5:28 odesílatel Tom Lane napsal:
>
>> Peifeng Qiu writes:
>> >> the need for this code seems not that great. But as to the code
>> itself I'm unable to properly judge.
>>
>> I mention this because trying to
Pavel Stehule writes:
> po 5. 12. 2022 v 5:28 odesílatel Tom Lane napsal:
>> I tend to agree with David that LATERAL offers a good-enough
>> solution in most cases ... but it is annoying that we accept
>> this syntax and then pessimize it.
> I agree, so there is a perfect solution like don't
On Thu, 1 Dec 2022 at 21:18, Richard Guo wrote:
>> + if (!func_strict(opexpr->opfuncid))
>> + return false;
>>
>> Should return true instead?
>
>
> Yeah, you're right. This should be a thinko.
Yeah, oops. That's wrong.
I've adjusted that in the attached.
I'm keen to move along and
po 5. 12. 2022 v 5:28 odesílatel Tom Lane napsal:
> Peifeng Qiu writes:
> >> the need for this code seems not that great. But as to the code itself
> I'm unable to properly judge.
>
> > A simplified version of my use case is like this:
> > CREATE FOREIGN TABLE ft(rawdata json);
> > INSERT INTO
Peifeng Qiu writes:
>> the need for this code seems not that great. But as to the code itself I'm
>> unable to properly judge.
> A simplified version of my use case is like this:
> CREATE FOREIGN TABLE ft(rawdata json);
> INSERT INTO tbl SELECT (convert_func(rawdata)).* FROM ft;
It might be
On Mon, 28 Nov 2022 at 22:59, Sergey Shinderuk
wrote:
>
> On 28.11.2022 03:23, David Rowley wrote:
> > On Sat, 26 Nov 2022 at 05:19, Tom Lane wrote:
> >> It's pretty unlikely that this would work during an actual index scan.
> >> I'm fairly sure that btree (and other index AMs) have hard-wired
>
On Mon, Dec 05, 2022 at 08:48:25AM +0530, Bharath Rupireddy wrote:
> So, a SQL function pg_dissect_walfile_name (or some other better name)
> given a WAL file name returns the tli and seg number. Then the
> pg_walfile_offset_lsn can just be a SQL-defined function (in
> system_functions.sql) using
On Fri, 2 Dec 2022 at 00:21, Sergey Shinderuk
wrote:
> Maybe I'm missing something, but the previous call to spool_tuples()
> might have read extra tuples (if the tuplestore spilled to disk), and
> after switching to WINDOWAGG_PASSTHROUGH_STRICT mode we nevertheless
> would loop through these
On Sun, Dec 4, 2022 at 9:00 PM Peifeng Qiu wrote:
> > the need for this code seems not that great. But as to the code itself
> I'm unable to properly judge.
> A simplified version of my use case is like this:
> CREATE FOREIGN TABLE ft(rawdata json);
> INSERT INTO tbl SELECT
> the need for this code seems not that great. But as to the code itself I'm
> unable to properly judge.
A simplified version of my use case is like this:
CREATE FOREIGN TABLE ft(rawdata json);
INSERT INTO tbl SELECT (convert_func(rawdata)).* FROM ft;
We have a foreign data source that can emit
On Mon, Dec 5, 2022 at 8:59 AM Amit Kapila wrote:
>
> On Sun, Dec 4, 2022 at 5:14 PM houzj.f...@fujitsu.com
> wrote:
> >
> > On Saturday, December 3, 2022 7:37 PM Amit Kapila
> > wrote:
> > > Apart from the above, I have slightly adjusted the comments in the
> > > attached. Do
> > > let me
On Thu, Dec 1, 2022 at 6:14 AM Alexander Korotkov wrote:
> On Wed, Nov 23, 2022 at 1:53 AM Steve Chavez wrote:
> > So from my side this all looks good!
>
> Thank you for your feedback.
>
> The next revision of the patch is attached. It contains code
> improvements, comments and documentation.
On Sun, Dec 4, 2022 at 5:14 PM houzj.f...@fujitsu.com
wrote:
>
> On Saturday, December 3, 2022 7:37 PM Amit Kapila
> wrote:
> > Apart from the above, I have slightly adjusted the comments in the
> > attached. Do
> > let me know what you think of the attached.
>
> Thanks for updating the patch.
On Mon, Dec 5, 2022 at 6:34 AM Michael Paquier wrote:
>
> Regarding pg_walfile_offset_lsn(), I am not sure that this is the best
> move we can do as it is possible to compile a LSN from 0/0 with just a
> segment number, say:
> select '0/0'::pg_lsn + :segno * setting::int + :offset
> from
On Tue, Nov 29, 2022 at 7:51 PM Jeff Davis wrote:
> On Sat, 2022-11-26 at 18:27 +1300, Thomas Munro wrote:
> > On Thu, Nov 24, 2022 at 5:48 PM Thomas Munro
> > wrote:
> > > On Thu, Nov 24, 2022 at 3:07 PM Jeff Davis
> > > wrote:
> > > > I'd vote for 1 on the grounds that it's easier to document
On Fri, Dec 2, 2022 at 7:40 PM Amit Langote wrote:
> On Thu, Dec 1, 2022 at 9:43 PM Amit Langote wrote:
> > On Thu, Dec 1, 2022 at 8:21 PM Alvaro Herrera
> > wrote:
> > > On 2022-Dec-01, Amit Langote wrote:
> > > > Hmm, how about keeping the [Merge]Append's parent relation's RT index
> > > >
On Sat, Dec 03, 2022 at 03:58:19PM +0900, Ian Lawrence Barwick wrote:
> A few of the developer option GUCs were missing the "id" attribute
> in their markup, making it impossible to link to them directly.
True enough that the other developer GUCs do that, so applied and
backpatched down to 11.
--
Hi Mr.Pyhalov.
> Attaching minor fixes. I haven't proof-read all comments (but perhaps, they
> need attention from some native speaker).
Thank you. I fixed according to your patch.
And I fixed have proof-read all comments and messages.
> Tested it with queries from
>
Hi
On this page:
https://www.postgresql.org/docs/current/extend-extensions.html
three of the sections are missing an "id" attribute; patch adds
these. Noticed when trying to create a stable link to one of the affected
sections.
Regards
Ian Barwick
From
On Sat, Dec 03, 2022 at 05:34:57PM +, Matheus Alcantara wrote:
> I've tested your patched on current master and seems to be working properly.
>
> I'm starting reviewing some patches here, let's see what more experience
> hackers
> has to say about this, but as far I can tell is that is
On Sun, Dec 04, 2022 at 06:01:33PM +0100, Vik Fearing wrote:
> Once/If I get that in, I will be pushing to get that syntax in postgres as
> well.
If I may ask, how long would it take to know if this grammar would be
integrated in the standard or not?
--
Michael
signature.asc
Description: PGP
On Sat, Dec 03, 2022 at 09:07:38AM +0530, Bharath Rupireddy wrote:
> Yes, I removed those changes. Even if someone sees an offset of a
> record within a WAL file elsewhere, they have the new utility function
> (0002) pg_walfile_offset_lsn().
>
> I'm attaching the v4 patch set for further review.
On Wed, Nov 02, 2022 at 08:00:58AM -0700, Zhihong Yu wrote:
> Looking down in ri_PerformCheck(), I see there may be case where error from
> SPI_execute_snapshot() would skip restoring UID.
> @@ -2405,13 +2405,19 @@ ri_PerformCheck(const RI_ConstraintInfo *riinfo,
>
On Sun, 4 Dec 2022 at 22:53, Dean Rasheed wrote:
> Ah, I see that you changed the overflow test, and I realise that I
> forgot to answer your question about why I wrote that as 1 - INT_MIN /
> 10 over on the other thread.
>
> The reason is that we need to detect whether tmp * base will exceed
>
On Tue, Nov 29, 2022 at 5:13 PM Melanie Plageman
wrote:
> Thanks for the review, Maciek!
>
> I've attached a new version 39 of the patch which addresses your docs
> feedback from this email as well as docs feedback from Andres in [1] and
> Justin in [2].
This looks great! Just a couple of minor
Daniel Gustafsson writes:
>> On 4 Dec 2022, at 16:35, Tom Lane wrote:
>> Our policy is that the in-tree .gitignore files should only hide
>> files that are build artifacts of standard build processes.
>> Something like this belongs in your personal ~/.gitexclude,
>> instead.
> Since this comes
> On 4 Dec 2022, at 16:35, Tom Lane wrote:
>
> Sayyid Ali Sajjad Rizavi writes:
>> +**/.idea
>
> Our policy is that the in-tree .gitignore files should only hide
> files that are build artifacts of standard build processes.
> Something like this belongs in your personal ~/.gitexclude,
>
On Sat, Dec 03, 2022 at 07:13:30PM +0400, Ilya Gladyshev wrote:
> Hi,
>
> Thank you Justin and Alexander for working on this, I have reviewed and
> tested the latest patch, it works well, the problems mentioned
> previously are all fixed. I like the idea of sharing code of reindex
> and index,
On Sun, Dec 04, 2022 at 06:07:37AM +0100, Drouvot, Bertrand wrote:
> On 12/3/22 9:16 PM, Nathan Bossart wrote:
>> Thanks. I editorialized a bit in the attached v3. I'm not sure that my
>> proposed names for the macros are actually an improvement. WDYT?
>
> Thanks! I do prefer the macros
On 04/12/22 22:25, Vik Fearing wrote:
On 12/4/22 14:34, Ankit Kumar Pandey wrote:
This looks like way to go that would ensure main use case of
portability from Oracle.
The goal should not be portability from Oracle, but adherence to the
standard.
Yes, Vik. You are right. Wrong remark
On 12/4/22 17:21, Andrew Dunstan wrote:
More generally, I can see uses for error free
casts, something like, say CAST(foo AS bar ON ERROR blurfl)
What I am proposing for inclusion in the standard is basically the same
as what JSON does:
::=
CAST
AS
[ FORMAT ]
[ ON ERROR ]
On 12/4/22 14:34, Ankit Kumar Pandey wrote:
On 04/12/22 02:27, David Rowley wrote:
If you were to limit this to only working with the query you mentioned
in [1], i.e PARTITION BY without an ORDER BY, then you only need to
aggregate once per partition per aggregate and you only need to do
On 2022-12-04 Su 10:25, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 2022-12-03 Sa 16:46, Tom Lane wrote:
>>> 1. Bikeshedding on my name choices is welcome. I know Robert is
>>> dissatisfied with "ereturn", but I'm content with that so I didn't
>>> change it here.
>> details_please seems
Sayyid Ali Sajjad Rizavi writes:
> +**/.idea
Our policy is that the in-tree .gitignore files should only hide
files that are build artifacts of standard build processes.
Something like this belongs in your personal ~/.gitexclude,
instead.
(BTW, perhaps we should remove the entries targeting
I searched the commit fest app and there's already someone who has made
this.
On Sun, Dec 4, 2022 at 7:28 AM Sayyid Ali Sajjad Rizavi
wrote:
> From 6d10dafdd7c7789eddd7fd72ca22dfde74febe23 Mon Sep 17 00:00:00 2001
> From: Ali Sajjad
> Date: Sun, 4 Dec 2022 06:03:11 -0800
> Subject: [PATCH] Add
>From 6d10dafdd7c7789eddd7fd72ca22dfde74febe23 Mon Sep 17 00:00:00 2001
From: Ali Sajjad
Date: Sun, 4 Dec 2022 06:03:11 -0800
Subject: [PATCH] Add .idea to gitignore for JetBrains CLion
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index
Andrew Dunstan writes:
> On 2022-12-03 Sa 16:46, Tom Lane wrote:
>> 1. Bikeshedding on my name choices is welcome. I know Robert is
>> dissatisfied with "ereturn", but I'm content with that so I didn't
>> change it here.
> details_please seems more informal than our usual style. details_wanted
On 04/12/22 02:27, David Rowley wrote:
To make this work when rows can exit the window frame seems
significantly harder. Likely a hash table would be a better data
structure to remove records from, but then how are you going to spill
the hash table to disk when it reaches work_mem? As David J
On 2022-12-03 Sa 16:46, Tom Lane wrote:
> Andrew Dunstan writes:
>> Great. Let's hope we can get this settled early next week and then we
>> can get to work on the next tranche of functions, those that will let
>> the SQL/JSON work restart.
> OK, here's a draft proposal. I should start out by
On Saturday, December 3, 2022 7:37 PM Amit Kapila
wrote:
>
> On Tue, Nov 29, 2022 at 12:23 PM houzj.f...@fujitsu.com
> wrote:
> >
> > On Tuesday, November 29, 2022 12:08 PM Dilip Kumar
> wrote:
> >
> > I have few comments about the patch.
> >
> > 1.
> >
> > 1.1.
> > - /* For streamed
On Friday, December 2, 2022 4:59 PM Peter Smith wrote:
>
> Here are my review comments for patch v54-0001.
Thanks for the comments!
> ==
>
> FILE: .../replication/logical/applyparallelworker.c
>
> 1b.
>
> + *
> + * This file contains routines that are intended to support setting up,
> +
On Friday, December 2, 2022 7:27 PM Kuroda, Hayato/黒田 隼人
wroteL
>
> Dear Hou,
>
> Thanks for making the patch. Followings are my comments for v54-0003 and
> 0004.
Thanks for the comments!
>
> 0003
>
> pa_free_worker()
>
> + /* Unlink any files that were needed to serialize partial
On Sun, 4 Dec 2022 at 03:19, David Rowley wrote:
>
> Pushed with some small adjustments.
>
Ah, I see that you changed the overflow test, and I realise that I
forgot to answer your question about why I wrote that as 1 - INT_MIN /
10 over on the other thread.
The reason is that we need to detect
50 matches
Mail list logo
