On Thu, Mar 31, 2022 at 5:01 PM Michael Paquier wrote:
> On Wed, Mar 30, 2022 at 08:23:25PM +1300, Thomas Munro wrote:
> > That leads to the attached patches, the first of which I'd want to
> > back-patch.
>
> Makes sense.
> ...
> This should also work for plain files, so that looks fine to me.
On Fri, Jul 22, 2022 at 1:13 PM David Rowley wrote:
> On Fri, 22 Jul 2022 at 15:22, Amit Langote wrote:
> > BTW, the only way I found to *forcefully* exercise llvm_compile_expr()
> > is to add `set jit_above_cost to 0` at the top of the test file, or
> > are we missing a force_jit_mode, like
On Fri, Jul 22, 2022 at 3:47 AM Peter Smith wrote:
>
> I was in favour of enum mostly because I thought the bitmask of an
> earlier patch was mis-used; IMO each bit should only be for
> representing something as "on/set". So a bit for
> SUBSCRIPTION_REL_STATE_READY makes sense, but a bit for
>
On Fri, Jul 22, 2022 at 7:39 AM Kyotaro Horiguchi
wrote:
>
> +errmsg("cannot operate on relation \"%s\"",
>
> Other callers of errdetail_relkind_not_supported() describing
> operations concretely. In that sense we I think should say "cannot
> open relation \"%s\""
On Fri, Jul 22, 2022 at 1:39 AM Jonathan S. Katz wrote:
>
> Thanks for the work on this feature -- this is definitely very helpful
> towards supporting more types of use cases with logical replication!
>
> I've read through the proposed documentation and did some light testing
> of the patch. I
On Thu, Jun 30, 2022 at 8:21 PM Heikki Linnakangas wrote:
> I ran sparc64-ext4-zeros on chipmunk for 10 minutes, and it didn't print
> anything.
Thanks for checking.
> It's possible that the SD card on chipmunk is simply wearing out and
> flipping bits. I can try to replace it. Anyone have
On Fri, 22 Jul 2022 at 15:22, Amit Langote wrote:
> BTW, the only way I found to *forcefully* exercise llvm_compile_expr()
> is to add `set jit_above_cost to 0` at the top of the test file, or
> are we missing a force_jit_mode, like there is force_parallel_mode?
I don't think we'd need any
On Thu, 4 Nov 2021 at 20:59, Ronan Dunklau wrote:
> I took some time to toy with this again.
>
> At first I thought that charging a discount in foreign grouping paths for
> Aggref targets (since they are computed remotely) would be a good idea,
> similar to what is done for the grouping keys.
>
>
On Monday, May 30, 2022 4:13 pmshiy.f...@fujitsu.com
wrote:
>
> On Tue, May 10, 2022 5:43 PM Simon Riggs
> wrote:
> >
> > On Sat, 30 Apr 2022 at 12:12, Amit Kapila
> > wrote:
> > >
> > > Few comments on the patch:
> > > 1. I think it is better to use DatumGetUInt32 to fetch the hash key
> > >
On Fri, Jul 22, 2022 at 3:11 PM Masahiko Sawada wrote:
> We can see regression.diffs[1]:
Ahh, right, thanks. We see it when it fails in test-decoding-check on
Windows, but not when it fails in MiscCheck, and I didn't check enough
of them.
On Fri, Jul 22, 2022 at 2:12 AM Alvaro Herrera wrote:
> On 2022-Jul-21, Amit Langote wrote:
>
> > Because I wrote all of it while not really understanding how the LLVM
> > constructs like blocks and branches work, the only reason I think
> > those llvm_compile_expr() additions may be correct is
On Fri, Jul 22, 2022 at 10:59 AM Thomas Munro wrote:
>
> Hi,
>
> Here are some recent $SUBJECT on HEAD. Unfortunately we don't see the
> regression.diffs file :-(
We can see regression.diffs[1]:
== output_iso/regression.diffs
diff -w -U3
Fujii Masao writes:
> On 2022/07/21 14:54, Kyotaro Horiguchi wrote:
>> At Thu, 21 Jul 2022 11:45:23 +0900, Fujii Masao
>> wrote in
>>> - (errmsg("could not locate required checkpoint record"),
>>> + (errmsg("could not locate a valid checkpoint record in backup_label
>>> file"),
>> "in
Ok, thanks for the clarification.
On Fri, Jul 22, 2022 at 11:03 AM Tom Lane wrote:
>
> Junwang Zhao writes:
> > I notice that there are lots of *static inline functions* in header files,
> > the header file's content will go into each translation unit at preprocess
> > phase, that means all the
On 2022/07/21 23:41, Japin Li wrote:
On Thu, 21 Jul 2022 at 22:22, Fujii Masao wrote:
Hi,
I found that fetch_more_data_begin() in postgres_fdw reports an error when
PQsendQuery() returns the value less than 0 as follows though PQsendQuery() can
return only 1 or 0. I think this is a
Junwang Zhao writes:
> I notice that there are lots of *static inline functions* in header files,
> the header file's content will go into each translation unit at preprocess
> phase, that means all the c file including the header will have a copy
> of the static inline function.
We are assuming
On 2022/07/21 14:54, Kyotaro Horiguchi wrote:
I agree to removing the two parameters. And agree to let
ReadCheckpointRecord not conscious of the location source.
Thanks for the review!
At Thu, 21 Jul 2022 11:45:23 +0900, Fujii Masao
wrote in
Agreed. Attached is the updated version of
I notice that there are lots of *static inline functions* in header files,
the header file's content will go into each translation unit at preprocess
phase, that means all the c file including the header will have a copy
of the static inline function.
The inline keyword is a hint for compiler to
Hi.
+errmsg("cannot operate on relation \"%s\"",
Other callers of errdetail_relkind_not_supported() describing
operations concretely. In that sense we I think should say "cannot
open relation \"%s\"" here.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software
Hi,
Here are some recent $SUBJECT on HEAD. Unfortunately we don't see the
regression.diffs file :-(
bfbot=> select make_snapshot_url(animal, snapshot) from run where
'slot_creation_error' = any(fail_tests) order by snapshot desc;
make_snapshot_url
Finally returning to this .. rebased and updated per feedback.
I'm not sure of a good place to put test cases for this..
>From 13e8c8b96d1a5313fd3edde515a5278cf8c6b23e Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Mon, 13 Dec 2021 08:42:38 -0600
Subject: [PATCH v5 1/3] warn when setting GUC
On Tue, Jul 19, 2022 at 1:30 PM John Naylor
wrote:
>
>
>
> On Tue, Jul 19, 2022 at 9:11 AM Masahiko Sawada wrote:
>
> > I’d like to keep the first version simple. We can improve it and add
> > more optimizations later. Using radix tree for vacuum TID storage
> > would still be a big win
Hearing no objection, I committed the patch to remove O_FSYNC. The
next cleanup one I'll just leave here for now.
From a50957d4c079a3703c9f8074287c7edb5654022c Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Wed, 20 Jul 2022 14:10:37 +1200
Subject: [PATCH v3] Remove fdatasync configure probe.
On Fri, Jul 22, 2022 at 1:09 PM Michael Paquier wrote:
> On Thu, Jun 23, 2022 at 02:30:13PM +0900, Michael Paquier wrote:
> > One idea I got to limit the useless output generated is to check the
> > status of the cluster after running the regression test suite as
> > restart_on_crash is disabled
On Thu, Jun 23, 2022 at 02:30:13PM +0900, Michael Paquier wrote:
> One idea I got to limit the useless output generated is to check the
> status of the cluster after running the regression test suite as
> restart_on_crash is disabled by default in Cluster.pm, and avoid any
> follow-up logic in
At Thu, 21 Jul 2022 13:25:05 +0200, Alvaro Herrera
wrote in
> On 2022-Jul-21, Alvaro Herrera wrote:
>
> > Yeah, I think that would reduce cruft. I'm not sure this is more
> > against backpatching policy or less, compared to adding a separate
> > GUC just for this bugfix.
>
> cruft:
>
>
On Thu, Jul 21, 2022 at 02:43:03PM +0800, Japin Li wrote:
> I attached a patch for v14 [1] based on master, if you want to apply it,
> please consider reviewing it.
We are talking about a few hundred bytes leaked each time, so this
does not worry me much in the older branches, honestly.
--
On Thu, Jul 21, 2022 at 05:39:35PM -0700, Gurjeet Singh wrote:
> One notable side effect of this change is that
> process_session_preload_libraries() is now called _before_ we
> SetProcessingMode(NormalProcessing). Which means any database access
> performed by _PG_init() of an extension will be
On Thu, Jul 21, 2022 at 07:42:12PM +0200, Alvaro Herrera wrote:
> Thanks. I was looking at the recently modified REINDEX syntax and
> noticed there another spot for taking an optional name. I ended up
> reusing OptSchemaName for that, as in the attached patch. I think
> adding
On Thu, Jul 21, 2022 at 4:35 PM Gurjeet Singh wrote:
> I like the idea of performing library initialization in
> InitPostgres(), as it performs the first transaction of the
> connection, and because of the libraries' ability to gin up new GUC
> variables that might need special handling, and also
On Thu, Jul 21, 2022 at 06:26:58PM -0400, Anthony Sotolongo wrote:
> Hi all:
> Here's a patch to add counters about planned/executed for parallelism to
> pg_stat_statements, as a way to follow-up on if the queries are
> planning/executing with parallelism, this can help to understand if you
At Thu, 21 Jul 2022 23:14:57 +1200, Thomas Munro wrote
in
> On Thu, Jul 21, 2022 at 11:01 PM Alvaro Herrera
> wrote:
> > On 2022-Jul-20, Alvaro Herrera wrote:
> > > I see the following alternatives:
> > >
> > > 1. not backpatch this fix to 14 and older
> > > 2. use a different GUC; either
On Thu, Jul 21, 2022 at 07:30:20PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> +StartTransactionCommand();
>> process_session_preload_libraries();
>> +CommitTransactionCommand();
>
> Yeah, that way would avoid any questions about changing the order of
> operations, but it
On Thu, Jul 21, 2022 at 3:29 PM Nathan Bossart wrote:
>
> On Thu, Jul 21, 2022 at 05:44:11PM -0400, Tom Lane wrote:
> > Right. So there are basically two things we could do about this:
> >
> > 1. set_config_option could decline to call pg_parameter_aclcheck
> > if not IsTransactionState(),
On Thu, Jul 21, 2022 at 2:44 PM Tom Lane wrote:
>
> Gurjeet Singh writes:
> > While poking at plperl's GUC in an internal discussion, I was able to
> > induce a crash (or an assertion failure in assert-enabled builds) as
> > an unprivileged user.
> > My investigation so far has revealed that the
Nathan Bossart writes:
> +StartTransactionCommand();
> process_session_preload_libraries();
> +CommitTransactionCommand();
Yeah, that way would avoid any questions about changing the order of
operations, but it seems like a mighty expensive solution: it's
adding a transaction to
On Wed, Jul 20, 2022 at 3:42 PM Tom Lane wrote:
> Jacob Champion writes:
> > I'm currently hardcoding an elevel of ERROR on the new guc_strdup()s,
> > because that seems to be a common case for the check hooks.
>
> Really? That's almost certainly NOT okay. As an example, if you
> have a
On Thu, Jul 21, 2022 at 05:44:11PM -0400, Tom Lane wrote:
> Right. So there are basically two things we could do about this:
>
> 1. set_config_option could decline to call pg_parameter_aclcheck
> if not IsTransactionState(), instead failing the assignment.
> This isn't a great answer because it
Hi all:
Here's a patch to add counters about planned/executed for parallelism
to pg_stat_statements, as a way to follow-up on if the queries are
planning/executing with parallelism, this can help to understand if you
have a good/bad configuration or if your hardware is enough
We
On Thu, Jul 21, 2022 at 10:11 PM Amit Kapila wrote:
>
> On Thu, Jul 21, 2022 at 10:03 AM Michael Paquier wrote:
> >
> > On Thu, Jul 21, 2022 at 09:54:05AM +0530, Amit Kapila wrote:
> > > Yeah, it is not very clear to me either. I think this won't be
> > > difficult to change one or another way
Gurjeet Singh writes:
> While poking at plperl's GUC in an internal discussion, I was able to
> induce a crash (or an assertion failure in assert-enabled builds) as
> an unprivileged user.
> My investigation so far has revealed that the code path for the
> following condition has never been
On Tue, Jul 19, 2022 at 11:22 PM Morris de Oryx wrote:
> It might help if I show a sample insert handling function. The issue is with
> the line at the end of the top CTE, insert_rows:
>
> returning xmax as inserted_transaction_id),
>
> That's what fails on partitions. Is there an
Hey,
This came up today on twitter as a claimed POLA violation:
postgres=# select random(), random() order by random();
random| random
-+-
0.08176638503720679 | 0.08176638503720679
(1 row)
Which was explained long ago by Tom as:
Hi,
On 7/21/22 6:34 AM, vignesh C wrote:
On Thu, Jul 21, 2022 at 2:06 PM Amit Kapila wrote:
On Wed, Jul 20, 2022 at 2:33 PM vignesh C wrote:
Modified. Apart from this I have run pgperltidy on the perl file and
renamed 032_origin.pl to 030_origin.pl as currently there is
029_on_error.pl,
On 2022-07-21 Th 04:53, Alvaro Herrera wrote:
> On 2022-Jul-20, Andrew Dunstan wrote:
>
>> On 2022-07-20 We 13:23, Justin Pryzby wrote:
>>> PATH=... && @echo "TAP tests not enabled. Try configuring with
>>> --enable-tap-tests"
>>> /bin/sh: 1: @echo: not found
>>>
>>> make is telling the shell
On Mon, Jul 18, 2022 at 12:53:23PM +0200, Peter Eisentraut wrote:
> Asymmetric keys gives you some more options for how you set up the keys at
> the beginning. For example, you create the asymmetric key pair on the host
> where your client program that wants access to the encrypted data will run.
On Thu, 21 Jul 2022 at 18:42, Alvaro Herrera wrote:
>
> Thanks. I was looking at the recently modified REINDEX syntax and
> noticed there another spot for taking an optional name. I ended up
> reusing OptSchemaName for that, as in the attached patch. I think
> adding production-specific
On Mon, Jul 18, 2022 at 9:07 AM Robert Haas wrote:
> Even there, what can be accomplished with a feature that only encrypts
> individual column values is by nature somewhat limited. If you have a
> text column that, for one row, stores the value 'a', and for some
> other row, stores the entire
On Mon, Jul 18, 2022 at 3:53 AM Peter Eisentraut
wrote:
> Some other products make use of secure enclaves to do computations on
> (otherwise) encrypted values on the server. I don't fully know how that
> works, but I suspect that asymmetric keys can play a role in that. (I
> don't have any
On 2022-Jul-15, Thomas Munro wrote:
> On Mon, Jul 11, 2022 at 9:45 PM Kyotaro Horiguchi
> wrote:
> > So, for starters, I compiled the whole tree with -Wshadow=local. and I
> > saw many warnings with it. At a glance all of them are reasonably
> > "fixed" but I don't think it is what we want...
On Wed, Jul 20, 2022 at 11:50:10AM -0400, Tom Lane wrote:
> I think that 13d838815 has completely changed the terms that this
> discussion needs to be conducted under. It seems clear to me now
> that if you want to relax this only-superusers restriction, what
> you have to do is store the OID of
On Tue, Jul 12, 2022 at 02:47:07PM -0400, Bruce Momjian wrote:
> On Mon, Jul 11, 2022 at 11:31:32PM -0700, Noah Misch wrote:
> > On Mon, Jul 11, 2022 at 12:39:57PM -0400, Bruce Momjian wrote:
> > > I had trouble reading the sentences in the order you used so I
> > > restructured it:
> > >
> > >
On 2022-Jul-21, Dean Rasheed wrote:
> I tend to agree with Matthias' earlier point about avoiding code
> duplication in the grammar. Without going off and refactoring other
> parts of the grammar not related to this patch, it's still a slightly
> smaller, simpler change, and less code
Am 21.07.22 um 10:41 schrieb Dean Rasheed:
It's important to mark these new functions as VOLATILE, not IMMUTABLE,
otherwise they won't work as expected in queries. See
https://www.postgresql.org/docs/current/xfunc-volatility.html
It would be better to use pg_prng_uint64_range() rather than
On Thu, Jul 21, 2022 at 01:02:50PM -0400, Tom Lane wrote:
> Robert Haas writes:
>> ... if
>> we want to regard no-superusers as a supported configuration, we
>> probably need to tighten that up. I think it's kind of hopeless,
>
> Yeah, I agree. At least, I'm uninterested in spending any of my
>
On 2022-Jul-21, Amit Langote wrote:
> Because I wrote all of it while not really understanding how the LLVM
> constructs like blocks and branches work, the only reason I think
> those llvm_compile_expr() additions may be correct is that all the
> tests in jsonb_sqljson.sql pass even if I add the
Robert Haas writes:
> ... if
> we want to regard no-superusers as a supported configuration, we
> probably need to tighten that up. I think it's kind of hopeless,
Yeah, I agree. At least, I'm uninterested in spending any of my
own time trying to make that usefully-more-secure than it is today.
On Thu, Jul 21, 2022 at 12:28 PM Tom Lane wrote:
> True, but what if the idea is to have *no* superusers? I seem
> to recall people being interested in setups like that.
Hmm, right. There's nothing that stops you from de-super-ing all of
your superusers today, and then if you ever need to do
"David G. Johnston" writes:
> On Thu, Jul 21, 2022 at 9:28 AM Tom Lane wrote:
>> True, but what if the idea is to have *no* superusers? I seem
>> to recall people being interested in setups like that.
> I would expect an initdb option (once this is possible) to specify this
> desire and we
On Thu, Jul 21, 2022 at 9:28 AM Tom Lane wrote:
> Robert Haas writes:
> > Currently, it's possible to remove the rolissuper bit from the
> > bootstrap superuser, but this leaves that user - and the system in
> > general - in an odd state. The bootstrap user continues to own all of
> > the
Robert Haas writes:
> Currently, it's possible to remove the rolissuper bit from the
> bootstrap superuser, but this leaves that user - and the system in
> general - in an odd state. The bootstrap user continues to own all of
> the objects it owned before, e.g. all of the system catalogs. Direct
Hello,
I have addressed the reviews.
@Aleksander Alekseev thanks for reporting the issue. I have altered
the patch to respect the behavior of pg_stat_activity, specifically
[1]
> Another important point is that when a server process is asked to display any
> of these statistics,
> it first
On 7/21/22 16:12, Dean Rasheed wrote:
> On Wed, 20 Jul 2022 at 12:01, Matthias van de Meent
> wrote:
>>
>> On Wed, 13 Jul 2022 at 08:07, Simon Riggs
>> wrote:
>>>
+ *CREATE STATISTICS [ [IF NOT EXISTS] stats_name ]
>>
>> I think this is ready for a committer, so I've marked
Hi,
Currently, it's possible to remove the rolissuper bit from the
bootstrap superuser, but this leaves that user - and the system in
general - in an odd state. The bootstrap user continues to own all of
the objects it owned before, e.g. all of the system catalogs. Direct
DML on system catalogs
On Thu, 21 Jul 2022 at 15:12, Dean Rasheed wrote:
>
> On Wed, 20 Jul 2022 at 12:01, Matthias van de Meent
> wrote:
> >
> > On Wed, 13 Jul 2022 at 08:07, Simon Riggs
> > wrote:
> > >
> > > > + *CREATE STATISTICS [ [IF NOT EXISTS] stats_name ]
> >
> > I think this is ready for a
LGTM
On Thu, Jul 21, 2022 at 11:52 PM Aleksander Alekseev
wrote:
>
> Hi Junwang,
>
> > btw, there are some typos in Patch v5, %s/ralation/relation/g
>
> D'oh!
>
> > yeah, IMHO validate_relation_kind() is better ;)
>
> Cool. Here is the corrected patch. Thanks!
>
> --
> Best regards,
> Aleksander
Hi Junwang,
> btw, there are some typos in Patch v5, %s/ralation/relation/g
D'oh!
> yeah, IMHO validate_relation_kind() is better ;)
Cool. Here is the corrected patch. Thanks!
--
Best regards,
Aleksander Alekseev
v6-0001-Eliminate-duplicate-code-in-table.c.patch
Description: Binary data
Am 21.07.22 um 14:25 schrieb Dean Rasheed:
I'm inclined to say that we want a new pg_global_prng_user_state that
is updated by setseed(), and used by random(), array_shuffle(),
array_sample(), and any other user-facing random functions we add
later.
I like the idea. How would you organize
Fujii Masao writes:
> I found that fetch_more_data_begin() in postgres_fdw reports an error when
> PQsendQuery() returns the value less than 0 as follows though PQsendQuery()
> can return only 1 or 0. I think this is a bug. Attached is the patch that
> fixes this bug. This needs to be
On Thu, Jul 21, 2022 at 11:55 PM Amit Langote
wrote:
> On Wed, Jul 20, 2022 at 11:09 PM Amit Langote
wrote:
> > On Wed, Jul 20, 2022 at 12:37 AM Andres Freund
wrote:
> > > On 2022-07-19 20:40:11 +0900, Amit Langote wrote:
> > > > About that, I was wondering if the blocks in llvm_compile_expr()
btw, there are some typos in Patch v5, %s/ralation/relation/g
On Thu, Jul 21, 2022 at 10:05 PM Aleksander Alekseev
wrote:
>
> Hi Amit,
>
> > Yeah, that's better. On again thinking about the function name, I
> > wonder if validate_relation_type() suits here as there is no generic
> > object being
On Wed, 20 Jul 2022 at 15:09, Andres Freund wrote:
>
> Each backend only had stats for things it touched. But the stats collector
> read all files at startup into hash tables and absorbed all generated stats
> into those as well.
Fascinating. I'm surprised this didn't raise issues previously
yeah, IMHO validate_relation_kind() is better ;)
On Thu, Jul 21, 2022 at 10:21 PM Aleksander Alekseev
wrote:
>
> Hi Amit,
>
> > Yep, validate_relation_type() sounds better.
>
> Or maybe validate_relation_kind() after all?
>
> --
> Best regards,
> Aleksander Alekseev
--
Regards
Junwang Zhao
On Wed, Jul 20, 2022 at 11:09 PM Amit Langote wrote:
> On Wed, Jul 20, 2022 at 12:37 AM Andres Freund wrote:
> > On 2022-07-19 20:40:11 +0900, Amit Langote wrote:
> > > About that, I was wondering if the blocks in llvm_compile_expr() need
> > > to be hand-coded to match what's added in
On Thu, 21 Jul 2022 at 22:22, Fujii Masao wrote:
> Hi,
>
> I found that fetch_more_data_begin() in postgres_fdw reports an error when
> PQsendQuery() returns the value less than 0 as follows though PQsendQuery()
> can return only 1 or 0. I think this is a bug. Attached is the patch that
>
Hi, John!
On Thu, Jul 21, 2022 at 6:44 AM John Naylor
wrote:
> On Tue, Jul 12, 2022 at 3:23 PM Alexander Korotkov
> wrote:
> > There are some places, which potentially could cause a slowdown. I'm
> > going to make some experiments with that.
>
> I haven't looked at the patches, so I don't
Hi,
I found that fetch_more_data_begin() in postgres_fdw reports an error when
PQsendQuery() returns the value less than 0 as follows though PQsendQuery() can
return only 1 or 0. I think this is a bug. Attached is the patch that fixes
this bug. This needs to be back-ported to v14 where async
Hi Amit,
> Yep, validate_relation_type() sounds better.
Or maybe validate_relation_kind() after all?
--
Best regards,
Aleksander Alekseev
On Wed, 20 Jul 2022 at 12:01, Matthias van de Meent
wrote:
>
> On Wed, 13 Jul 2022 at 08:07, Simon Riggs
> wrote:
> >
> > > + *CREATE STATISTICS [ [IF NOT EXISTS] stats_name ]
>
> I think this is ready for a committer, so I've marked it as such.
>
Picking this up...
I tend to
Hi Amit,
> Yeah, that's better. On again thinking about the function name, I
> wonder if validate_relation_type() suits here as there is no generic
> object being passed?
Yep, validate_relation_type() sounds better.
--
Best regards,
Aleksander Alekseev
On Wed, Jul 20, 2022 at 09:19:17PM -0400, Bruce Momjian wrote:
> On Wed, Jul 20, 2022 at 04:32:46PM -0400, Bruce Momjian wrote:
> > On Wed, Jul 20, 2022 at 04:23:21PM -0400, Isaac Morland wrote:
> > > Will there be a comprehensive list somewhere? Even if it just lists the
> > > views,
> > > gives
On Thu, Jul 21, 2022 at 6:12 PM Aleksander Alekseev
wrote:
>
> Hi Alvaro,
>
> > Hmm, but see commit 2ed532ee8c47 about this kind of check. Perhaps we
> > should change these error messages to conform to the same message style.
>
> Good point! Done.
>
Yeah, that's better. On again thinking about
Thomas Munro writes:
> On Thu, Jul 21, 2022 at 1:34 AM Tom Lane wrote:
>> How is it sane to ask for a segment bin for zero pages? Seems like
>> something should have short-circuited such a case well before here.
> It's intended. There are two ways you can arrive here with n == 0:
OK.
>> We
Good day, Thomas
В Пт, 27/05/2022 в 23:24 +1200, Thomas Munro пишет:
> Rebased, debugged and fleshed out a tiny bit more, but still with
> plenty of TODO notes and questions. I will talk about this idea at
> PGCon, so I figured it'd help to have a patch that actually applies,
> even if it
Hi
On Thu, Jul 21, 2022 at 6:44 AM Masahiko Sawada wrote:
>
> Hi,
>
> I realized that standby_desc_running_xacts() in standbydesc.c doesn't
> describe subtransaction XIDs. I've attached the patch to improve the
> description. Here is an example by pg_wlaldump:
>
> * HEAD
> rmgr: Standby len
Good day, all.
I did benchmark of patch on 2 socket Xeon 5220 CPU @ 2.20GHz .
I used "benchmark" used to reproduce problems with SLRU on our
customers setup.
In opposite to Shawn's tests I concentrated on bad case: a lot
of contention.
slru-funcs.sql - function definitions
- functions creates
Hi Alvaro,
> Hmm, but see commit 2ed532ee8c47 about this kind of check. Perhaps we
> should change these error messages to conform to the same message style.
Good point! Done.
--
Best regards,
Aleksander Alekseev
v4-0001-Eliminate-duplicate-code-in-table.c.patch
Description: Binary data
Hi,
Sorry for the first email.
On Mon, 18 Jul 2022 at 23:23, Andres Freund wrote:
>
> In
https://postgr.es/m/0e81e45c-c9a5-e95b-2782-ab2dfec8bf57%40enterprisedb.com
> On 2022-07-06 11:03:31 +0200, Peter Eisentraut wrote:
> > dff7b5a960 meson: prereq: regress: allow to specify director
On Thu, 21 Jul 2022 at 12:15, Martin Kalcher
wrote:
>
> I agree that we should use pg_prng_uint64_range(). However, in order to
> achieve interoperability with setseed() we would have to use
> drandom_seed (rather than pg_global_prng_state) as rng state, which is
> declared statically in float.c
On 2022-Jul-21, Junwang Zhao wrote:
> There are some duplicate code in table.c, add a static inline function
> to eliminate the duplicates.
Hmm, but see commit 2ed532ee8c47 about this kind of check. Perhaps we
should change these error messages to conform to the same message style.
--
Álvaro
Hi,
On 2022-07-18 23:23:27 +0300, Andres Freund wrote:
> Bilal, Peter previously commented on the pg_regress change for ecpg,
> perhaps
> you can comment on that?
>
> In
> https://postgr.es/m/0e81e45c-c9a5-e95b-2782-ab2dfec8bf57%40enterprisedb.com
> On 2022-07-06 11:03:31 +0200, Peter Eisentraut
Hi Amit,
> I don't think this change should be part of this patch. Do you see a
> reason for doing this?
My bad. I thought this was done by pgindent.
--
Best regards,
Aleksander Alekseev
v3-0001-Eliminate-duplicate-code-in-table.c.patch
Description: Binary data
On Thu, Jul 21, 2022 at 5:09 PM Aleksander Alekseev
wrote:
>
> > > There are some duplicate code in table.c, add a static inline function
> > > to eliminate the duplicates.
> > >
> >
> > Can we name function as validate_object_type, or check_object_type?
> >
> > Otherwise, the patch looks fine to
Hi hackers,
> > There are some duplicate code in table.c, add a static inline function
> > to eliminate the duplicates.
> >
>
> Can we name function as validate_object_type, or check_object_type?
>
> Otherwise, the patch looks fine to me. Let's see if others have
> something to say.
LGTM
--
On 7/5/22 13:57, Yuya Watari wrote:
On Mon, Jul 4, 2022 at 6:28 AM Tom Lane wrote:
Perhaps the bms_is_subset class could be handled in a similar
way, ie do a one-time pass to make a List of all EquivalenceMembers
that use a RelOptInfo.
Thank you for giving your idea. I will try to polish up
On 2022-Jul-21, Alvaro Herrera wrote:
> Yeah, I think that would reduce cruft. I'm not sure this is more
> against backpatching policy or less, compared to adding a separate
> GUC just for this bugfix.
cruft:
{
{"allow_recovery_tablespaces", PG_POSTMASTER, WAL_RECOVERY,
On 2022-Jul-21, Thomas Munro wrote:
> On Thu, Jul 21, 2022 at 11:01 PM Alvaro Herrera
> wrote:
> > I've got no opinions on this. I don't like either 1 or 3, so I'm going
> > to add and backpatch a new GUC allow_recovery_tablespaces as the
> > override mechanism.
> >
> > If others disagree
On 2022-Jul-21, Thomas Munro wrote:
> On Wed, Jul 20, 2022 at 10:51 PM Alvaro Herrera
> wrote:
> > v26 here. I spent some time fighting the readdir() stuff for
> > Windows (so that get_dirent_type returns LNK for junction points)
> > but couldn't make it to work and was unable to figure out
Am 21.07.22 um 10:41 schrieb Dean Rasheed:
A couple of quick comments on the current patch:
Thank you for your feedback!
It's important to mark these new functions as VOLATILE, not IMMUTABLE,
otherwise they won't work as expected in queries. See
On Thu, Jul 21, 2022 at 11:01 PM Alvaro Herrera wrote:
> On 2022-Jul-20, Alvaro Herrera wrote:
> > I see the following alternatives:
> >
> > 1. not backpatch this fix to 14 and older
> > 2. use a different GUC; either allow_invalid_pages as previously
> >suggested, or create a new one just
1 - 100 of 128 matches
Mail list logo
