On Mon, Dec 5, 2022 at 9:59 AM houzj.f...@fujitsu.com
wrote:
>
> Attach a new version patch set which fixed a testcase failure on CFbot.
>
Few comments:
1.
+ /*
+ * Break the loop if the parallel apply worker has finished applying
+ * the transaction. The parallel apply worker
On Sat, Dec 3, 2022 at 12:45 AM Nathan Bossart wrote:
>
> On Fri, Dec 02, 2022 at 12:11:35PM +0530, Bharath Rupireddy wrote:
> > On Fri, Dec 2, 2022 at 3:10 AM Nathan Bossart
> > wrote:
> >> The test appears to reliably create snapshot and mapping files, so if the
> >> directories are empty at
At Mon, 5 Dec 2022 13:13:23 +0900, Michael Paquier wrote
in
> 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
> >
On Tue, Dec 6, 2022 at 8:15 AM Michael Paquier wrote:
>
> On Mon, Dec 05, 2022 at 05:16:56PM +0900, Michael Paquier wrote:
> > Doing that in a separate patch is fine by me.
>
> I have applied the patch for the tab entries, then could not resist
> poking at the parts for the db entries. This
John Naylor writes:
> Here's a quick go at that. I've not attempted to use it for what I need,
> but it looks like it fits the bill.
Passes a quick eyeball check, but of course we should have a
concrete external use for the new pg_bitutils functions.
regards, tom lane
On Mon, Dec 5, 2022 6:57 PM Amit Kapila wrote:
>
> On Mon, Dec 5, 2022 at 3:41 PM Dilip Kumar wrote:
> >
> > I think we need something like this[1] so that we can better control
> > the streaming.
> >
>
> +1. The additional advantage would be that we can generate parallel
> apply and new
Hi hackers,
In logical decoding, when logical_decoding_work_mem is exceeded, the changes are
sent to output plugin in streaming mode. But there is a restriction that the
minimum value of logical_decoding_work_mem is 64kB. I tried to add a GUC to
allow sending every change to output plugin without
On Tue, Dec 6, 2022 at 12:57 PM Tom Lane wrote:
> > Well, they've already escaped to tidbitmap.c as a copy. How do you feel
> > about going that route?
>
> Not terribly pleased with that either, I must admit.
Okay, I won't pursue that further.
> If we do put RIGHTMOST_ONE functionality into
David Rowley writes:
> Maybe there's a path of lesser resistance... There's been a bit of
> work in pg_bitutils.h to define some of the bit manipulation functions
> for size_t types which wrap the 32 or 64-bit version of the function
> accordingly. Couldn't we just define one of those for
>
On Tue, 6 Dec 2022 at 17:57, Tom Lane wrote:
> And RIGHTMOST_ONE is something that could be made public, but
> I think it belongs in pg_bitutils.h, perhaps with a different
> name.
Maybe there's a path of lesser resistance... There's been a bit of
work in pg_bitutils.h to define some of the bit
On 12/6/22 05:57, David G. Johnston wrote:
On Mon, Dec 5, 2022 at 9:48 PM Vik Fearing wrote:
I can imagine an optimization that would remove an ORDER BY clause
because it isn't needed for any other aggregate.
I'm referring to the query:
select any_value(v order by v) from (values
Hi,
On 12/6/22 3:45 AM, Michael Paquier wrote:
On Mon, Dec 05, 2022 at 05:16:56PM +0900, Michael Paquier wrote:
Doing that in a separate patch is fine by me.
I have applied the patch for the tab entries,
Oops, I missed this part when reading the email the first time and just saw the
patch
John Naylor writes:
> On Mon, Dec 5, 2022 at 9:33 PM Tom Lane wrote:
>> IMV these are absolutely private to bitmapset.c. I reject the idea
>> that they should be exposed publicly, under these names or any others.
> Well, they've already escaped to tidbitmap.c as a copy. How do you feel
> about
On Mon, Dec 5, 2022 at 9:48 PM Vik Fearing wrote:
> On 12/6/22 05:22, David G. Johnston wrote:
> > On Mon, Dec 5, 2022 at 8:46 PM Vik Fearing
> wrote:
> >
> >> On 12/5/22 18:56, David G. Johnston wrote:
> >>> Also, maybe we should have any_value do something like compute a 50/50
> >>> chance
On 12/6/22 05:22, David G. Johnston wrote:
On Mon, Dec 5, 2022 at 8:46 PM Vik Fearing wrote:
On 12/5/22 18:56, David G. Johnston wrote:
Also, maybe we should have any_value do something like compute a 50/50
chance that any new value seen replaces the existing chosen value,
instead
of
Hi,
On 12/6/22 3:45 AM, Michael Paquier wrote:
On Mon, Dec 05, 2022 at 05:16:56PM +0900, Michael Paquier wrote:
Doing that in a separate patch is fine by me.
I have applied the patch for the tab entries, then could not resist
poking at the parts for the db entries. This leads to more
On Mon, Dec 5, 2022 at 8:46 PM Vik Fearing wrote:
> On 12/5/22 18:56, David G. Johnston wrote:
> > Also, maybe we should have any_value do something like compute a 50/50
> > chance that any new value seen replaces the existing chosen value,
> instead
> > of simply returning the first value all
On Mon, Dec 5, 2022 at 9:33 PM Tom Lane wrote:
>
> 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
On Mon, 5 Dec 2022 at 22:52, Vik Fearing wrote:
> On 12/5/22 20:31, 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.
>
> I have had use for
On Tue, Dec 06, 2022 at 11:45:10AM +0900, Michael Paquier wrote:
> I have applied the patch for the tab entries, then could not resist
> poking at the parts for the db entries. This leads to more reduction
> than the other one actually, as of:
> 4 files changed, 169 insertions(+), 447
On 12/5/22 20:31, 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.
I have had use for this in the past, but I can't remember why. What is
your use case
On Tue, Dec 6, 2022 at 5:27 AM Peter Smith wrote:
>
> Here are my review comments for patch v55-0002
>
...
>
> 3. pa_spooled_messages
>
> Previously I suggested this function name should be changed but that
> was rejected (see [1] #6a)
>
> > 6a.
> > IMO a better name for this function would be
>
On 12/5/22 18:56, David G. Johnston wrote:
Also, maybe we should have any_value do something like compute a 50/50
chance that any new value seen replaces the existing chosen value, instead
of simply returning the first value all the time. Maybe even prohibit the
first value from being chosen so
Hi,
Thank you for updating the patch!
On Tue, Nov 29, 2022 at 8:57 AM Imseih (AWS), Sami wrote:
>
> > I think that indexes_total should be 0 also when INDEX_CLEANUP is off.
>
> Patch updated for handling of INDEX_CLEANUP = off, with an update to
> the documentation as well.
>
> >I think
On Mon, Dec 05, 2022 at 05:16:56PM +0900, Michael Paquier wrote:
> Doing that in a separate patch is fine by me.
I have applied the patch for the tab entries, then could not resist
poking at the parts for the db entries. This leads to more reduction
than the other one actually, as of:
4 files
Andres Freund writes:
> This in turn make me look at record_in() in 0002 - I think we might be leaking
> a tupledesc refcount in case of errors. Yup:
Doh :-( ... I did that function a little too hastily, obviously.
Thanks for catching that.
regards, tom lane
Hi,
On 2022-12-05 20:19:26 -0500, Tom Lane wrote:
> That seems like kind of a problematic requirement, unless we leave some
> datatype around that's intentionally not ever going to be converted. For
> datatypes that we do convert, there shouldn't be any easy way to get to a
> hard error.
I
On Tue, Dec 6, 2022 at 1:42 AM Tom Lane wrote:
> One small problem is that top_parent doesn't exist in the back branches,
> so I had to substitute a much uglier lookup in order to make this work
> there. I'm surprised that we got away without top_parent for this long
> TBH, but anyway this fix
Andres Freund writes:
> On 2022-12-05 20:06:55 -0500, Tom Lane wrote:
>> Hmm, either I'm confused or you're stating that backwards --- aren't
>> the hard-error code paths already tested by our existing tests?
> What I'd like to test is a hard error, either due to an input function
> that wasn't
Hi,
On 2022-12-05 20:06:55 -0500, Tom Lane wrote:
> >> I wasn't trying all that hard on the error tests, because I think
> >> 0003 is just throwaway code at this point.
>
> > I am mainly interested in having *something* test erroring out hard when
> > using the "Safe" mechanism, which afaict we
Hi,
On 2022-12-06 09:44:01 +0900, Kyotaro Horiguchi wrote:
> At Mon, 5 Dec 2022 15:07:47 -0800, Andres Freund wrote in
> > 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
Andres Freund writes:
> On 2022-12-05 19:18:11 -0500, Tom Lane wrote:
>> but I'm not sure that's much of an improvement. Note that it'd
>> *not* be correct to declare it as anything more specific than Node*,
>> since the fmgr context pointer is Node* and we're not expecting
>> callers to do
2022年12月5日(月) 11:25 Michael Paquier :
>
> 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
Hi,
On 2022-12-05 19:18:11 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Why is context a void *?
>
> elog.h can't depend on nodes.h, at least not without some rather
> fundamental rethinking of our #include relationships. We could
> possibly use the same kind of hack that fmgr.h does:
>
>
2022年12月5日(月) 18:56 Alvaro Herrera :
>
> 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
At Mon, 5 Dec 2022 15:07:47 -0800, Andres Freund wrote in
> 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 PostgresMain(), this
> adds additional
Thank you!
Sadly I didn't manage how to reproduce that locally. check-world doesn't seem
to fail at my end.
That being said, attached patch should fix the issue reported below.
I'll have another look at the log later this week.
Regards
Arne
From: Andres
On Fri, Dec 2, 2022 at 6:18 PM Alexander Korotkov wrote:
> On Mon, Nov 28, 2022 at 1:30 PM Aleksander Alekseev
> wrote:
> > Thanks for the feedback!
> >
> > > I think it's a nice catch and worth fixing. The one thing I don't
> > > agree with is using asserts for handling the error that can
On Mon, Dec 05, 2022 at 12:48:28PM +, gkokola...@pm.me wrote:
> I also took the liberty of applying the test pattern when it the dump
> is explicitly compressed.
Sticking with glob_patterns is fine by me.
> I was thinking a bit more about this. I think that we can use the list
> TOC option
Hi,
On 2022-12-05 15:41:29 -0800, Andrey Borodin wrote:
> 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
Andres Freund writes:
> Why is context a void *?
elog.h can't depend on nodes.h, at least not without some rather
fundamental rethinking of our #include relationships. We could
possibly use the same kind of hack that fmgr.h does:
typedef struct Node *fmNodePtr;
but I'm not sure that's much of
On Mon, Dec 05, 2022 at 03:48:45PM -0800, Andres Freund wrote:
> Yes, that's a typo. I meant that we shouldn't add arm64 support to
> src/tools/msvc/.
Okay, thanks.
> I do think we should rip out src/tools/msvc/ soon-ish, but we need
> buildfarm support first.
Sure, let's see where it goes.
--
2022年12月5日(月) 23:59 Robert Haas :
>
> 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
Jacob,
Thanks for your feedback.
I think we can focus on the roles and responsibilities of the components first.
Details of the patch can be elaborated. Like "flow type code" is a
mistake on our side, and we will use the term "grant_type" which is
defined by OIDC spec. As well as details of usage
On Mon, Dec 05, 2022 at 11:21:08PM +0300, Pavel Luzanov wrote:
> But perhaps this behavior should be reviewed or at least documented?
I wonder why \dpS wasn't added. I wrote up a patch to add it and the
corresponding documentation that other meta-commands already have.
--
Nathan Bossart
Amazon
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
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
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,
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
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
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 @@
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,
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 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
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.
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
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
> >>
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.
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 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
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
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
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
> >
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 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
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
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 /
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
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
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,
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
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,
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
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
"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
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
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
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
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
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
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
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
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
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
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
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
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? (
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
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
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
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 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
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
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
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 —
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
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.
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
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 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.
>>
1 - 100 of 145 matches
Mail list logo
