On Fri, 11 Nov 2022 at 22:20, John Naylor wrote:
>
>
> On Wed, Oct 12, 2022 at 4:37 PM David Rowley wrote:
> > [v3]
>
> + /*
> + * Compute a shift that guarantees that shifting chunksPerBlock with it
> + * yields is smaller than SLAB_FREELIST_COUNT - 1 (one freelist is used for
> full blocks).
>
On 02.12.22 09:34, Daniel Gustafsson wrote:
On 2 Dec 2022, at 08:09, Peter Eisentraut
wrote:
fixed
+1 on this version of the patch, LGTM.
committed
I also put back the old long options forms in the documentation and help but
marked them deprecated.
+ --blobs (deprecated)
While
Hi,
On 12/5/22 8:44 AM, Michael Paquier wrote:
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
Hi!
>I think storing this in pg_control is a bad idea. That file is
>extremely critical and if you break it, you're pretty much SOL on
>recovering your data. I suggest that this should use a separate file.
Thanks. Operation log location changed to 'global/pg_control_log' (if
the name is not p
On Mon, Dec 05, 2022 at 09:11:43AM +0100, Drouvot, Bertrand wrote:
> Means, once the current patch is committed, working on [1] and
> "cleaning" the databases one could be done in parallel. Sounds good
> to you?
Doing that in a separate patch is fine by me.
--
Michael
signature.asc
Description:
I had noticed that most getopt() or getopt_long() calls had their letter
lists in pretty crazy orders. There might have been occasional attempts
at grouping, but those then haven't been maintained as new options were
added. To restore some sanity to this, I went through and ordered them
alpha
Hello Peter,
I had noticed that most getopt() or getopt_long() calls had their letter
lists in pretty crazy orders. There might have been occasional attempts
at grouping, but those then haven't been maintained as new options were
added. To restore some sanity to this, I went through and ord
> Which is properly written as the following, using lateral, which also avoids
> the problem you describe:
>
> INSERT INTO tbl
> SELECT func_call.*
> FROM ft
> JOIN LATERAL convert_func(ft.rawdata) AS func_call ON true;
I didn't fully realize this syntax until you point out. Just try it out in
ou
On 05/12/2022 05:12, Michael Paquier wrote:
- Last comes OpenSSL, that supports amd64_arm64 as build target (see
NOTES-WINDOWS.md), and the library names are libssl.lib and
libcrypto.lib. Looking at
https://slproweb.com/products/Win32OpenSSL.html, there are
experimental builds for arm64 with O
On Sun, Dec 4, 2022 at 4:48 PM houzj.f...@fujitsu.com
wrote:
>
> On Friday, December 2, 2022 4:59 PM Peter Smith wrote:
> >
>
> > ~~~
> >
> > 12. pa_clean_subtrans
> >
> > +/* Reset the list that maintains subtransactions. */ void
> > +pa_clean_subtrans(void)
> > +{
> > + subxactlist = NIL;
> > +
In the pg_dump blob terminology thread it was briefly discussed [0] to mark
parameters as deprecated in the --help output. The attached is a quick diff to
show that that would look like. Personally I think it makes sense, not
everyone will read the docs.
--
Daniel Gustafsson https:
On Sat, Dec 3, 2022 at 10:41 AM Thomas Munro wrote:
> Here's an iteration like that. Still WIP grade. It passes, but there
> must be something I don't understand about this computer program yet,
> because if I move the "if (pending_..." section up into the block
> where WL_LATCH_SET has arrived
On 2022-Dec-05, Ian Lawrence Barwick wrote:
> 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.
Hm, I was
On Mon, Dec 5, 2022 at 9:21 AM Dilip Kumar wrote:
>
> 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 sligh
On Mon, Dec 5, 2022 at 3:02 PM David Rowley wrote:
>
> On Fri, 11 Nov 2022 at 22:20, John Naylor
wrote:
> > #define SLAB_FREELIST_COUNT ((1<<3) + 1)
> > index = (freecount & (SLAB_FREELIST_COUNT - 2)) + (freecount != 0);
>
> Doesn't this create a sort of round-robin use of the free list? What
>
I happened to notice that currently MemoizePath cannot be generated for
partitionwise join. I traced that and have found the problem. One
condition we need to meet to generate MemoizePath is that inner path's
ppi_clauses should have the form "outer op inner" or "inner op outer",
as checked by cla
On Mon, Dec 5, 2022 at 3:41 PM Dilip Kumar wrote:
>
> On Mon, Dec 5, 2022 at 9:21 AM Dilip Kumar wrote:
> >
> > 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
On Fri, Dec 2, 2022 at 9:13 PM Tom Lane wrote:
>
> Ashutosh Bapat writes:
> > On Fri, Dec 2, 2022 at 8:25 AM Tom Lane wrote:
> >> Unfortunately, I don't have an example that produces such a
> >> failure against HEAD. It seems certain to me that such cases
> >> exist, though, so I'd like to appl
> 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 an
After posting the patch I've found my own typo in docs. So corrected
it in v5 (PFA).
Regards,
Pavel.
v5-0001-USER-SET-parameters-for-pg_db_role_setting.patch
Description: Binary data
Over in [1], Masahiko and I found that using some bitmapset logic yields a
useful speedup in one part of the proposed radix tree patch. In addition to
what's in bitmapset.h now, we'd need WORDNUM, BITNUM, RIGHTMOST_ONE and
bmw_rightmost_one_pos() from bitmapset.c. The file tidbitmap.c has its own
c
On 2022-Dec-05, John Naylor wrote:
> diff --git a/src/backend/nodes/bitmapset.c b/src/backend/nodes/bitmapset.c
> index b7b274aeff..3204b49738 100644
> --- a/src/backend/nodes/bitmapset.c
> +++ b/src/backend/nodes/bitmapset.c
> @@ -26,33 +26,9 @@
> #include "port/pg_bitutils.h"
>
>
> -#define
Hi hackers,
I've been working on/struggling with this patch for a while. But I haven't
updated this thread regularly.
So sharing what I did with this patch so far.
> Amit Kapila , 6 Ağu 2022 Cmt, 16:01 tarihinde
> şunu yazdı:
> >>
> >> I think there is some basic flaw in slot reuse design. Curren
Dear Nathan,
Thank you for making the patch! I tested your patch, and it basically worked
well.
About following part:
```
ConfigReloadPending = false;
ProcessConfigFile(PGC_SIGHUP);
+ now = GetCurrentTimestamp();
+
On Fri, Dec 2, 2022 at 5:43 AM Andres Freund wrote:
>
> > + /* Loop over offsets and validate the data in the
> predecessor array. */
> > + for (OffsetNumber currentoffnum = FirstOffsetNumber;
> currentoffnum <= maxoff;
> > + currentoffnum = OffsetNumb
Hi Ian,
Ian Lawrence Barwick writes:
> Hi Dag
>
> 2022年2月3日(木) 23:27 Dag Lem :
>>
>> Hi,
>>
>> Just some minor adjustments to the patch:
>>
>> * Removed call to locale-dependent toupper()
>> * Cleaned up input normalization
>
> This patch was marked as "Waiting on Author" in the CommitFest entry
On Mon, Dec 5, 2022 at 6:30 PM Melih Mutlu wrote:
>
> Attached two patches:
> 0001: adds REPLICATION_SLOT_SNAPSHOT command for replication protocol.
> 0002: Reuses workers/replication slots and origins for tablesync
>
> I would appreciate any feedback/review/thought on the approach and both
> pat
On Mon, Dec 5, 2022 at 2:27 PM Pavel Borisov wrote:
> After posting the patch I've found my own typo in docs. So corrected
> it in v5 (PFA).
The new revision of the patch is attached.
I've removed the mention of "(s)" suffix from the "Server
Configuration" docs section. I think it might be confu
Alvaro Herrera writes:
> On 2022-Dec-05, John Naylor wrote:
>> -#define WORDNUM(x) ((x) / BITS_PER_BITMAPWORD)
>> -#define BITNUM(x) ((x) % BITS_PER_BITMAPWORD)
> In this location, nobody can complain about the naming of these macros,
> since they're just used to implement other bitmapset.c co
Ashutosh Bapat writes:
> partition-wise join should be willing to fallback to non-partitionwise
> join in such a case. After spending a few minutes with the code, I
> think generate_partitionwise_join_paths() should not call
> set_cheapest() is the pathlist of the child is NULL and should just
> w
Hi, Alexander!
On Mon, 5 Dec 2022 at 17:51, Alexander Korotkov wrote:
>
> On Mon, Dec 5, 2022 at 2:27 PM Pavel Borisov wrote:
> > After posting the patch I've found my own typo in docs. So corrected
> > it in v5 (PFA).
>
> The new revision of the patch is attached.
>
> I've removed the mention o
The SQL:2023 Standard defines a new aggregate named ANY_VALUE. It
returns an implementation-dependent (i.e. non-deterministic) value from
the rows in its group.
PFA an implementation of this aggregate.
Ideally, the transition function would stop being called after the first
non-null was foun
On Fri, Dec 2, 2022 at 11:29 PM Ian Lawrence Barwick wrote:
> Though on reflection maybe it's overkill and the existing tests
> suffice. Anyway leaving the patch here in the interests of pushing
> this forward in some direction.
Do you think that there is a scenario where 008_untar.pl and
009_ext
On Sat, Dec 3, 2022 at 11:07 AM Andrew Dunstan wrote:
> > Well, what this would lose is the ability to selectively restore
> > individual large objects using "pg_restore -L". I'm not sure who
> > out there might be depending on that, but if we assume that's the
> > empty set I fear we'll find out
On Fri, Sep 10, 2021 at 5:07 PM Tomas Vondra
wrote:
> Turns out it's pretty difficult to benchmark this, because the results
> strongly depend on what the backend did before.
What you report here seems to be mostly cold-cache effects, with which
I don't think we need to be overly concerned. We do
On Sun, 4 Dec 2022 at 00:35, David Rowley wrote:
>
> On Tue, 29 Nov 2022 at 21:59, Yuya Watari wrote:
> > Thank you for testing the patch with an actual query. This speedup is
> > very impressive. When I used an original query with 1024 partitions,
> > its planning time was about 200ms. Given tha
On Sun, Dec 4, 2022 at 10:12 PM Thomas Munro wrote:
> My tentative votes are:
>
> 1. I think we should seriously consider provider = ICU63. I still
> think search-by-collversion is a little too magical, even though it
> clearly can be made to work. Of the non-magical systems, I think
> encoding
On Sat, Dec 3, 2022 at 10:57 PM Corey Huinker wrote:
> 2. ereturn_* => errfeedback / error_feedback / feedback
Oh, I like that, especially errfeedback.
--
Robert Haas
EDB: http://www.enterprisedb.com
Robert Haas writes:
> I wonder if we can't find a better solution than bunching TOC entries
> together. Perhaps we don't need every TOC entry in memory
> simultaneously, for instance, especially things like LOBs that don't
> have dependencies.
Interesting idea. We'd have to either read the TOC m
On Mon, Dec 5, 2022 at 3:42 AM Fabien COELHO wrote:
> > I had noticed that most getopt() or getopt_long() calls had their letter
> > lists in pretty crazy orders. There might have been occasional attempts
> > at grouping, but those then haven't been maintained as new options were
> > added. To re
Robert Haas writes:
> On Sat, Dec 3, 2022 at 10:57 PM Corey Huinker wrote:
>> 2. ereturn_* => errfeedback / error_feedback / feedback
> Oh, I like that, especially errfeedback.
efeedback? But TBH I do not think any of these are better than ereturn.
Whether or not you agree with my position th
Robert Haas writes:
> +1 for Peter's proposal to just alphabetize. That's easy to maintain,
> at least in theory.
Agreed for single-letter options. Long options complicate matters:
are we going to order their code stanzas by the actual long name, or
by the character/number returned by getopt? O
On Mon, Dec 5, 2022 at 10:56 AM Tom Lane wrote:
> Interesting idea. We'd have to either read the TOC multiple times,
> or shove the LOB TOC entries into a temporary file, either of which
> has downsides.
I wonder if we'd need to read the TOC entries repeatedly, or just incrementally.
I haven't
On Mon, Dec 5, 2022 at 11:09 AM Tom Lane wrote:
> Robert Haas writes:
> > On Sat, Dec 3, 2022 at 10:57 PM Corey Huinker
> > wrote:
> >> 2. ereturn_* => errfeedback / error_feedback / feedback
>
> > Oh, I like that, especially errfeedback.
>
> efeedback? But TBH I do not think any of these are
On Mon, Dec 5, 2022 at 11:14 AM Tom Lane wrote:
> Robert Haas writes:
> > +1 for Peter's proposal to just alphabetize. That's easy to maintain,
> > at least in theory.
>
> Agreed for single-letter options. Long options complicate matters:
> are we going to order their code stanzas by the actual
On 2022-12-05 Mo 11:20, Robert Haas wrote:
> On Mon, Dec 5, 2022 at 11:09 AM Tom Lane wrote:
>> Robert Haas writes:
>>> On Sat, Dec 3, 2022 at 10:57 PM Corey Huinker
>>> wrote:
2. ereturn_* => errfeedback / error_feedback / feedback
>>> Oh, I like that, especially errfeedback.
>> efeedba
Robert Haas writes:
> I was only talking about the actual argument to getopt(), not the
> order of the code stanzas. I'm not sure what we ought to do about the
> latter.
100% agreed that the getopt argument should just be alphabetical.
But the bulk of Peter's patch is rearranging switch cases to
On 12/5/22 11:36, Andrew Dunstan wrote:
On 2022-12-05 Mo 11:20, Robert Haas wrote:
On Mon, Dec 5, 2022 at 11:09 AM Tom Lane wrote:
Robert Haas writes:
On Sat, Dec 3, 2022 at 10:57 PM Corey Huinker wrote:
2. ereturn_* => errfeedback / error_feedback / feedback
Oh, I like that, especially
On Mon, Dec 5, 2022 at 11:51 AM Tom Lane wrote:
> Robert Haas writes:
> > I was only talking about the actual argument to getopt(), not the
> > order of the code stanzas. I'm not sure what we ought to do about the
> > latter.
>
> 100% agreed that the getopt argument should just be alphabetical.
>
Robert Haas writes:
> On Mon, Dec 5, 2022 at 11:09 AM Tom Lane wrote:
>> efeedback? But TBH I do not think any of these are better than ereturn.
> I do. Having a macro name that is "return" plus one character is going
> to make people think that it returns.
But it does return, or at least you
I couldn't find any discussion of the idea of adding "(s)" to the
variable name in order to mark the variable userset in the catalog, and
I have to admit I find it a bit strange. Are we really agreed that
that's the way to proceed?
--
Álvaro Herrera PostgreSQL Developer — https://www.E
Joe Conway writes:
> On 12/5/22 11:36, Andrew Dunstan wrote:
>> OK, I take both this point and Tom's about trying to keep it the same
>> length. So we need something that's 7 letters, doesn't say 'return' and
>> preferably begins with 'e'. I modestly suggest 'eseterr', or if we like
>> the 'feedba
Alvaro Herrera writes:
> I couldn't find any discussion of the idea of adding "(s)" to the
> variable name in order to mark the variable userset in the catalog, and
> I have to admit I find it a bit strange. Are we really agreed that
> that's the way to proceed?
I hadn't been paying close attent
On Mon, Dec 5, 2022 at 12:09 PM Tom Lane wrote:
> But it does return, or at least you need to code on the assumption
> that it will. (The cases where it doesn't aren't much different
> from any situation where a called subroutine unexpectedly throws
> an error. Callers typically don't have to co
I wrote:
> Nah, it's so close to ereport that it looks like a typo. eseterr isn't
> awful, perhaps. Or maybe err, but I've not thought of suitable .
... "errsave", maybe?
regards, tom lane
On Mon, Dec 05, 2022 at 01:00:19PM +, Hayato Kuroda (Fujitsu) wrote:
> But in your patch, the apply worker calcurates wakeup[LRW_WAKEUP_PING] and
> wakeup[LRW_WAKEUP_TERMINATE] again when it gets SIGHUP, so the worker never
> sends
> ping with requestReply = true, and never exits due to the ti
On Mon, Dec 5, 2022 at 12:27 PM Tom Lane wrote:
> I wrote:
> > Nah, it's so close to ereport that it looks like a typo. eseterr isn't
> > awful, perhaps. Or maybe err, but I've not thought of suitable .
>
> ... "errsave", maybe?
eseterr or errsave seem totally fine to me, FWIW.
I would
On 12/5/22 12:35, Robert Haas wrote:
On Mon, Dec 5, 2022 at 12:27 PM Tom Lane wrote:
I wrote:
> Nah, it's so close to ereport that it looks like a typo. eseterr isn't
> awful, perhaps. Or maybe err, but I've not thought of suitable .
... "errsave", maybe?
eseterr or errsave seem to
Hello,
I think this is the correct mail list for feature/modification requests.
If not please let me know which mail list I should use.
Would it be possible to modify the information_schema.view_table_usage
(VTU) to include materialized views? (
https://www.postgresql.org/docs/current/infoschema
Hi,
On 2022-12-05 15:20:55 +0900, Kyotaro Horiguchi wrote:
> The in-xact created relation t1 happened to be scanned during the
> CREATE RULE and a stats entry is attached. So the stats entry loses t1
> at roll-back, then crashes. Thus, if I understand it correctly, it
> seems to me that just unli
On Mon, 2022-12-05 at 16:12 +1300, Thomas Munro wrote:
> 1. I think we should seriously consider provider = ICU63. I still
> think search-by-collversion is a little too magical, even though it
> clearly can be made to work. Of the non-magical systems, I think
> encoding the choice of library int
On 2022-Dec-05, Tom Lane wrote:
> I wrote:
> > Nah, it's so close to ereport that it looks like a typo. eseterr isn't
> > awful, perhaps. Or maybe err, but I've not thought of suitable .
>
> ... "errsave", maybe?
IMO eseterr is quite awful while errsave is not, so here goes my vote
for
Richard Guo writes:
> The fix is straightforward, just to use outerrel->top_parent if it is
> not null and leave the reparameterization work to try_nestloop_path. In
> addition, I believe when reparameterizing MemoizePath we need to adjust
> its param_exprs too.
Right you are. I'd noticed the a
Robert Haas writes:
> AIUI, the macro never returns in the sense of using the return
> statement, unlike PG_RETURN_WHATEVER(), which do.
Oh! Now I see what you don't like about it. I thought you
meant "return to the call site", not "return to the call site's
caller". Agreed that that could be
On 12/5/22 12:41, Jeff Davis wrote:
On Mon, 2022-12-05 at 16:12 +1300, Thomas Munro wrote:
1. I think we should seriously consider provider = ICU63. I still
think search-by-collversion is a little too magical, even though it
clearly can be made to work. Of the non-magical systems, I think
enc
On Mon, Dec 5, 2022 at 12:44 PM Tom Lane wrote:
> Robert Haas writes:
> > AIUI, the macro never returns in the sense of using the return
> > statement, unlike PG_RETURN_WHATEVER(), which do.
>
> Oh! Now I see what you don't like about it. I thought you
> meant "return to the call site", not "re
On 2022-12-05 Mo 12:42, Alvaro Herrera wrote:
> On 2022-Dec-05, Tom Lane wrote:
>
>> I wrote:
>>> Nah, it's so close to ereport that it looks like a typo. eseterr isn't
>>> awful, perhaps. Or maybe err, but I've not thought of suitable .
>> ... "errsave", maybe?
> IMO eseterr is quite a
Jonathan Lemig writes:
> Would it be possible to modify the information_schema.view_table_usage
> (VTU) to include materialized views?
Is it physically possible? Sure, it'd just take adjustment of some
relkind checks.
However, it's against project policy. We consider that because the
informati
On Mon, Dec 5, 2022 at 7:57 AM Vik Fearing wrote:
> The SQL:2023 Standard defines a new aggregate named ANY_VALUE. It
> returns an implementation-dependent (i.e. non-deterministic) value from
> the rows in its group.
>
> PFA an implementation of this aggregate.
>
>
Can we please add "first_value
Andrew Dunstan writes:
> Wait a minute! Oh, no, sorry, as you were, 'errsave' is fine.
Seems like everybody's okay with errsave. I'll make a v2 in a
little bit. I'd like to try updating array_in and/or record_in
just to verify that indirection cases work okay, before we consider
the design to
"David G. Johnston" writes:
> Can we please add "first_value" and "last_value" if we are going to add
> "some_random_value" to our library of aggregates?
First and last according to what ordering? We have those in the
window-aggregate case, and I don't think we want to encourage people
to believ
On Mon, Dec 5, 2022 at 1:04 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > Can we please add "first_value" and "last_value" if we are going to add
> > "some_random_value" to our library of aggregates?
>
> First and last according to what ordering? We have those in the
> window-aggregate ca
Hi,
On 2022-12-05 22:45:57 +1300, Thomas Munro wrote:
> On Sat, Dec 3, 2022 at 10:41 AM Thomas Munro wrote:
> > Here's an iteration like that. Still WIP grade. It passes, but there
> > must be something I don't understand about this computer program yet,
> > because if I move the "if (pending_.
Hi,
On 2022-12-05 14:12:41 +0900, Michael Paquier wrote:
> With meson gaining in maturity, perhaps that's not the most urgent
> thing as we will likely remove src/tools/msvc/ soon but I'd rather do
> that right anyway as much as I can to avoid an incorrect state in the
> tree at any time in its hi
Hey Tom,
Thanks for the info. I'll submit a document change request instead.
Thanks!
Jon
On Mon, Dec 5, 2022 at 11:53 AM Tom Lane wrote:
> Jonathan Lemig writes:
> > Would it be possible to modify the information_schema.view_table_usage
> > (VTU) to include materialized views?
>
> Is it phy
Hi,
FWIW, I don't see an advantage in 0003. If it allows us to make something else
simpler / faster, cool, but on its own it doesn't seem worthwhile.
On 2022-12-02 16:31:58 -0800, Nathan Bossart wrote:
> On Fri, Dec 02, 2022 at 04:32:38PM +0530, Bharath Rupireddy wrote:
> > On Fri, Dec 2, 2022
On Fri, Dec 2, 2022 at 9:58 AM Jacob Champion wrote:
> Thanks for the nudge -- running with OpenSSL 3.0.7 in CI did not fix
> the issue. I suspect a problem with our error stack handling...
It is a problem with the error queue, but *whose* problem is probably
up for debate. The queue looks like t
Hi,
On Mon, Oct 24, 2022 at 12:45 AM Peter Smith wrote:
> Hi hackers.
>
> There is a docs Logical Replication section "31.10 Configuration
> Settings" [1] which describes some logical replication GUCs, and
> details on how they interact with each other and how to take that into
> account when se
On Mon, Dec 5, 2022 at 11:36 AM Andrew Dunstan wrote:
>
> On 2022-12-05 Mo 11:20, Robert Haas wrote:
> > On Mon, Dec 5, 2022 at 11:09 AM Tom Lane wrote:
> >> Robert Haas writes:
> >>> On Sat, Dec 3, 2022 at 10:57 PM Corey Huinker
> wrote:
> 2. ereturn_* => errfeedback / error_feedback / f
On Mon, Dec 5, 2022 at 1:00 PM Tom Lane wrote:
> Andrew Dunstan writes:
> > Wait a minute! Oh, no, sorry, as you were, 'errsave' is fine.
>
> Seems like everybody's okay with errsave. I'll make a v2 in a
> little bit. I'd like to try updating array_in and/or record_in
> just to verify that in
On Mon, Dec 5, 2022 at 12:57 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Mon, Dec 5, 2022 at 7:57 AM Vik Fearing
> wrote:
>
>> The SQL:2023 Standard defines a new aggregate named ANY_VALUE. It
>> returns an implementation-dependent (i.e. non-deterministic) value from
>> the ro
Hi,
- I think it might be worth to rename IOCONTEXT_BUFFER_POOL to
IOCONTEXT_{NORMAL, PLAIN, DEFAULT}. I'd like at some point to track WAL IO ,
temporary file IO etc, and it doesn't seem useful to define a version of
BUFFER_POOL for each of them. And it'd make it less confusing, because all
On Mon, Dec 5, 2022 at 8:18 PM Tom Lane wrote:
> Alvaro Herrera writes:
> > I couldn't find any discussion of the idea of adding "(s)" to the
> > variable name in order to mark the variable userset in the catalog, and
> > I have to admit I find it a bit strange. Are we really agreed that
> > tha
On Mon, Dec 5, 2022 at 2:31 PM Corey Huinker wrote:
> Adding to the pile of wanted aggregates: in the past I've lobbied for
> only_value() which is like first_value() but it raises an error on
> encountering a second value.
Yeah, that's another that I have hand-rolled in the past.
--
Robert H
On 2022-12-05 Mo 14:22, Corey Huinker wrote:
>
> On Mon, Dec 5, 2022 at 11:36 AM Andrew Dunstan
> wrote:
>
>
> On 2022-12-05 Mo 11:20, Robert Haas wrote:
> > On Mon, Dec 5, 2022 at 11:09 AM Tom Lane wrote:
> >> Robert Haas writes:
> >>> On Sat, Dec 3, 2022 at 10:57 PM Corey Hui
On 12/5/22 15:57, Vik Fearing wrote:
The SQL:2023 Standard defines a new aggregate named ANY_VALUE. It
returns an implementation-dependent (i.e. non-deterministic) value from
the rows in its group.
PFA an implementation of this aggregate.
Here is v2 of this patch. I had forgotten to update
Hello,
While looking into the new feature, I found the following situation with
the \dp command displaying privileges on the system tables:
GRANT VACUUM, ANALYZE ON TABLE pg_type TO alice;
SELECT relacl FROM pg_class WHERE oid = 'pg_type'::regclass;
relacl
-
On Tue, 6 Dec 2022 at 04:45, Thom Brown wrote:
> Testing your patches with the same 1024 partitions, each with 64
> sub-partitions, I get a planning time of 205.020 ms, which is now a
> 1,377x speedup. This has essentially reduced the planning time from a
> catastrophe to a complete non-issue. H
On Tue, Dec 6, 2022 at 6:45 AM Joe Conway wrote:
> On 12/5/22 12:41, Jeff Davis wrote:
> > On Mon, 2022-12-05 at 16:12 +1300, Thomas Munro wrote:
> >> 1. I think we should seriously consider provider = ICU63. I still
> >> think search-by-collversion is a little too magical, even though it
> >> c
I wrote:
> Seems like everybody's okay with errsave. I'll make a v2 in a
> little bit. I'd like to try updating array_in and/or record_in
> just to verify that indirection cases work okay, before we consider
> the design to be set.
v2 as promised, incorporating the discussed renamings as well as
On Sat, Dec 3, 2022 at 9:41 AM Andrey Borodin wrote:
> Fixed. Added test for this.
>
Thanks! Tested (gitpod:
https://gitpod.io/#https://gitlab.com/NikolayS/postgres/tree/transaction_timeout-v2
),
works as expected.
On Mon, 5 Dec 2022 at 02:34, Ankit Kumar Pandey wrote:
> Interesting problem, Hashtables created in normal aggregates (AGG_HASHED
> mode) may provide some reference as they have hashagg_spill_tuple but I
> am not sure of any prior implementation of hashtable with counter and
> spill.
I'm unsure i
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
Tested, works as expected;
documentation is not yet added
On 02.12.22 15:07, Andrew Dunstan wrote:
On 2022-12-01 Th 05:02, Peter Eisentraut wrote:
Keeping the SQL commands that initdb runs in string arrays before
feeding them to PG_CMD_PUTS() seems unnecessarily verbose and
inflexible. In some cases, the array only has one member. In other
cases, one
Hi,
On 2022-12-03 09:41:04 -0800, Andrey Borodin wrote:
> @@ -2720,6 +2723,7 @@ finish_xact_command(void)
>
> if (xact_started)
> {
> +
> CommitTransactionCommand();
>
> #ifdef MEMORY_CONTEXT_CHECKING
Spurious newline added.
> @@ -4460,6 +4473,10 @@ PostgresMain(c
On Mon, Dec 05, 2022 at 10:14:49AM -0800, Andres Freund wrote:
> On 2022-12-05 14:12:41 +0900, Michael Paquier wrote:
>> With meson gaining in maturity, perhaps that's not the most urgent
>> thing as we will likely remove src/tools/msvc/ soon but I'd rather do
>> that right anyway as much as I can
Thanks for looking into this Andres!
On Mon, Dec 5, 2022 at 3:07 PM Andres Freund wrote:
>
> I'm a bit worried about adding evermore branches and function calls for
> the processing of single statements. We already spend a noticable
> percentage of the cycles for a single statement in PostgresMai
Hi,
On 2022-12-05 16:40:06 -0500, Tom Lane wrote:
> +/*
> + * errsave_start --- begin a "safe" error-reporting cycle
> + *
> + * If "context" isn't an ErrorSaveContext node, this behaves as
> + * errstart(ERROR, domain), and the errsave() macro ends up acting
> + * exactly like ereport(ERROR, ...)
Hi,
On 2022-12-06 08:31:16 +0900, Michael Paquier wrote:
> On Mon, Dec 05, 2022 at 10:14:49AM -0800, Andres Freund wrote:
> > On 2022-12-05 14:12:41 +0900, Michael Paquier wrote:
> >> With meson gaining in maturity, perhaps that's not the most urgent
> >> thing as we will likely remove src/tools/m
Here are my review comments for patch v55-0002
==
.../replication/logical/applyparallelworker.c
1. pa_can_start
@@ -276,9 +278,9 @@ pa_can_start(TransactionId xid)
/*
* Don't start a new parallel worker if user has set skiplsn as it's
* possible that user want to skip the streaming tr
1 - 100 of 145 matches
Mail list logo
