Got it, thanks!
On Wed, Jul 20, 2022 at 1:14 PM Michael Paquier wrote:
>
> On Wed, Jul 20, 2022 at 12:51:24PM +0800, Junwang Zhao wrote:
> > Though the patch looks good, I myself think the patch should be edited
> > and submitted by Tang
> > It's easy to attach a fixed patch based on the
On Wed, Jul 20, 2022 at 5:26 PM Thomas Munro wrote:
> On Wed, Jul 20, 2022 at 4:52 PM Tom Lane wrote:
> > I think we could probably just drop fls() entirely. It doesn't look
> > to me like any of the existing callers expect a zero argument, so they
> > could be converted to use
On Wed, Jul 20, 2022 at 7:06 AM Kyotaro Horiguchi
wrote:
>
> At Tue, 19 Jul 2022 14:28:40 +0530, Bharath Rupireddy
> wrote in
> > Hi,
> >
> > At times it's useful to know the last replayed WAL record's timeline
> > ID (especially on the standbys that are lagging in applying WAL while
> >
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 Wed, Jul 20, 2022 at 4:52 PM Tom Lane wrote:
> I think we could probably just drop fls() entirely. It doesn't look
> to me like any of the existing callers expect a zero argument, so they
> could be converted to use pg_leftmost_one_pos32() pretty trivially.
> I don't see that fls() is buying
On Wed, Jul 20, 2022 at 9:01 AM Masahiko Sawada wrote:
>
> On Wed, Jul 20, 2022 at 12:11 PM Amit Kapila wrote:
> >
> > On Tue, Jul 19, 2022 at 7:28 PM Masahiko Sawada
> > wrote:
> >
> > Why do you think we can't remove
> > ReorderBufferInitialXactsSetCatalogChanges() from the back branch
> >
On Wed, Jul 20, 2022 at 12:51:24PM +0800, Junwang Zhao wrote:
> Though the patch looks good, I myself think the patch should be edited
> and submitted by Tang
> It's easy to attach a fixed patch based on the comments of the thread,
> but coins should be
> given to Tang since he is the first one to
On Tue, Jul 19, 2022 at 03:04:27PM +0900, Kyotaro Horiguchi wrote:
> At Wed, 13 Jul 2022 18:54:45 -0500, Justin Pryzby
> wrote in
> > On Thu, Jul 14, 2022 at 08:46:02AM +0900, Michael Paquier wrote:
> > > On Wed, Jul 13, 2022 at 12:30:00PM -0500, Justin Pryzby wrote:
> > > > How did you make
On Tue, Jul 19, 2022 at 11:34 PM Amit Kapila wrote:
>
> On Mon, Jul 18, 2022 at 9:46 PM vignesh C wrote:
> >
> > I have updated the patch to handle the origin value case
> > insensitively. The attached patch has the changes for the same.
> >
>
> Thanks, the patch looks mostly good to me. I have
On 2022/07/16 11:36, Michael Paquier wrote:
I was thinking about doing that only on HEAD. One thing interesting
about this patch is that it can also be used as a point of reference
for other future things.
Ok, here are review comments:
+my $connstr =
+ $node->connstr('postgres') . "
Thomas Munro writes:
> Back in commit 4f658dc8 we gained src/port/fls.c. As anticipated by
> its commit message, we later finished up with something better in
> src/include/port/pg_bitutils.h. fls() ("find last set") is an
> off-by-one cousin of pg_leftmost_one_pos32(). I don't know why ffs()
-1
Though the patch looks good, I myself think the patch should be edited
and submitted by Tang
It's easy to attach a fixed patch based on the comments of the thread,
but coins should be
given to Tang since he is the first one to find the mem leak.
No offense, but that's what I think how open
On Tue, Jul 19, 2022 at 1:46 PM Önder Kalacı wrote:
>
> Hi, thanks for your reply.
>
> Amit Kapila , 18 Tem 2022 Pzt, 08:29 tarihinde şunu
> yazdı:
>>
>> >
>>
>> IIUC, this proposal is to optimize cases where users can't have a
>> unique/primary key for a relation on the subscriber and those
>>
On Wed, Jul 20, 2022 at 4:14 PM Thomas Munro wrote:
> On Wed, Jul 20, 2022 at 4:08 PM David Rowley wrote:
> > On Wed, 20 Jul 2022 at 15:22, Thomas Munro wrote:
> > > Ok, I've pushed the Windows patch. I'll watch the build farm to see
> > > if I've broken any of the frankentoolchain Windows
On Wed, 20 Jul 2022 at 16:21, Thomas Munro wrote:
> Back in commit 4f658dc8 we gained src/port/fls.c. As anticipated by
> its commit message, we later finished up with something better in
> src/include/port/pg_bitutils.h. fls() ("find last set") is an
> off-by-one cousin of
On Wed, Jul 20, 2022 at 6:55 AM Kyotaro Horiguchi
wrote:
>
> At Tue, 19 Jul 2022 09:58:28 -0700, Nathan Bossart
> wrote in
> > On Tue, Jul 19, 2022 at 02:43:59PM +0530, Bharath Rupireddy wrote:
> > > Done. PSA v5 patch set.
> >
> > LGTM. I've marked this as ready-for-committer.
>
> I find the
Hi,
Back in commit 4f658dc8 we gained src/port/fls.c. As anticipated by
its commit message, we later finished up with something better in
src/include/port/pg_bitutils.h. fls() ("find last set") is an
off-by-one cousin of pg_leftmost_one_pos32(). I don't know why ffs()
("find first set", the
On Wed, Jul 20, 2022 at 4:08 PM David Rowley wrote:
> On Wed, 20 Jul 2022 at 15:22, Thomas Munro wrote:
> > Ok, I've pushed the Windows patch. I'll watch the build farm to see
> > if I've broken any of the frankentoolchain Windows animals.
>
> Just to get in there before the farm does... I just
On Wed, 20 Jul 2022 at 15:22, Thomas Munro wrote:
> Ok, I've pushed the Windows patch. I'll watch the build farm to see
> if I've broken any of the frankentoolchain Windows animals.
Just to get in there before the farm does... I just got a boatload of
redefinition of HAVE_FDATASYNC warnings. I
On Wed, 20 Jul 2022 at 11:51, Michael Paquier wrote:
> On Wed, Jul 20, 2022 at 03:14:35AM +, tanghy.f...@fujitsu.com wrote:
>> Your fix LGTM so please allow me to merge it in the attached patch.
>> Based on your rebased version, now this new patch version is V3.
>
> What about the argument
On Wed, 20 Jul 2022 at 15:02, David Rowley wrote:
> I've attached a patch for this and it changes the plan for the above query to:
Looks like I based that patch on the wrong branch.
Here's another version of the patch that's based on master.
David
diff --git
On Wed, Jul 20, 2022 at 03:14:35AM +, tanghy.f...@fujitsu.com wrote:
> Your fix LGTM so please allow me to merge it in the attached patch.
> Based on your rebased version, now this new patch version is V3.
What about the argument of upthread where we could use a goto in
functions where there
On Wed, Jul 20, 2022 at 12:11 PM Amit Kapila wrote:
>
> On Tue, Jul 19, 2022 at 7:28 PM Masahiko Sawada wrote:
> >
> > On Tue, Jul 19, 2022 at 9:25 PM Amit Kapila wrote:
> > >
> > > On Tue, Jul 19, 2022 at 1:10 PM Masahiko Sawada
> > > wrote:
> > > >
> > >
> > > > BTW on backbranches, I think
Ok, I've pushed the Windows patch. I'll watch the build farm to see
if I've broken any of the frankentoolchain Windows animals.
Mikael kindly upgraded conchuela, so that leaves just prairiedog
without fdatasync. I've attached a patch to drop the configure probe
for that once prairiedog's host
On Tue, Jul 19, 2022 at 10:38 PM Robert Haas wrote:
> For MERGE itself, I wonder if some information about this should be
> included in the command tag. It looks like MERGE already includes some
> sort of row count in the command tag, but I guess perhaps it doesn't
> distinguish between inserts
On Tuesday, July 19, 2022 7:41 PM, Japin Li wrote:
> After looking around, I found psql/describe.c also has some memory
> leaks,
> attached a patch to fix these leaks.
Thanks for your check and improvement.
Your fix LGTM so please allow me to merge it in the attached patch.
Based on your
On Tue, Jul 19, 2022 at 7:28 PM Masahiko Sawada wrote:
>
> On Tue, Jul 19, 2022 at 9:25 PM Amit Kapila wrote:
> >
> > On Tue, Jul 19, 2022 at 1:10 PM Masahiko Sawada
> > wrote:
> > >
> >
> > > BTW on backbranches, I think that the reason why we add
> > > initial_running_xacts stuff to
Hackers,
Currently, if we have a query such as:
SELECT a,b, COUNT(*)
FROM a
INNER JOIN b on a.a = b.x
GROUP BY a,b
ORDER BY a DESC, b;
With enable_hashagg = off, we get the following plan:
QUERY PLAN
---
GroupAggregate
Group Key: a.a, a.b
On Wed, Jul 20, 2022 at 9:58 AM Kyotaro Horiguchi
wrote:
>
> At Tue, 19 Jul 2022 17:31:07 +0900, Masahiko Sawada
> wrote in
> > On Tue, Jul 19, 2022 at 4:35 PM Kyotaro Horiguchi
> > wrote:
> > > At Tue, 19 Jul 2022 10:17:15 +0530, Amit Kapila
> > > wrote in
> > > > Good work. I wonder
At Tue, 19 Jul 2022 14:28:40 +0530, Bharath Rupireddy
wrote in
> Hi,
>
> At times it's useful to know the last replayed WAL record's timeline
> ID (especially on the standbys that are lagging in applying WAL while
> failing over - for reporting, logging and debugging purposes). AFICS,
>
On Tue, Jul 19, 2022 at 09:51:13PM +0900, Michael Paquier wrote:
> +1.
I have looked at that and added the extra periods, and applied it.
Thanks, Justin.
--
Michael
signature.asc
Description: PGP signature
At Tue, 19 Jul 2022 09:58:28 -0700, Nathan Bossart
wrote in
> On Tue, Jul 19, 2022 at 02:43:59PM +0530, Bharath Rupireddy wrote:
> > Done. PSA v5 patch set.
>
> LGTM. I've marked this as ready-for-committer.
I find the following sentense in config.sgml. "Specifies the minimum
size of past
At Tue, 19 Jul 2022 17:31:07 +0900, Masahiko Sawada
wrote in
> On Tue, Jul 19, 2022 at 4:35 PM Kyotaro Horiguchi
> wrote:
> > At Tue, 19 Jul 2022 10:17:15 +0530, Amit Kapila
> > wrote in
> > > Good work. I wonder without comments this may create a problem in the
> > > future. OTOH, I don't
On Wed, 20 Jul 2022 09:38:17 +0900
Fujii Masao wrote:
>
>
> On 2022/07/15 16:52, Fujii Masao wrote:
> >
> >
> > On 2022/07/08 17:03, Etsuro Fujita wrote:
> >> Rather than doing so, I'd vote for adding a test case to file_fdw, as
> >> proposed in the patch, because that would be much simpler
On 2022/07/15 16:52, Fujii Masao wrote:
On 2022/07/08 17:03, Etsuro Fujita wrote:
Rather than doing so, I'd vote for adding a test case to file_fdw, as
proposed in the patch, because that would be much simpler and much
less expensive.
So ISTM that most agreed to push Nagata-san's patch
On Tue, Jul 19, 2022 at 09:43:21AM -0700, Mark Dilger wrote:
> This looks ok, but comments down-thread seem reasonable, so I
> suspect a new patch will be needed. Would you like to author it, or
> would you prefer that I, as the guilty party, do so?
If any of you could update the patch, that
On Tue, Jul 19, 2022 at 12:36:31PM -0400, Tom Lane wrote:
> Yeah, it's old school, but please let's not have a few functions that
> do it randomly differently from all their neighbors.
True enough. And it is not like we should free the PQExpBuffer given
by the caller in validateSQLNamePattern().
On 7/18/22 02:53, Alvaro Herrera wrote:
On 2022-Jul-18, Aleksander Alekseev wrote:
Hi hackers,
If someone put a lot of review into a patchset a few months ago, they
absolutely deserve credit. But if that entry has been sitting with no
feedback this month, why is it useful to keep that
I wrote:
> * WRITE_OID_ARRAY and WRITE_BOOL_ARRAY needed extension to handle a null
> array pointer. I think we should make all the WRITE_FOO_ARRAY macros
> work alike, so I added that to all of them. I first tried to make the
> rest work like WRITE_INDEX_ARRAY, but that failed because
Hi,
On 2022-07-19 08:31:49 -0700, Andres Freund wrote:
> But I think we probably should err on the side of adding more
> declarations, rather than the oposite.
To see if there's other declarations that should be added, I used
https://codesearch.debian.net/search?q=load_external_function=1=1
Hi,
On 2022-07-19 16:28:07 +0200, Alvaro Herrera wrote:
> Anyway, the minimal patch that makes plpgsql_check tests pass is
> attached.
Do you want to commit that or should I?
Greetings,
Andres Freund
Hi,
On 2022-07-19 15:08:38 -0700, Jacob Champion wrote:
> v2 adds escaping to pg_clean_ascii(). My original attempt used
> StringInfo allocation, but that didn't play well with guc_malloc(), so
> I switched to a two-pass API where the caller allocates. Let me know
> if I'm missing something
On Tue, Jul 19, 2022 at 10:09 AM Andres Freund wrote:
> On 2022-07-19 12:39:43 -0400, Tom Lane wrote:
> > Having said that, I struggle to see why we are panicking about badly
> > encoded log data from this source while blithely ignoring the problems
> > posed by non-ASCII role names, database
On Tue, Jul 19, 2022 at 04:27:08PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> However, I wonder if a
>> better way to fix this is to provide a way to stop set_config_option() from
>> throwing errors (e.g., setting elevel to -1). That way, we could remove
>> the manual permissions checks
Hello, Andrey.
> I've looked into v5.
Thanks!
Patch is updated accordingly your remarks.
Best regards,
Michail.
From 1301a262dea7f541c11092851e82f10932150ee3 Mon Sep 17 00:00:00 2001
From: Michail Nikolaev
Date: Tue, 19 Jul 2022 23:50:53 +0300
Subject: [PATCH v6] Currently
On Tue, Jul 19, 2022 at 01:13:07PM -0500, Justin Pryzby wrote:
> On Tue, Jul 19, 2022 at 01:24:30PM -0400, Bruce Momjian wrote:
> > Well, I put the --no-synchronized-snapshots item in incompatibilities
> > since it is a user-visible change that might require script adjustments.
> > However, I put
Nathan Bossart writes:
>> I think this is because GUCArrayReset() is the only caller of
>> validate_option_array_item() that sets skipIfNoPermissions to true. The
>> others fall through to set_config_option(), which does a
>> pg_parameter_aclcheck(). So, you are right.
> Here's a small patch
Am 19.07.22 um 16:20 schrieb Tom Lane:
So I withdraw my original position. These functions should just
shuffle or select in the array's first dimension, preserving
subarrays. Or else be lazy and reject more-than-one-D arrays;
but it's probably not that hard to handle them.
Here is a patch
Tomas Vondra writes:
> I we want to improve sampling for partitioned cases (where the foreign
> table is just one of many partitions), I think we'd have to rework how
> we determine sample size for each partition. Now we simply calculate
> that from relpages, which seems quite fragile (different
Peter Eisentraut writes:
> On 18.07.22 18:08, Tom Lane wrote:
>> I'm kind of tempted to mount an effort to get rid of as many of
>> pathnodes.h's "read_write_ignore" annotations as possible. Some are
>> necessary to prevent infinite recursion, and others represent considered
>> judgments that
On 7/18/22 20:45, Tom Lane wrote:
> Tomas Vondra writes:
>> Thanks. I'll switch this to "needs review" now.
>
> OK, I looked through this, and attach some review suggestions in the
> form of a delta patch. (0001 below is your two patches merged, 0002
> is my delta.) A lot of the delta is
On Tue, Jul 19, 2022 at 01:24:30PM -0400, Bruce Momjian wrote:
> > > Remove pg_dump's --no-synchronized-snapshots option since all supported
> > > server versions support synchronized snapshots (Tom Lane)
> >
> > It'd be better to put that after the note about dropping support for
> > upgrading
On Mon, Jul 18, 2022 at 09:22:24PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Sat, Jul 16, 2022 at 10:53:17AM +0200, Peter Eisentraut wrote:
> >> Maybe this whole notion that "system views" is one thing is not suitable.
>
> > Are you thinking we should just call the chapter "System
On Mon, Jul 18, 2022 at 08:23:23PM -0500, Justin Pryzby wrote:
> > Increase hash_mem_multiplier default to 2.0 (Peter Geoghegan)
> > This allows query hash operations to use double the amount of work_mem
> > memory as other operations.
>
> I wonder if it's worth pointing out that a query may end
Hi,
On 2022-07-19 12:39:43 -0400, Tom Lane wrote:
> Having said that, I struggle to see why we are panicking about badly
> encoded log data from this source while blithely ignoring the problems
> posed by non-ASCII role names, database names, and tablespace names.
I think we should fix these as
On Tue, Jul 19, 2022 at 02:43:59PM +0530, Bharath Rupireddy wrote:
> Done. PSA v5 patch set.
LGTM. I've marked this as ready-for-committer.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
I'm preparing the way for a later patch that would allow unique hash
indexes to be primary keys. There are various parts to the problem. I
was surprised at how many times we hardcode BTREE_AM_OID and
associated BT Strategy Numbers in many parts of the code, so have been
looking for ways to
On Tue, Jul 19, 2022 at 12:55:14AM -0500, Steve Chavez wrote:
> Taking your options into consideration, for me the correct behaviour should
> be:
>
> - The ALTER ROLE placeholder should always be stored with a PGC_USERSET
> GucContext. It's a placeholder anyway, so it should be the less
On Tue, Jul 19, 2022 at 12:40:06PM -0300, Rafael Thofehrn Castro wrote:
> PG prioritizes databases that need to be frozen and since a temporary table
> can't
> be frozen by a process other than the session that created it, that DB will
> remain
> a priority until the table is dropped.
>
> I
> On Jul 19, 2022, at 2:02 AM, tanghy.f...@fujitsu.com wrote:
>
> I think there is a newly introduced memory leak in your patch d2d3547.
I agree. Thanks for noticing, and for the patch!
> Try to fix it in the attached patch.
> Kindly to have a check.
This looks ok, but comments
Jacob Champion writes:
> On 7/19/22 09:14, Andres Freund wrote:
>> IMO this should replace the existing ascii escape function instead.
> That will affect the existing behavior of application_name and
> cluster_name; is that acceptable?
I think Andres' point is exactly that these should all act
Andres Freund writes:
> On 2022-07-19 21:08:53 +0800, Japin Li wrote:
>> +{
>> +termPQExpBuffer();
>> return false;
>> +}
> Adding copy over copy of this same block doesn't seem great. Can we instead
> add a helper for it or such?
The usual style in these files
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> It seems like a reasonable idea, but I don't know enough to judge the
> wider ramifications of it. But one thing that the patch should also do,
> is switch to using the l*_node() functions instead of manual casting.
Hm, I didn't bother with
[resending to list]
On 7/19/22 09:14, Andres Freund wrote:
> IMO this should replace the existing ascii escape function instead.
That will affect the existing behavior of application_name and
cluster_name; is that acceptable?
--Jacob
Hi,
On 2022-07-19 21:08:53 +0800, Japin Li wrote:
> From b2bcc3a1bac67b8b414f2025607f8dd35e096289 Mon Sep 17 00:00:00 2001
> From: Japin Li
> Date: Tue, 19 Jul 2022 18:27:25 +0800
> Subject: [PATCH v2 1/1] Fix the memory leak in psql describe
>
> ---
> src/bin/psql/describe.c | 168
Hi,
On 2022-07-19 09:07:31 -0700, Jacob Champion wrote:
> On Fri, Jul 15, 2022 at 4:45 PM Andres Freund wrote:
> > On 2022-07-15 14:51:38 -0700, Jacob Champion wrote:
> > > That seems much worse than escaping for this particular patch; if your
> > > cert's Common Name is in (non-ASCII) UTF-8
On Fri, Jul 15, 2022 at 4:45 PM Andres Freund wrote:
> On 2022-07-15 14:51:38 -0700, Jacob Champion wrote:
> > That seems much worse than escaping for this particular patch; if your
> > cert's Common Name is in (non-ASCII) UTF-8 then all you'll see is
> > "CN=?" in the log lines that were
Hi,
On 2022-07-19 14:30:34 +0700, John Naylor wrote:
> I wrote:
>
> > On Mon, Jul 18, 2022 at 9:58 AM Andres Freund wrote:
> > > Hm. Wouldn't it make sense to just use the normal tuple deforming
> routines and
> > > then map the results to the structs?
> >
> > I wasn't sure if they'd be
On 18.07.22 18:08, Tom Lane wrote:
I'm kind of tempted to mount an effort to get rid of as many of
pathnodes.h's "read_write_ignore" annotations as possible. Some are
necessary to prevent infinite recursion, and others represent considered
judgments that they'd bloat node dumps more than
Hello all,
While investigating a problem in a PG14 instance I noticed that autovacuum
workers
stop processing other databases when a database has a temporary table with
age
older than `autovacuum_freeze_max_age`. To test that I added a custom
logline showing
which database the about to spawned
Hi,
On 2022-07-19 17:37:11 +0200, Pavel Stehule wrote:
> út 19. 7. 2022 v 17:31 odesílatel Andres Freund napsal:
>
> > Hi,
> >
> > On 2022-07-19 16:28:07 +0200, Alvaro Herrera wrote:
> > > Anyway, the minimal patch that makes plpgsql_check tests pass is
> > > attached. This seems a bit random.
Hi
út 19. 7. 2022 v 17:31 odesílatel Andres Freund napsal:
> Hi,
>
> On 2022-07-19 16:28:07 +0200, Alvaro Herrera wrote:
> > Anyway, the minimal patch that makes plpgsql_check tests pass is
> > attached. This seems a bit random. Maybe it'd be better to have a
> > plpgsql_internal.h with
Hi,
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 ExecInterpExpr() or if I've
> missed some tool that can be used instead?
The easiest way is to just call an external function
Hi,
On 2022-07-19 16:28:07 +0200, Alvaro Herrera wrote:
> Anyway, the minimal patch that makes plpgsql_check tests pass is
> attached. This seems a bit random. Maybe it'd be better to have a
> plpgsql_internal.h with functions that are exported only for plpgsql
> itself, and keep plpgsql.h with
Alvaro Herrera writes:
> Thanks, pushed.
Pushed the original patch now too.
regards, tom lane
Hi
út 19. 7. 2022 v 16:28 odesílatel Alvaro Herrera
napsal:
> [ Redirecting thread to -hackers from -committers ]
>
> On 2022-Jul-19, Tom Lane wrote:
>
> > Alvaro Herrera writes:
>
> > > Do you just need to send a patch to add an exports.txt file to
> > > src/pl/plpgsql/src/ for these
On Tue, Jul 19, 2022 at 04:28:07PM +0200, Alvaro Herrera wrote:
> ... oh, and:
>
> $ postmaster -c shared_preload_libraries=plugin_debugger
> 2022-07-19 16:27:24.006 CEST [742142] FATAL: cannot request additional
> shared memory outside shmem_request_hook
This has been reported multiple times
[ Redirecting thread to -hackers from -committers ]
On 2022-Jul-19, Tom Lane wrote:
> Alvaro Herrera writes:
> > Do you just need to send a patch to add an exports.txt file to
> > src/pl/plpgsql/src/ for these functions?
>
> The precedent of plpython says that PGDLLEXPORT markers are
Robert Haas writes:
> On Tue, Jul 19, 2022 at 9:53 AM Andrew Dunstan wrote:
>> Why not have an optional second parameter for array_shuffle that
>> indicates whether or not to flatten? e.g. array_shuffle(my_array,
>> flatten => true)
> IMHO, if we think that's something many people are going to
On Tue, Jul 19, 2022 at 9:25 PM Amit Kapila wrote:
>
> On Tue, Jul 19, 2022 at 1:10 PM Masahiko Sawada wrote:
> >
> > On Mon, Jul 18, 2022 at 8:49 PM Amit Kapila wrote:
> > >
> > > On Sun, Jul 17, 2022 at 6:29 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Fri, Jul 15, 2022 at 3:32 PM
On Tue, Jul 19, 2022 at 9:53 AM Andrew Dunstan wrote:
> > Having thought about it, i would go with (2). It gives the user the
> > ability to decide wether or not array-of-arrays behavior is desired.
> > If he wants the behavior of (1) he can flatten the array before
> > applying array_shuffle().
On 2022-07-19 Tu 07:15, Martin Kalcher wrote:
> Am 18.07.22 um 23:48 schrieb Martin Kalcher:
>>
>> If we go with (1) array_shuffle() and array_sample() should shuffle
>> each element individually and always return a one-dimensional array.
>>
>> select array_shuffle('{{1,2},{3,4},{5,6}}');
>>
Thomas Munro writes:
> The reason we need it for macOS is that they have had fdatasync
> function for many years now, and configure detects it, but they
> haven't ever declared it in a header, so we (accidentally?) do it in
> c.h. We didn't set that up for Apple! The commit that added it was
>
On Tue, 19 Jul 2022 at 20:32, Michael Paquier wrote:
> On Tue, Jul 19, 2022 at 06:41:13PM +0800, Japin Li wrote:
>> After looking around, I found psql/describe.c also has some memory leaks,
>> attached a patch to fix these leaks.
>
> Indeed. There are quite a bit of them, so let's fix all that.
On Mon, Jul 18, 2022 at 6:43 PM Tom Lane wrote:
> Um ... why is "the order in which the elements were chosen" a concept
> we want to expose? ISTM sample() is a black box in which notionally
> the decisions could all be made at once.
I agree with that. But I also think it's fine for the elements
On Tue, Jul 19, 2022 at 02:31:28PM +0200, Alvaro Herrera wrote:
> Hmm, +1, though a few of these are still missing ending periods after
> your patch.
+1.
--
Michael
signature.asc
Description: PGP signature
On Tue, Jul 19, 2022 at 2:01 PM Masahiko Sawada wrote:
>
> On Tue, Jul 19, 2022 at 4:35 PM Kyotaro Horiguchi
> wrote:
>
> >
> >
> > + Assert((xcnt > 0) && (xcnt == rb->catchange_ntxns));
> >
> > (xcnt > 0) is obvious here (otherwise means dlist_foreach is broken..).
> > (xcnt ==
Hi!
Improved my patch by adding block subtransactions.
The block size is determined by the REPLAY_BUFFER_SIZE parameter.
I used the idea of a buffer for accumulating tuples in it.
If we read REPLAY_BUFFER_SIZE rows without errors, the subtransaction will
be committed.
If we find an error, the
On Tue, Jul 19, 2022 at 4:44 AM Morris de Oryx wrote:
> My reason for xmax() in the result is to break down the affected rows count
> into an insert count, and a modified estimate. Not super critical, but
> helpful. I've built out some simple custom logging table in out system for
> this kind
On Tue, Jul 19, 2022 at 06:41:13PM +0800, Japin Li wrote:
> After looking around, I found psql/describe.c also has some memory leaks,
> attached a patch to fix these leaks.
Indeed. There are quite a bit of them, so let's fix all that. You
have missed a couple of code paths in
On 2022-Jul-19, Justin Pryzby wrote:
> https://www.postgresql.org/docs/current/error-style-guide.html#id-1.10.6.4.7
>
> git grep 'errdetail("[[:lower:]]'
> git grep 'errdetail(".*".*;' |grep -v '\."'
Hmm, +1, though a few of these are still missing ending periods after
your patch.
--
Álvaro
On Tue, Jul 19, 2022 at 1:10 PM Masahiko Sawada wrote:
>
> On Mon, Jul 18, 2022 at 8:49 PM Amit Kapila wrote:
> >
> > On Sun, Jul 17, 2022 at 6:29 PM Masahiko Sawada
> > wrote:
> > >
> > > On Fri, Jul 15, 2022 at 3:32 PM shiy.f...@fujitsu.com
> > > wrote:
> > > >
> > >
> > > I've attached
Most of these are new in v15.
In any case, I'm not sure if the others ought to be backpatched.
There may be additional fixes to make with the same grepping.
>From a33bd79c2f36046463489fbd37c76d7f0c3f7a8e Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Mon, 18 Jul 2022 13:54:38 -0500
Subject:
On Tue, Apr 26, 2022 at 6:31 AM Michael Paquier wrote:
>
> On Mon, Apr 25, 2022 at 01:34:38PM -0700, Nathan Bossart wrote:
> > I took another look at the example output, and I think I agree that logging
> > the total time for logical decoding operations is probably the best path
> > forward.
On Tue, Jul 19, 2022 at 1:43 PM Kyotaro Horiguchi
wrote:
>
> At Tue, 19 Jul 2022 16:57:14 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > At Tue, 19 Jul 2022 16:02:26 +0900, Masahiko Sawada
> > wrote in
> > > On Tue, Jul 19, 2022 at 1:47 PM Amit Kapila
> > > wrote:
> > > > Good work. I wonder
Hi,
On Tue, Jul 19, 2022 at 4:09 AM Andrew Dunstan wrote:
> On 2022-07-15 Fr 17:07, Andres Freund wrote:
> > Perhaps you could post your current state? I might be able to help resolving
> > some of the problems.
>
> Ok. Here is the state of things. This has proved to be rather more
> intractable
On Mon, Jul 18, 2022 at 9:46 PM vignesh C wrote:
>
> I have updated the patch to handle the origin value case
> insensitively. The attached patch has the changes for the same.
>
Thanks, the patch looks mostly good to me. I have made a few changes
in 0001 patch which are as follows: (a) make a
Kenaniah Cerny wrote:
> Rebased yet again...
>
> On Mon, Jul 4, 2022 at 1:17 PM Kenaniah Cerny wrote:
> The "unsafe_tests" directory is where the pre-existing role tests were
> located. According to the readme of the "unsafe_tests" directory, the tests
> contained within are not run during
Am 18.07.22 um 23:48 schrieb Martin Kalcher:
If we go with (1) array_shuffle() and array_sample() should shuffle each
element individually and always return a one-dimensional array.
select array_shuffle('{{1,2},{3,4},{5,6}}');
---
{1,4,3,5,6,2}
select
On Tue, 19 Jul 2022 at 17:02, tanghy.f...@fujitsu.com
wrote:
> Hi
>
> I think there is a newly introduced memory leak in your patch d2d3547.
> Try to fix it in the attached patch.
> Kindly to have a check.
>
Yeah, it leaks, and the patch can fix it.
After looking around, I found
1 - 100 of 122 matches
Mail list logo
