On Thu, Jan 12, 2023 at 10:17:21AM -0800, Nathan Bossart wrote:
> On Thu, Jan 12, 2023 at 03:30:40PM +0900, Michael Paquier wrote:
> IMHO I don't think there's an urgent need to rename it, but if there's a
> better name that people like, I'm happy to do so.
Okay.
>> Saying that, 0001 seems fine
HI,
On Jan 16, 2023, 00:10 +0800, Nathan Bossart , wrote:
> On Mon, Jan 16, 2023 at 12:04:56AM +0800, Zhang Mingli wrote:
> > So, they are all dead codes, provide a patch to remove them.
>
> I am proposing a new use of dsa_create, dsa_attach, and dsa_get_handle in
>
On Mon, Jan 16, 2023 at 10:24 AM Peter Smith wrote:
>
> 2.
>
> /*
> + * Return the pid of the leader apply worker if the given pid is the pid of a
> + * parallel apply worker, otherwise return InvalidPid.
> + */
> +pid_t
> +GetLeaderApplyWorkerPid(pid_t pid)
> +{
> + int leader_pid = InvalidPid;
On Sunday, January 15, 2023, 金 wrote:
>
> postgres=# \df fun1
>
> List of functions
>
> Schema | Name | Result data type |Argument data types
> | Type
>
> +--+--+-
>
I wrote:
> ...but arguably the earlier check is close enough that it's silly to
assert in the "else" branch, and I'd be okay with just nuking those lines.
Another thing that caught my attention is the assumption that unsetting a
bit is so expensive that we have to first check if it's set, so we
Hi,
I find if there are more than one functions in different schemas,
and the functions have the same name and the same arguments,
\df[+] only display the function that schema earlier appeared in the
search_path.
And SELECT pg_function_is_visible(funoid) returns f.
Because in
On Sun, Jan 15, 2023 at 10:39 PM Tomas Vondra
wrote:
>
> I think there's a bug in how get_transaction_apply_action() interacts
> with handle_streamed_transaction() to decide whether the transaction is
> streamed or not. Originally, the code was simply:
>
> /* not in streaming mode */
> if
ne 15. 1. 2023 v 7:32 odesílatel Pavel Stehule
napsal:
> Hi
>
>
>> On Thu, Jan 12, 2023 at 9:51 AM Pavel Stehule
>> wrote:
>>
>>> Hi
>>>
>>> I checked this patch and it looks well. All tests passed. Together with
>>> https://commitfest.postgresql.org/41/4013/ it can be a good feature.
>>>
>>> I
On 16/01/23 09:48, David Rowley wrote:
I don't think we should touch this. It could significantly increase
the number of indexes that we consider when generating paths on base
relations and therefore *significantly* increase the number of paths
we consider during the join search. What I had
On Fri, Jan 13, 2023 at 09:19:10AM +0100, Jelte Fennema wrote:
>> Even if folks applying quotes
>> would not be able anymore to replace the pattern, the risk seems a bit
>> remote?
>
> Yeah I agree the risk is remote. To be clear, the main pattern I'm
> worried about breaking is simply "\1".
On Mon, Jan 9, 2023 at 7:16 AM Peter Geoghegan wrote:
>
> On Tue, Jan 3, 2023 at 12:30 PM Peter Geoghegan wrote:
> > Attached is v14.
>
> This has stopped applying due to conflicts with nearby work on VACUUM
> from Tom. So I attached a new revision, v15, just to make CFTester
> green again.
>
>
Here are some review comments for v81-0001.
==
Commit Message
1.
Additionally, update the leader_pid column in pg_stat_activity as well to
display the PID of the leader apply worker for parallel apply workers.
~
Probably it should not say both "Additionally" and "as well" in the
same
On Mon, 16 Jan 2023 at 06:52, Ankit Kumar Pandey wrote:
> Hence, input_rel->pathlist returns null for select distinct b,a from ab
> where a < 10; even if index is created on a.
>
> In order to tackle this, I have added index_pathkeys in indexpath node
> itself.
I don't think we should touch
On Sun, 15 Jan 2023 at 09:39, Ajin Cherian wrote:
>
> On Fri, Jan 13, 2023 at 5:33 PM vignesh C wrote:
> > Adding support for CREATE/ALTER/DROP Publication ddl deparsing.
> > The attached v61 patch has the changes for the same.
> >
>
> Hi Vignesh,
> this doesn't seem to compile:
>
> gcc
At Tue, 10 Jan 2023 12:01:43 +0530, Amit Kapila wrote
in
> On Tue, Jan 10, 2023 at 11:16 AM Kyotaro Horiguchi
> wrote:
> > Although I don't see a technical difference between the two, all the
> > other occurances including the just above (except test_shm_mq) use
> > "could not". A faint memory
On Sun, Jan 15, 2023 at 07:56:25PM -0600, Justin Pryzby wrote:
> On Mon, Jan 16, 2023 at 10:28:50AM +0900, Michael Paquier wrote:
>> The functions changed by 0001 are cfopen[_write](),
>> AllocateCompressor() and ReadDataFromArchive(). Why is it a good idea
>> to change these interfaces which
On Fri, Dec 23, 2022 at 4:33 PM John Naylor
wrote:
>
>
>
> On Thu, Dec 22, 2022 at 10:00 PM Masahiko Sawada
> wrote:
>
> > If the value is a power of 2, it seems to work perfectly fine. But for
> > example if it's 700MB, the total memory exceeds the limit:
> >
> > 2*(1+2+4+8+16+32+64+128) =
On Mon, Jan 16, 2023 at 02:27:56AM +, gkokola...@pm.me wrote:
> Oh, I didn’t realize you took over Justin? Why? After almost a year of work?
>
> This is rather disheartening.
I believe you've misunderstood my intent here. I sent rebased versions
of your patches with fixup commits
On Mon, Jan 16, 2023 at 10:52:43AM +0900, Kyotaro Horiguchi wrote:
> Yeah, we could do that. But as I mentioned before, that happens only
> on startup thus it can be said that that's not worth bothering. On
> the other hand I don't think it's great to waste 16kB * max_backends
> memory especially
Hi,
On 2023-01-13 11:55:47 -0800, Andres Freund wrote:
> Does anybody see a reason to not move forward with this aspect? We do a fair
> amount of INSTR_TIME_ACCUM_DIFF() etc, and that gets a good bit cheaper by
> just using nanoseconds. We'd also save memory in BufferUsage (144-122 bytes),
>
On Sat, Jan 14, 2023 at 07:10:55PM +0530, Nitin Jadhav wrote:
> Option-1 is, expose a function like pg_settings_get_no_show_all()
> which just returns the parameters which are just listed as
> GUC_NO_SHOW_ALL (Not in combination with NOT_IN_SAMPLE). We can then
> use this function in the test file
Oh, I didn’t realize you took over Justin? Why? After almost a year of work?
This is rather disheartening.
On Mon, Jan 16, 2023 at 02:56, Justin Pryzby wrote:
> On Mon, Jan 16, 2023 at 10:28:50AM +0900, Michael Paquier wrote:
>> On Sat, Jan 14, 2023 at 03:43:09PM -0600, Justin Pryzby wrote:
>>
On Mon, Jan 16, 2023 at 10:28:50AM +0900, Michael Paquier wrote:
> On Sat, Jan 14, 2023 at 03:43:09PM -0600, Justin Pryzby wrote:
> > On Sun, Jan 08, 2023 at 01:45:25PM -0600, Justin Pryzby wrote:
> >> pg_compress_specification is being passed by value, but I think it
> >> should be passed as a
On Sun, Jan 15, 2023 at 08:13:28AM -0800, Nathan Bossart wrote:
> On Sun, Jan 15, 2023 at 08:23:13AM -0500, Andrew Dunstan wrote:
>> On 2023-01-14 Sa 18:11, Nathan Bossart wrote:
>>> I've attached a patch for $SUBJECT, which allows us to remove a use of the
>>> unconstify macro in basic_archive.
At Thu, 12 Jan 2023 15:02:25 +0530, Bharath Rupireddy
wrote in
> On the contrary, PGAlignedBlock is being used elsewhere in the code;
I noticed it and had the same feeling, and thought that they don't
justify to do the same at other places.
> some of them are hot paths.
At Fri, 13 Jan 2023 16:41:08 +0530, Amit Kapila wrote
in
> Okay, but what happens in the case of physical replication when
> synchronous_commit = remote_apply? In that case, won't it ensure that
> apply has also happened? If so, then shouldn't the time delay feature
> also cause a similar
On Sat, Jan 14, 2023 at 03:43:09PM -0600, Justin Pryzby wrote:
> On Sun, Jan 08, 2023 at 01:45:25PM -0600, Justin Pryzby wrote:
>> pg_compress_specification is being passed by value, but I think it
>> should be passed as a pointer, as is done everywhere else.
>
> ISTM that was an issue with
At Wed, 28 Dec 2022 09:15:41 +, "Hayato Kuroda (Fujitsu)"
wrote in
> > Another thing we can investigate here why do we need to ensure that
> > there is no pending send before shutdown.
>
> I have not done yet about it, will continue next year.
> It seems that walsenders have been sending
On Sun, 15 Jan 2023 18:01:50 -0600
"Karl O. Pinc" wrote:
> Regards XSLT:
>
> I believe the XSLT needs work.
I also think that the XSLT should error and halt
when there's no id (in the expected places).
Instead of just giving a warning and keeping going. Otherwise
they'll constantly be
Hi Brar,
Here's my first review of the make_html_ids_discoverable.patch.
Overall:
To start with, I'd like to say I like the goal and how everything
works when the patch is applied. I was a bit skeptical, thinking that
the whole thing was going to be distracting when reading the docs or
On Sun, Jan 15, 2023 at 06:02:07PM -0500, Tom Lane wrote:
> I guess, but it seems like make-work as long as there's just the one
> column.
Well, the query is already written, so I would use that, FWIW.
> I did find that 002_pg_upgrade.pl could load it. I got stuck at
> the point of trying to
Andrew Dunstan writes:
> Those replacement lines are very difficult to read. I think use of
> extended regexes and some multi-part replacements would help. I'll have
> a go at that tomorrow.
Yeah, after I wrote that code I remembered about \Q ... \E, which would
eliminate the need for most of
On 2023-01-15 Su 11:01, Tom Lane wrote:
> Another thing I was just thinking about was not bothering to run
> "diff" if the fixed dump strings are equal in-memory. You could
> take that even further and not write out the fixed files at all,
> but that seems like a bad idea for debuggability of
Michael Paquier writes:
> On Sat, Jan 14, 2023 at 03:06:06PM -0500, Tom Lane wrote:
> + # Can't upgrade aclitem in user tables from pre 16 to 16+.
> + _add_st($result, 'regression',
> + 'alter table public.tab_core_types drop column aclitem');
> Could you just use a DO
On Sat, Jan 14, 2023 at 03:06:06PM -0500, Tom Lane wrote:
> I tried to use this to replace upgrade_adapt.sql, but failed so
> far because I couldn't figure out exactly how you're supposed
> to use 002_pg_upgrade.pl with an old source installation.
> It's not terribly well documented.
As in
This is a test. Please ignore...
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
Andres Freund writes:
> WFM, just wanted to be sure we thought about the errors it could cause. I'm
> not sure we've exercised cases of tuples being too wide due to variable-width
> plain storage types exhaustively. There's only a small number of these types:
> int2vector, oidvector, gtsvector,
Hi,
On 2023-01-15 15:53:09 -0500, Tom Lane wrote:
> Andres Freund writes:
> > For the purpose here a limit of MaxTupleAttributeNumber or such instead of
> > FUNC_MAX_ARGS would do the trick, I think?
>
> As long as we have to change the code, we might as well remove the
> arbitrary restriction.
Andres Freund writes:
> For the purpose here a limit of MaxTupleAttributeNumber or such instead of
> FUNC_MAX_ARGS would do the trick, I think?
As long as we have to change the code, we might as well remove the
arbitrary restriction.
> Should this be repalloc0? I don't know if the palloc0 above
I wrote:
> BTW, fd0b9dceb is in v15, so are you sure this doesn't fail in 15?
Ah-hah: simple test cases only fail since b7ae03953. Before
that, the default situation was that pg_publication_rel.prattrs
was null and that would be passed on as the transmitted value.
b7ae03953 decided it'd be cool
Hi,
On 2023-01-15 15:17:16 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-01-15 14:39:41 -0500, Tom Lane wrote:
> >> But I suppose we are stuck with that, seeing that this datatype choice
> >> is effectively part of the logrep protocol now. I think the only
> >> reasonable solution
Hi,
On 2023-01-13 09:11:06 +0100, David Geier wrote:
> Mostly I'm wondering if the sampling based approach gains us enough to be
> worth it, once the patch to use RDTSC hopefully landed (see [1]).
Well, I'm not sure we have a path forward on it. There's portability and
accuracy concerns. But
Andres Freund writes:
> On 2023-01-15 14:39:41 -0500, Tom Lane wrote:
>> But I suppose we are stuck with that, seeing that this datatype choice
>> is effectively part of the logrep protocol now. I think the only
>> reasonable solution is to get rid of the FUNC_MAX_ARGS restriction
>> in
More information on the latest patch.
1. We aligned the implementation with the barebone SASL for OAUTH
described here - https://www.rfc-editor.org/rfc/rfc7628
The flow can be explained in the diagram below:
+--+ +--+
|
Hi,
On 2023-01-15 14:39:41 -0500, Tom Lane wrote:
> It looks like the proximate cause is that fd0b9dceb started fetching
> the remote's pg_get_publication_tables() result as-is rather than
> unnesting it, so that the on-the-wire representation is now int2vector
> not a series of int2. However,
I wrote:
> Alvaro Herrera writes:
>> At the same time, I don't understand why it fails in 16 but not in 15.
>> Maybe something changed in the way we process the column lists in 16?
> Probably didn't have a dependency on int2vector before.
It looks like the proximate cause is that fd0b9dceb
On 11/21/22 17:35, Joe Conway wrote:
On 11/21/22 15:57, Ted Toth wrote:
In SELinux file context files you can specify <> for a file
meaning you don't want restorecon to relabel it. <> is
especially useful in an SELinux MLS environment when objects are
created at a specific security level and
Justin Pryzby writes:
> On Sun, Jan 15, 2023 at 01:25:11PM -0500, Tom Lane wrote:
>> v15? That assert is from 8bf6ec3ba, which wasn't back-patched.
> The assert isn't from 8bf6 (Improve handling of inherited GENERATED
> expressions.), but rather:
> commit
On Sun, Jan 15, 2023 at 01:25:11PM -0500, Tom Lane wrote:
> Justin Pryzby writes:
> > On Thu, Jan 12, 2023 at 01:23:57PM +0300, v.davy...@postgrespro.ru wrote:
> >> TRAP: FailedAssertion("relinfo->ri_GeneratedExprs != NULL", File:
> >> "execUtils.c", Line: 1292)
>
> > Yeah, confirmed under
Justin Pryzby writes:
> On Thu, Jan 12, 2023 at 01:23:57PM +0300, v.davy...@postgrespro.ru wrote:
>> TRAP: FailedAssertion("relinfo->ri_GeneratedExprs != NULL", File:
>> "execUtils.c", Line: 1292)
> Yeah, confirmed under master branch and v15.
v15? That assert is from 8bf6ec3ba, which wasn't
On 13/01/23 07:48, David Rowley wrote:
It would just care if the
pathkeys were present and return a list of pathkeys not contained so
that an incremental sort could be done only on the returned list and a
Unique on an empty returned list.
In create_final_distinct_paths, presorted keys are
On Sun, 8 Jan 2023 at 21:00, vignesh C wrote:
>
> On Tue, 3 Jan 2023 at 13:13, vignesh C wrote:
> >
> > Hi All,
> >
> > Just a reminder that Commitfest 2023-01 has started.
> > There are many patches based on the latest run from [1] which require
> > a) Rebased on top of head b) Fix compilation
Hi,
I think there's a bug in how get_transaction_apply_action() interacts
with handle_streamed_transaction() to decide whether the transaction is
streamed or not. Originally, the code was simply:
/* not in streaming mode */
if (!in_streamed_transaction)
return false;
But now
Hi
Thanks for noticing. Similarly to the previous issue, the order of
> columns was incorrect -- deform counters have to be the last columns in
> the view.
>
I tested it and now looks well
check-world passed
make doc passed
I mark this patch as ready for committer
Regards
Pavel
On Sat, Jan 14, 2023 at 4:22 PM Joseph Koshakow wrote:
>
> At this point the patch is ready for review again except for the one
> outstanding question of: Should finite checks on intervals only look at
> months or all three fields?
>
> - Joe
I've gone ahead and updated the patch to only look at
Justin Pryzby writes:
> Yeah, confirmed under master branch and v15.
> Tom ?
Yeah, sorry, I've been absorbed in $other_stuff. Will look
at this soon. My guess is that this logrep code path is
missing the necessary setup operation.
regards, tom lane
On Thu, Jan 12, 2023 at 01:23:57PM +0300, v.davy...@postgrespro.ru wrote:
> Dear all,
>
> I think I've found a problem in logical replication that was introduced
> recently in the patch:
>
> Fix calculation of which GENERATED columns need to be updated
>
On Sun, Jan 15, 2023 at 08:23:13AM -0500, Andrew Dunstan wrote:
> On 2023-01-14 Sa 18:11, Nathan Bossart wrote:
>> I've attached a patch for $SUBJECT, which allows us to remove a use of the
>> unconstify macro in basic_archive. This is just a pet peeve, but maybe it
>> bothers others, too.
>
> I
On Mon, Jan 16, 2023 at 12:04:56AM +0800, Zhang Mingli wrote:
> So, they are all dead codes, provide a patch to remove them.
I am proposing a new use of dsa_create, dsa_attach, and dsa_get_handle in
https://commitfest.postgresql.org/41/4020/. These might also be useful for
extensions, so IMHO we
Alvaro Herrera writes:
> On 2023-Jan-15, Erik Rijkers wrote:
>> Logical replication sometimes gets stuck with
>> ERROR: int2vector has too many elements
> Weird. This error comes from int2vectorin which amusingly only wants to
> read up to FUNC_MAX_ARGS values in the array (100 in the default
HI,
On Jan 15, 2023, 23:43 +0800, Zhang Mingli , wrote:
> Hi, hackers
>
> Found some functions in dsa.c are not used anymore.
>
> dsa_create
> dsa_attach
> dsa_get_handle
> dsa_trim
> dsa_dump
>
> We once used dsa_create to create DSA and it ’s all replaced by
> dsa_create_in_place since
Andrew Dunstan writes:
> On 2023-01-14 Sa 15:06, Tom Lane wrote:
>> Here's version 2, incorporating your suggestions and with some
>> further work to make it handle 9.2 fully.
> This looks pretty good to me.
Great! I'll work on making back-branch versions.
> I'll probably change this line
>
Hi, hackers
Found some functions in dsa.c are not used anymore.
dsa_create
dsa_attach
dsa_get_handle
dsa_trim
dsa_dump
We once used dsa_create to create DSA and it ’s all replaced by
dsa_create_in_place since commit 31ae1638ce.
dsa_attach and dsa_get_handle cooperate with dsa_create.
On Sunday, January 15, 2023 5:35 PM Erik Rijkers wrote:
>
> I can't find the exact circumstances that cause it but it has something to do
> with
> many columns (or adding many columns) in combination with perhaps
> generated columns.
>
> This replication test, in a slightly different form,
> On Sun, Jan 08, 2023 at 09:06:33PM +0100, Pavel Stehule wrote:
> It is working although I am not sure if it is correctly
>
> when I run EXPLAIN ANALYZE for query `explain analyze select
> count(length(prosrc) > 0) from pg_proc;`
>
> I got plan and times
>
>
On Sun, 15 Jan 2023 07:11:30 +0100
Brar Piening wrote:
> On 03.01.2023 at 01:00, Karl O. Pinc wrote:
> > Attached is a patch: contrib_v1.patch
> >
> > It modifies Appendix F, the contrib directory.
>
> Review:
> It adds a brief explanatory part to the headers of all contrib modules
> The
On 2023-01-14 Sa 18:11, Nathan Bossart wrote:
> I've attached a patch for $SUBJECT, which allows us to remove a use of the
> unconstify macro in basic_archive. This is just a pet peeve, but maybe it
> bothers others, too.
I don't like using unconstify where it can be avoided, so this looks
On 2023-01-14 Sa 15:06, Tom Lane wrote:
> I wrote:
>> OK, I'll take a look at that and make a new draft.
> Here's version 2, incorporating your suggestions and with some
> further work to make it handle 9.2 fully. I think this could
> be committable so far as HEAD is concerned, though I still
>
On 1/15/23 12:33, Alvaro Herrera wrote:
On 2023-Jan-15, Erik Rijkers wrote:
Hello,
Logical replication sometimes gets stuck with
ERROR: int2vector has too many elements
Weird. This error comes from int2vectorin which amusingly only wants to
read up to FUNC_MAX_ARGS values in the array
On 2023-Jan-15, Erik Rijkers wrote:
> Hello,
>
> Logical replication sometimes gets stuck with
> ERROR: int2vector has too many elements
Weird. This error comes from int2vectorin which amusingly only wants to
read up to FUNC_MAX_ARGS values in the array (100 in the default config,
but it
Hello,
Logical replication sometimes gets stuck with
ERROR: int2vector has too many elements
I can't find the exact circumstances that cause it but it has something
to do with many columns (or adding many columns) in combination with
perhaps generated columns.
This replication test, in a
71 matches
Mail list logo
