Le 07/07/2021 à 06:59, David Rowley a écrit :
> On Wed, 7 Jul 2021 at 10:18, Gilles Darold wrote:
>> I have noticed that postgres_fdw do not push down the CASE WHEN clauses. In
>> the following case this normal:
> This looks very similar to [1] which is in the current commitfest.
>
> Are you
Michael Paquier writes:
> It seems to me that this does not address yet the problems with the
> palloc/pstrdup in jsonapi.c though, which would need to rely on
> malloc() if we finish to use this code in libpq. I am not sure yet
> that we have any need to do that yet as we may finish by not
On Tue, Jun 29, 2021 at 03:34:29PM -0400, Tom Lane wrote:
> Actually, I'd forgotten that the PQExpBuffer functions are already
> exported by libpq, and much of our frontend code already uses them
> from there. So we don't really need to move anything unless there's
> a call to use this code in
On Thu, Jul 1, 2021 at 10:43 AM Euler Taveira wrote:
>
>
> Amit, thanks for rebasing this patch. I already had a similar rebased patch in
> my local tree. A recent patch broke your version v15 so I rebased it.
>
Hi,
I did some testing of the performance of the row filtering, in the
case of the
>
>
>
> For example: SELECT nullablecol FROM tab WHERE nullablecol = ;
>
> If the equality operator is strict then the nullablecol can be NULL in
> the WHERE clause but not in the SELECT list. Tom's idea should allow
> us to determine both of those things but your idea cannot tell them
> apart,
On Tue, Jul 06, 2021 at 06:20:49PM +, Jacob Champion wrote:
> On Mon, 2021-07-05 at 17:17 +0900, Michael Paquier wrote:
> Each name must be null-terminated, not just null-separated. That way
> the list of names ends with an empty string:
>
> name-one\0 <- added by the
On Wed, 7 Jul 2021 at 10:18, Gilles Darold wrote:
> I have noticed that postgres_fdw do not push down the CASE WHEN clauses. In
> the following case this normal:
This looks very similar to [1] which is in the current commitfest.
Are you able to look over that patch and check to ensure you're
On Fri, 2 Jul 2021 at 12:41, Amit Langote wrote:
> I'll mark the CF entry as WoA, unless you'd rather I just mark it RwF.
I've set it to waiting on author. It was still set to needs review.
If you think you'll not get time to write the patch during this CF,
feel free to bump it out.
David
On Wed, 7 Jul 2021 at 02:46, David Christensen
wrote:
> if we do decide to expand the units table there will be a
> few additional changes (most significantly, the return value of
> `pg_size_bytes()` will need to switch
> to `numeric`).
I wonder if it's worth changing pg_size_bytes() to return
On Tue, 6 Jul 2021 at 22:39, David Rowley wrote:
> If anyone feels differently, please let me know in the next couple of
> days. Otherwise, I plan on taking a final look and pushing it soon.
After doing some very minor adjustments, I pushed this. (29f45e299).
Thanks to James and Zhihong for
On Tue, Jul 6, 2021 at 11:06 PM Tom Lane wrote:
>
> Amul Sul writes:
> > On Tue, Apr 20, 2021 at 6:59 AM Kyotaro Horiguchi
> > wrote:
> >> I don't mind RelationGetSmgr(index)->smgr_rnode alone or
> >> >member alone and there's not the previous call to
> >> RelationGetSmgr just above. How about
On Wed, Jul 7, 2021 at 5:33 AM Peter Smith wrote:
> PSA my patch which includes all the fixes mentioned above.
I agree with Amit to start a separate thread to discuss these points.
IMO, we can close this thread. What do you think?
Regards,
Bharath Rupireddy.
On Wed, Jul 7, 2021 at 7:36 AM Alvaro Herrera wrote:
>
> On 2021-Jul-07, Peter Smith wrote:
>
> > 1. Zap 'opts' up-front
> >
> > + *
> > + * Caller is expected to have cleared 'opts'.
> >
> > This comment is putting the onus on the caller to "do the right thing".
> >
> > I think that hopeful
Fabien COELHO писал 2021-07-06 23:49:
Hello Yura,
However, I'm not enthousiastic at combining two methods depending on
the range, the function looks complex enough without that, so I would
suggest not to take this option. Also, the decision process adds to
the average cost, which is
On Wed, 7 Jul 2021 at 02:54, Tom Lane wrote:
>
> Minor nit: use "const char *text" in the struct declaration, so
> that all of the static data can be placed in fixed storage.
Thanks for pointing that out.
> David Rowley writes:
> > (I'm not sure why pgindent removed the space between != and
On Wed, 7 Jul 2021 at 00:51, Dean Rasheed wrote:
> 10. half_round(21) == 11 :: 20 >> 1 = 10
>
> The correct result should be 10 (it would be very odd to claim that
> 10241 bytes should be displayed as 11kb), but the half-rounding keeps
> rounding up at each stage.
>
> That's a general property of
On Tue, Jul 6, 2021 at 9:24 PM Alvaro Herrera wrote:
>
> On 2021-Jul-06, Bharath Rupireddy wrote:
>
> > Thanks, Amit. I'm posting the 0002 patch which removes extra ereport
> > calls using local variables. Please review it.
>
> I looked at this the other day and I'm not sure I like it very much.
When reading through code for my previous patch [1] I realized that
initdb does *not* warn users that it ignores all other options (except
-D/--pgdata) if the --sync-only option is used.
I'm not able to come up with an exact situation to prove this, but
this behaviour seems potentially dangerous.
On 2021/07/01 21:41, Bharath Rupireddy wrote:
On Thu, Jul 1, 2021 at 6:07 PM Fujii Masao wrote:
On 2021/07/01 13:16, Bharath Rupireddy wrote:
On Thu, Jul 1, 2021 at 8:23 AM Fujii Masao wrote:
The recent commit 61d599ede7 documented that the type of those options is
floating point. But
On 2021-Jul-07, Peter Smith wrote:
> 1. Zap 'opts' up-front
>
> + *
> + * Caller is expected to have cleared 'opts'.
>
> This comment is putting the onus on the caller to "do the right thing".
>
> I think that hopeful expectations about input should be removed - the
> function should just be
When reading the output of `initdb --help` I could not clearly
understand what the purpose of the --sync-only option was, until I
read the documentation of initdb.
-S, --sync-only only sync data directory
Perhaps the confusion was caused by the fact that sync(hronization)
means
On Tue, Jul 6, 2021 at 08:36:13PM -0400, Bruce Momjian wrote:
> On Tue, Jul 6, 2021 at 06:49:10PM -0400, Bruce Momjian wrote:
> > My point is that there are a lot internals involved here that are not
> > part of pg_upgrade, though it probably only affects pg_upgrade. Anyway,
> > Bertrand patch
On Wed, 7 Jul 2021 at 13:04, Andy Fan wrote:
> Looking forward to watching this change closely, thank you both David and Tom!
> But I still don't understand what the faults my way have , do you mind
> telling the
> details?
The problem is that we don't need 6 different ways to determine if a
On Tuesday, July 6, 2021 7:18 PM Ajin Cherian
>
> thanks for the test!
> I hadn't updated the case where sending schema across was the first
> change of the transaction as part of the decoding of the
> truncate command. In this test case, the schema was sent across
> without the stream start,
On Tue, Jul 6, 2021 at 9:14 PM Tom Lane wrote:
> David Rowley writes:
> > Tom, I'm wondering if you might get a chance to draw up a design for
> > what you've got in mind with this? I assume adding a new field in
> > Var, but I'm drawing a few blanks on how things might work for equal()
> >
On Sun, Jul 4, 2021 at 1:21 PM vignesh C wrote:
>
> CFBot shows the following failure:
> # poll_query_until timed out executing this query:
> # SELECT '0/3046250' <= replay_lsn AND state = 'streaming' FROM
> pg_catalog.pg_stat_replication WHERE application_name = 'standby_1';
> # expecting this
On Tue, Jul 6, 2021 at 06:49:10PM -0400, Bruce Momjian wrote:
> On Tue, Jul 6, 2021 at 03:46:48PM -0700, Peter Geoghegan wrote:
> > On Tue, Jul 6, 2021 at 3:30 PM Bruce Momjian wrote:
> > > Yes, I can, though it seems like a much bigger issue than pg_upgrade.
> > > I will be glad to dig into
On Tue, Jul 6, 2021 at 6:21 PM Amit Kapila wrote:
>
> On Fri, Jul 2, 2021 at 12:36 PM Amit Kapila wrote:
> >
> > On Fri, Jul 2, 2021 at 8:35 AM Alvaro Herrera
> > wrote:
> > >
> > > > The latest patch sent by Bharath looks good to me. Would you like to
> > > > commit it or shall I take care of
Hello, here are a few comments on this patch.
The patch adds a function get_att_num_by_name; but we have a lsyscache.c
function for that purpose, get_attnum. Maybe that one should be used
instead?
get_tuple_columns_map() returns a bitmapset of the attnos of the columns
in the given list, so its
On Tue, Jul 6, 2021 at 3:49 PM Bruce Momjian wrote:
> My point is that there are a lot internals involved here that are not
> part of pg_upgrade, though it probably only affects pg_upgrade. Anyway,
> Bertrand patch seems to have what I need.
I was confused by your remarks because I am kind of
On Tue, Jul 6, 2021 at 03:46:48PM -0700, Peter Geoghegan wrote:
> On Tue, Jul 6, 2021 at 3:30 PM Bruce Momjian wrote:
> > Yes, I can, though it seems like a much bigger issue than pg_upgrade.
> > I will be glad to dig into it.
>
> I'm not sure what you mean by that. Technically this would be an
On Tue, Jul 6, 2021 at 06:30:41PM -0400, Bruce Momjian wrote:
> On Tue, Jul 6, 2021 at 02:27:34PM -0700, Peter Geoghegan wrote:
> > > BTW, is it really necessary for copy_xact_xlog_xid to invoke pg_resetwal
> > > so many times? Why can't we pass all of the update-this options in one
> > > call?
On Tue, Jul 6, 2021 at 3:30 PM Bruce Momjian wrote:
> Yes, I can, though it seems like a much bigger issue than pg_upgrade.
> I will be glad to dig into it.
I'm not sure what you mean by that. Technically this would be an issue
for any program that uses "pg_resetwal -x" in the way that
On Tue, Jul 6, 2021 at 02:27:34PM -0700, Peter Geoghegan wrote:
> > BTW, is it really necessary for copy_xact_xlog_xid to invoke pg_resetwal
> > so many times? Why can't we pass all of the update-this options in one
> > call?
>
> No opinion here.
>
> > Who's going to do the legwork on this?
>
On Tue, Jul 6, 2021 at 3:12 PM Mark Dilger wrote:
> Thanks, Peter, for drawing my attention to this. I had already been
> following this thread, but had not yet thought about the problem in terms of
> amcheck.
>
> I will investigate possible solutions in verify_heapam().
Thanks! Great that we
Hi,
I have noticed that postgres_fdw do not push down the CASE WHEN clauses.
In the following case this normal:
contrib_regression=# EXPLAIN (ANALYZE, VERBOSE) SELECT (CASE WHEN
mod(c1, 4) = 0 THEN 1 ELSE 2 END) FROM ft1;
QUERY
Aleksander Alekseev writes:
>> I named the flag CUSTOMPATH_SUPPORT_PROJECTION similar to the other
>> custom node flags, but this would revert the current logic
> This seems to be a typical Kobayashi Maru situation, i.e any choice is
> a bad one. I suggest keeping the patch as is and hoping that
> On Jul 6, 2021, at 2:27 PM, Peter Geoghegan wrote:
>
> It looks like amcheck's verify_heapam.c functionality almost catches
> bugs like this one. Something for Mark (CC'd) to consider. Does it
> matter that we usually "ctx.oldest_xid = ctx.relfrozenxid", and so
> usually use
On 2021-Jun-30, Daniel Gustafsson wrote:
> + BAIL_OUT("system $_[0] failed: $!\n");
> I wonder if we should take more inspiration from the Perl manual and change it
> to "failed to execute" to make it clear that the failure was in executing the
> program, not from the program
On Tue, Jul 6, 2021 at 11:57 AM Tom Lane wrote:
> Peter Geoghegan writes:
> > ... We should just carry forward the original oldestXid.
>
> Yup. It's a bit silly that we recognized the need to do that
> for oldestMultiXid yet not for oldestXid.
True. But at the same time it somehow doesn't seem
James Hilliard writes:
> On Tue, Jul 6, 2021 at 2:34 PM Tom Lane wrote:
>> As far as I can tell, the only way to really deal with #2 is to
>> perform a runtime dlsym() probe to see whether pwritev exists, and
>> then fall back to our src/port/ implementation if not. This does
>> not look
On Tue, Jul 6, 2021 at 2:34 PM Tom Lane wrote:
>
> Peter Eisentraut writes:
> > I think this change is perfectly appropriate (modulo some small cleanups).
>
> I think there are a couple of issues here.
>
> 1. People who are already using MACOSX_DEPLOYMENT_TARGET to control
> their builds would
Hello Yura,
However, I'm not enthousiastic at combining two methods depending on
the range, the function looks complex enough without that, so I would
suggest not to take this option. Also, the decision process adds to
the average cost, which is undesirable.
Given 99.99% cases will be in
Peter Eisentraut writes:
> I think this change is perfectly appropriate (modulo some small cleanups).
I think there are a couple of issues here.
1. People who are already using MACOSX_DEPLOYMENT_TARGET to control
their builds would like to keep on doing so, but the AC_CHECK_FUNCS
probe doesn't
On Sun, 4 Jul 2021 at 09:32, Tatsuo Ishii wrote:
>
> >> So overall gain by the patch is around 15%, whereas the last test
> >> before the commit was 14%. It seems the patch is still beneficial
> >> after the commit.
> >
> > Yes, that's good!
>
> Yeah!
>
I tested this with -s100 and got similar
On Sat, Jun 12, 2021 at 4:29 AM Julien Rouhaud wrote:
> I'd like to propose an alternative approach, which is to allow multiple
> parsers
> to coexist, and let third-party parsers optionally fallback on the core
> parsers. I'm sending this now as a follow-up of [1] and to avoid duplicated
>
> On 6 Jul 2021, at 18:14, Pavel Stehule wrote:
> I thought about it more, and sometimes bitmap index scans are problematic
> too, index scans in nested loops can be a problem too.
Right. Depending on the circumstances, pretty much anything in a plan can be
something deemed problematic in
On Wed, Jun 30, 2021 at 03:29:41PM +0900, Michael Paquier wrote:
> On Tue, May 18, 2021 at 01:04:18PM +0200, Drouvot, Bertrand wrote:
> > On 5/17/21 8:56 PM, Andres Freund wrote:
> >> On 2021-05-17 20:14:40 +0200, Drouvot, Bertrand wrote:
> >>> I was also wondering if:
> >>>
> >>> * We should
Peter Geoghegan writes:
> ... We should just carry forward the original oldestXid.
Yup. It's a bit silly that we recognized the need to do that
for oldestMultiXid yet not for oldestXid.
BTW, is it really necessary for copy_xact_xlog_xid to invoke pg_resetwal
so many times? Why can't we pass
On Tue, Jul 6, 2021 at 10:58 AM Bruce Momjian wrote:
> Well, pg_upgrade corruptions are rare, but so is modifying
> autovacuum_freeze_max_age. If we have a corruption and we know
> autovacuum_freeze_max_age was modified, odds are that is the cause.
My point is that there isn't necessarily that
On Mon, 2021-07-05 at 17:17 +0900, Michael Paquier wrote:
> On Wed, Jun 30, 2021 at 10:30:12PM +, Jacob Champion wrote:
> > Done in v3, with a second patch for the code motion.
>
> I have gone through that, tweaking the documentation you have added as
> that's the meat of the patch, reworking
On 2021-Jul-06, Boris Kolpackov wrote:
> Alvaro Herrera writes:
>
> > Ah, yes it does. I can reproduce this now. I thought PQconsumeInput
> > was sufficient, but it's not: you have to have the PQgetResult in there
> > too. Looking ...
>
> Any progress on fixing this?
Yeah ... the problem
On 2021-Jul-06, Boris Kolpackov wrote:
> Alvaro Herrera writes:
>
> > Ah, yes it does. I can reproduce this now. I thought PQconsumeInput
> > was sufficient, but it's not: you have to have the PQgetResult in there
> > too. Looking ...
>
> Any progress on fixing this?
Can you please try
On Tue, Jul 6, 2021 at 10:32:24AM -0700, Peter Geoghegan wrote:
> On Tue, Jul 6, 2021 at 10:27 AM Bruce Momjian wrote:
> > OK, this is confirmation that the pg_resetwal bug, and its use by
> > pg_upgrade, is a serious issue that needs to be addressed. I am
> > prepared to work on it now.
>
>
Dean Rasheed writes:
> I took a look at this and wasn't able to find any way to break it, and
> your argument that it can't really make such rewriter bugs any worse
> makes sense.
Thanks for looking!
> Would it make sense to update the comment prior to copying the subquery?
Yeah, I hadn't
Amul Sul writes:
> On Tue, Apr 20, 2021 at 6:59 AM Kyotaro Horiguchi
> wrote:
>> I don't mind RelationGetSmgr(index)->smgr_rnode alone or
>> >member alone and there's not the previous call to
>> RelationGetSmgr just above. How about using a temporary variable?
>>
>> SMgrRelation srel =
On Tue, Jul 6, 2021 at 10:27 AM Bruce Momjian wrote:
> OK, this is confirmation that the pg_resetwal bug, and its use by
> pg_upgrade, is a serious issue that needs to be addressed. I am
> prepared to work on it now.
To be clear, I'm not 100% sure that this is related to the pg_upgrade
+
On Sun, 18 Apr 2021 at 21:42, Tom Lane wrote:
>
> > If multiple references are actually possible then this'd break it.
>
> I think this patch doesn't make things any worse for such a case though.
> If we re-introduced such a bug, the result would be an immediate null
> pointer crash while trying
On Sun, Jul 4, 2021 at 10:28:25PM +, Floris Van Nee wrote:
> >
> > I wonder if it's related to this issue:
> >
> > https://www.postgresql.org/message-
> > id/20210423234256.hwopuftipdmp3...@alap3.anarazel.de
> >
> > Have you increased autovacuum_freeze_max_age from its default? This
> >
Hello Bruce !
You can download the railroad generator to generate offline using Java
here -> https://www.bottlecaps.de/rr/download/rr-1.63-java8.zip (link
from the https://www.bottlecaps.de/rr/ui on tab Welcome).
java -jar rr.war -out:Dafny.atg.xhtml grammar.txt
Cheers !
On 6/7/21 18:51,
On Sat, Jul 3, 2021 at 10:39:02AM +0200, Domingo Alvarez Duarte wrote:
> I've done a experimental tool to convert bison grammars to a kind of EBNF
> understood by https://www.bottlecaps.de/rr/ui to generate railroad diagrams
> see
> bellow the converted
> On Jul 5, 2021, at 1:50 AM, Andrey Borodin wrote:
>
> I'm not sure, but maybe we should allow replication role to change
> session_replication_role?
Thanks, Andrey, for taking a look.
Yes, there is certainly some logic to that suggestion. The patch v4-0005 only
delegates authority to
Bharath Rupireddy writes:
> How about making the below else if statement and the attname
> assignment into a single line? They are falling below the 80 char
> limit.
> else if (colno > 0 && colno <= list_length(rte->eref->colnames))
> attname =
Hi
út 6. 7. 2021 v 16:07 odesílatel Daniel Gustafsson napsal:
> Looking at this I like the idea in principle, but I'm not convinced that
> auto_explain is the right tool for this. auto_explain is for identifying
> slow
> queries, and what you are proposing is to identify queries with a certain
On 2021-Jul-06, Bharath Rupireddy wrote:
> Thanks, Amit. I'm posting the 0002 patch which removes extra ereport
> calls using local variables. Please review it.
I looked at this the other day and I'm not sure I like it very much.
It's not making anything any simpler, it's barely saving two lines
On Tue, Jul 6, 2021 at 11:03 AM Ronan Dunklau wrote:
>
> Thank you for the review, I will address those shortly, but will answer some
> questions in the meantime.
>
> > > First, the changes are lacking any explanatory comments. Probably we
> > > should follow how nodeAgg does this and add both
On Wed, Jun 30, 2021 at 7:48 PM vignesh C wrote:
>
> On Thu, May 13, 2021 at 8:09 PM vignesh C wrote:
> >
> > On Thu, May 13, 2021 at 4:58 AM Alvaro Herrera
> > wrote:
> > >
> >
> > Thanks for the comments, Attached patch has the changes for the same.
> >
>
> The Patch was not applying on
Thank you for the review, I will address those shortly, but will answer some
questions in the meantime.
> > First, the changes are lacking any explanatory comments. Probably we
> > should follow how nodeAgg does this and add both comments to the
> > ExecSort function header as well as specific
David Rowley writes:
> Does anyone want to have a look over this? If not, I plan to push it
> in the next day or so.
Minor nit: use "const char *text" in the struct declaration, so
that all of the static data can be placed in fixed storage.
> (I'm not sure why pgindent removed the space
> I have a few suggestions on the patch
> 1.
> +
> + /*
> + * Found the oldest WAL, reset timeline ID and log segment number to
> generate
> + * the next WAL file in the sequence.
> + */
> + if (found && !historyFound)
> + {
> + XLogFromFileName(xlog, , , wal_segment_size);
> + ereport(LOG,
> +
David Rowley writes:
> On Mon, 5 Jul 2021 at 20:00, David Rowley wrote:
>> I don't really like the fact that I had to add the doHalfRound field
>> to get the same rounding behaviour as the original functions. I'm
>> wondering if it would just be too clever just to track how many bits
>> we've
On Wed, Jun 30, 2021 at 8:23 PM vignesh C wrote:
>
> On Sun, Jun 6, 2021 at 11:55 AM vignesh C wrote:
> >
> > On Fri, May 7, 2021 at 6:44 PM vignesh C wrote:
> > >
> > > Thanks for the comments, the attached patch has the fix for the same.
> >
> > The patch was not applying on the head,
> specifically about history files being given higher priority for
> archiving. If we go with this change then we'd at least want to rewrite
> or remove those comments, but I don't actually agree that we should
> remove that preference to archive history files ahead of WAL, for the
> reasons
Looking at this I like the idea in principle, but I'm not convinced that
auto_explain is the right tool for this. auto_explain is for identifying slow
queries, and what you are proposing is to identify queries with a certain
"shape" (for lack of a better term) even if they aren't slow as per the
On Tue, Jul 6, 2021 at 6:49 PM James Coleman wrote:
>
> Adding David since this patch is likely a precondition for [1].
>
> On Tue, Jul 6, 2021 at 2:15 AM Ronan Dunklau wrote:
> >
> > Hello,
> >
> > While testing the patch "Add proper planner support for ORDER BY / DISTINCT
> > aggregates" [0] I
Em ter., 6 de jul. de 2021 às 10:19, James Coleman
escreveu:
> Adding David since this patch is likely a precondition for [1].
>
> On Tue, Jul 6, 2021 at 2:15 AM Ronan Dunklau
> wrote:
> >
> > Hello,
> >
> > While testing the patch "Add proper planner support for ORDER BY /
> DISTINCT
> >
Greetings,
* Dipesh Pandit (dipesh.pan...@gmail.com) wrote:
> We have addressed the O(n^2) problem which involves directory scan for
> archiving individual WAL files by maintaining a WAL counter to identify
> the next WAL file in a sequence.
This seems to have missed the concerns raised in
Andrew Dunstan writes:
> On 7/5/21 11:46 PM, Bharath Rupireddy wrote:
>> On Tue, Jul 6, 2021 at 12:43 AM Tom Lane wrote:
>>> I like "debug_flush_caches" --- it's short and accurate.
>> Do we always flush the cache entries into the disk? Sometimes we just
>> invalidate the cache entries in the
Adding David since this patch is likely a precondition for [1].
On Tue, Jul 6, 2021 at 2:15 AM Ronan Dunklau wrote:
>
> Hello,
>
> While testing the patch "Add proper planner support for ORDER BY / DISTINCT
> aggregates" [0] I discovered the performance penalty from adding a sort node
>
David Rowley writes:
> Tom, I'm wondering if you might get a chance to draw up a design for
> what you've got in mind with this? I assume adding a new field in
> Var, but I'm drawing a few blanks on how things might work for equal()
> when one Var has the field set and another does not.
As I
On 21.06.21 15:47, Filip Gospodinov wrote:
-PKG_CONFIG_REQUIRES_PRIVATE = libssl libcrypto
+PKG_CONFIG_REQUIRES_PRIVATE = libpgcommon libpgport libssl libcrypto
This doesn't work.
This patch adds libpgcommon and libpgport to Requires.private. But they
are not pkg-config names but library
Andrey Lepikhov писал 2021-07-06 12:28:
On 5/7/21 23:15, Zhihong Yu wrote:
On Mon, Jul 5, 2021 at 2:57 AM Andrey Lepikhov
mailto:a.lepik...@postgrespro.ru>> wrote:
+ * Can't imagine situation when join relation already
exists. But in
+ * the 'partition_join' regression
On Tue, 6 Jul 2021 at 13:15, David Rowley wrote:
>
> Can you give an example where calling half_rounded too many times will
> give the wrong value? Keeping in mind we call half_rounded the number
> of times that the passed in value would need to be left-shifted by to
> get the equivalent
Thank you for reply.
You are right and the PostgreSQL server writes the entire content of each disk
page to WAL during the first modification of that page after a
checkpoint while data checksum is on.
But I wonder whether it is necessary or not while my file system can protect
the blocks of
On Sun, 4 Jul 2021, 03:40 Zhihong Yu, wrote:
>
> Hi,
> I was looking at :
> Relax transactional restrictions on ALTER TYPE ... ADD VALUE (redux).
>
> In check_safe_enum_use():
>
> + if (!TransactionIdIsInProgress(xmin) &&
> + TransactionIdDidCommit(xmin))
> + return;
>
> Since the
On Tue, 6 Jul 2021 at 23:39, Dean Rasheed wrote:
> When I first read this:
>
> +/* half-round until we get down to unitBits */
> +while (rightshifts++ < unit->unitBits)
> +size = half_rounded(size);
>
> it looked to me like it would be invoking
On Tue, Jul 6, 2021 at 8:43 PM David Rowley wrote:
>
> On Sun, 4 Jul 2021 at 20:53, David Rowley wrote:
> >
> > On Sat, 3 Jul 2021 at 22:44, Peter Eisentraut
> > wrote:
> > > I don't think this is a good change.
> >
> > > I think we should leave it as is.
> >
> > I'm inclined to agree.
>
> Does
Em ter., 6 de jul. de 2021 às 08:25, Ranier Vilela
escreveu:
> Em ter., 6 de jul. de 2021 às 03:15, Ronan Dunklau
> escreveu:
>
>> Hello,
>>
>> While testing the patch "Add proper planner support for ORDER BY /
>> DISTINCT
>> aggregates" [0] I discovered the performance penalty from adding a
On Tue, 6 Jul 2021 at 10:20, David Rowley wrote:
>
> I made another pass over this and ended up removing the doHalfRound
> field in favour of just doing rounding based on the previous
> bitshifts.
>
When I first read this:
+/* half-round until we get down to unitBits */
+
On Tue, Jul 6, 2021 at 4:33 PM Michael Paquier wrote:
>
> On Tue, Jul 06, 2021 at 03:54:07PM +0530, Bharath Rupireddy wrote:
> > Thanks. You are right. The issue is due to the MyLatch being set by
> > SwitchToSharedLatch before WaitLatch. If we use (WL_TIMEOUT |
> > WL_EXIT_ON_PM_DEATH), then the
On Tue, Jul 6, 2021 at 3:58 PM Michael Paquier wrote:
> On Tue, Jul 06, 2021 at 03:38:23PM +0500, Ibrar Ahmed wrote:
> > Any update and decision on this? so I can start working on this.
>
> Working on the CF does not strongly require the admin permissions. I
> have already switched the current
Em ter., 6 de jul. de 2021 às 03:15, Ronan Dunklau
escreveu:
> Hello,
>
> While testing the patch "Add proper planner support for ORDER BY /
> DISTINCT
> aggregates" [0] I discovered the performance penalty from adding a sort
> node
> essentially came from not using the single-datum tuplesort
On Tue, Jul 06, 2021 at 05:47:34PM +0900, Kyotaro Horiguchi wrote:
> More accurately, I didn't come up with the way to split out some of
> the rule-components in a rule out as another rule using the existing
> infrastructure.
>
> [...]
>
> Then add the following component to the rule "stmt".
I
On Tue, 06 Jul 2021 at 17:58, zwj <757634...@qq.com> wrote:
> Hi all,
>
> When I read the source code file src/backend/access/transam/xloginsert.c, I
> get something confused me.
> In the function XLogSaveBufferForHint, the flags are always
> REGBUF_FORCE_IMAGE which means it is always need
On Tue, Jul 06, 2021 at 03:54:07PM +0530, Bharath Rupireddy wrote:
> Thanks. You are right. The issue is due to the MyLatch being set by
> SwitchToSharedLatch before WaitLatch. If we use (WL_TIMEOUT |
> WL_EXIT_ON_PM_DEATH), then the backends will honour the
> post_auth_delay as well as detect the
On Tue, Jul 06, 2021 at 03:38:23PM +0500, Ibrar Ahmed wrote:
> Any update and decision on this? so I can start working on this.
Working on the CF does not strongly require the admin permissions. I
have already switched the current CF as in progress, so most of the
admin job is done for this
On Mon, Jul 5, 2021 at 2:20 PM Andrey Lepikhov
wrote:
> On 2/7/21 01:56, Hywel Carver wrote:
> > On Wed, Jun 30, 2021 at 12:21 PM Andrey Lepikhov
> > mailto:a.lepik...@postgrespro.ru>> wrote:
> > I think, here we could ask more general question: do we want to
> > remove a
> > 'IS NOT
On Sun, 4 Jul 2021 at 20:53, David Rowley wrote:
>
> On Sat, 3 Jul 2021 at 22:44, Peter Eisentraut
> wrote:
> > I don't think this is a good change.
>
> > I think we should leave it as is.
>
> I'm inclined to agree.
Does anyone object to marking this patch as rejected in the CF app?
David
I've been looking at the NOT IN hashing patch again and after making a
few minor tweaks I think it's pretty much ready to go.
If anyone feels differently, please let me know in the next couple of
days. Otherwise, I plan on taking a final look and pushing it soon.
David
On Fri, Jul 2, 2021 at 7:15 PM Ibrar Ahmed wrote:
>
>
> On Fri, 2 Jul 2021 at 7:06 PM, vignesh C wrote:
>
>> On Fri, Jul 2, 2021 at 6:05 PM Ibrar Ahmed wrote:
>> >
>> >
>> >
>> > On Fri, 2 Jul 2021 at 1:47 PM, David Rowley
>> wrote:
>> >>
>> >> On Fri, 2 Jul 2021 at 15:04, vignesh C wrote:
1 - 100 of 129 matches
Mail list logo
