On Tue, Aug 10, 2021 at 10:27 PM Greg Nancarrow wrote:
>
> On Tue, Aug 10, 2021 at 3:07 PM Masahiko Sawada wrote:
> >
> > I've attached the latest patches that incorporated all comments I got
> > so far. Please review them.
> >
>
> Some initial review comments on the v6-0001 patch:
Thanks for
On Wed, 11 Aug 2021 at 09:17, Dilip Kumar wrote:
>
> On Tue, Aug 10, 2021 at 10:49 PM Mahendra Singh Thalor
> wrote:
>
> > I checked this and found that we already have one process "stats
> > collector" and in v02 patch, we are sending requests to collect stats
> > two times. I don't know how
On Tue, Aug 10, 2021 at 8:08 PM Alvaro Herrera wrote:
>
> On 2021-Jul-30, Amit Kapila wrote:
>
> Reading Dilip's last posted patch that day, I had some reservations
> about the API of ExtractReplicaIdentity. The new argument makes for a
> very strange to explain behavior "return the key values
On 2021/08/05 18:02, Yugo NAGATA wrote:
this is a no-op because finishCon() is already called at CSTATE_ABORTED or
CSTATE_FINISHED. Therefore, in the end, the disconnection delay is not
measured even in v13.
Yes, but I was thinking that's a bug that we should fix.
IOW, I was thinking that,
Back in March 2016, e06a38965 added support for parallel aggregation.
IIRC, because it was fairly late in the release cycle, I dropped
parallel DISTINCT to reduce the scope a little. It's been on my list
of things to fix since then. I just didn't get around to it until
today.
The patch is just
On Tue, Aug 10, 2021 at 8:36 PM Tom Lane wrote:
> "=?UTF-8?B?5a2Z6K+X5rWpKOaAneaJjSk=?="
> writes:
> > we can use regular expressions (<>|!=) to cover "<>" and "!=".
> There is no
> > need to have two definitions less_greater and not_equals, because it
> will confuse developer.
> > So, we
On Tue, Aug 10, 2021 at 10:49 PM Mahendra Singh Thalor
wrote:
> I checked this and found that we already have one process "stats
> collector" and in v02 patch, we are sending requests to collect stats
> two times. I don't know how costly one call is but I feel that we can
> avoid the 2nd call by
"=?UTF-8?B?5a2Z6K+X5rWpKOaAneaJjSk=?=" writes:
> we can use regular expressions (<>|!=) to cover "<>" and "!=". There is
> no
> need to have two definitions less_greater and not_equals, because it will
> confuse developer.
> So, we can use only not_equals to cover this operator set.
I do
we can use regular expressions (<>|!=) to cover "<>" and "!=". There is no
need to have two definitions less_greater and not_equals, because it will
confuse developer.
So, we can use only not_equals to cover this operator set.
Please review my patch.
Thanks.
On Tue, Aug 10, 2021 at 10:57 PM Greg Sabino Mullane wrote:
>
> On Fri, Jul 16, 2021 at 9:40 AM Tom Lane wrote:
>>
>> That would require pg_restore to try to edit the DROP commands during
>> restore, which sounds horribly fragile. I'm inclined to think that
>> supporting this option only during
On 8/10/21 10:26 PM, Andrew Dunstan wrote:
> On 8/10/21 10:13 PM, Mark Dilger wrote:
>>> On Aug 10, 2021, at 7:11 PM, Andrew Dunstan wrote:
>>>
>>> If we were publishing them on CPAN that would be reasonable. But we're
>>> not, nor are we likely to, I believe.
>> I'm now trying to understand
On 8/10/21 10:13 PM, Mark Dilger wrote:
>
>> On Aug 10, 2021, at 7:11 PM, Andrew Dunstan wrote:
>>
>> If we were publishing them on CPAN that would be reasonable. But we're
>> not, nor are we likely to, I believe.
> I'm now trying to understand the purpose of the renaming. I thought the
>
On 8/10/21 9:25 PM, Michael Paquier wrote:
> On Tue, Aug 10, 2021 at 11:02:13AM -0400, Andrew Dunstan wrote:
>> I can live with that. I guess to be consistent we would also rename
>> PostgresVersion to PgVersion
> Are RewindTest.pm and SSLServer.pm things you are considering for a
> renaming as
> On Aug 10, 2021, at 7:11 PM, Andrew Dunstan wrote:
>
> If we were publishing them on CPAN that would be reasonable. But we're
> not, nor are we likely to, I believe.
I'm now trying to understand the purpose of the renaming. I thought the
problem was that RPM packagers wanted something
On 8/10/21 9:37 PM, Mark Dilger wrote:
>
>> On Aug 10, 2021, at 7:10 AM, Andrew Dunstan wrote:
>>
>> use PgTest::Utils;
>> use PgTest::PostgresNode;
> Checking CPAN, it seems there are three older modules with names starting
> with "Postgres":
>
> Postgres
>
On Wed, Aug 11, 2021 at 9:37 AM Mark Dilger
wrote:
>
> > On Aug 10, 2021, at 7:10 AM, Andrew Dunstan wrote:
> >
> > use PgTest::Utils;
> > use PgTest::PostgresNode;
>
> Checking CPAN, it seems there are three older modules with names starting
> with "Postgres":
>
> Postgres
>
> On Aug 10, 2021, at 7:10 AM, Andrew Dunstan wrote:
>
> use PgTest::Utils;
> use PgTest::PostgresNode;
Checking CPAN, it seems there are three older modules with names starting with
"Postgres":
Postgres
Postgres::Handler
Postgres::Handler::HTML
It would be
On Tue, Aug 10, 2021 at 11:02:13AM -0400, Andrew Dunstan wrote:
> I can live with that. I guess to be consistent we would also rename
> PostgresVersion to PgVersion
Are RewindTest.pm and SSLServer.pm things you are considering for a
renaming as well? It may be more consistent to put everything
On Mon, Aug 09, 2021 at 07:00:02PM +0100, Dagfinn Ilmari Mannsåker wrote:
> Thanks for the review. Updated patch attached, with the CURRENT/SESSION
> ROLE/USER changes for other commands separated out.
+#define Query_for_list_of_owner_roles \
+Query_for_list_of_roles \
" UNION ALL SELECT
On Wed, Jun 23, 2021 at 7:19 AM Andrey V. Lepikhov
wrote:
> Ivan Frolkov reported a problem with choosing a non-optimal index during
> a query optimization. This problem appeared after building of an
> extended statistics.
Any thoughts on this, Tomas?
--
Peter Geoghegan
On Tue, Aug 10, 2021 at 09:36:14AM +0200, Daniel Gustafsson wrote:
> I personally think the increased readability and usability from what we have
> today warrants the changes. Is it the use of .SECONDARY or the change in the
> global Makefile you object to (or both)?
The part I am mainly
On Thu, Jul 15, 2021 at 9:41 AM Simon Riggs
wrote:
> It would be very desirable to allow Hash Indexes to become Primary Key
> Indexes, which requires both
> amroutine->amcanunique = true;
> amroutine->amcanmulticol = true;
Why do you say that? I don't think it's self-evident that it's
On Tue, Aug 10, 2021 at 11:30:35AM -0400, Tom Lane wrote:
> Greg Stark writes:
>> While fixing up a patch I had dealing with temporary tables I noticed
>> a bit of a quirk with pg_temp schemas. Namely that we have no actual
>> meta data marking them as temporary aside from their names. And we
>>
On Tue, Aug 10, 2021 at 09:31:37AM +0200, Michael Meskes wrote:
>> that it could be a good thing. declare.pgc seems to rely on that
>> already but the tests are incorrect as I mentioned in [2]. For
>> DESCRIBE, that provides data about a result set, I find the
>> assignment
>> of a connection a
On Wed, Aug 11, 2021 at 7:07 AM Thomas Munro wrote:
> On Wed, Aug 11, 2021 at 2:12 AM Andres Freund wrote:
> > On Tue, Aug 10, 2021, at 15:19, Thomas Munro wrote:
> > > Yeah, make check always fails for me on macOS 11. With the attached
> > > experimental hack, it fails only occasionally (1 in
On 8/9/21 9:19 PM, Mark Dilger wrote:
On Jul 20, 2021, at 11:28 AM, Tomas Vondra
wrote:
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
<0001-Handling-Expr-op-Expr-clauses-in-extended-stats-20210720.patch>
Hi Tomas,
I tested this patch against
On 2021-Aug-09, Alvaro Herrera wrote:
> > 3) What is the goal of the autovac_refresh_stats() after the loop doing
> >pgstat_report_anl_ancestors()? I think it'll be common that the stats
> >collector hasn't even processed the incoming messages by that point, not
> > to
> >speak of
On Tue, Aug 10, 2021 at 12:04 PM Robert Haas wrote:
> On Tue, Mar 9, 2021 at 10:09 AM David G. Johnston
> wrote:
> > Frankly, I am hoping for a bit more constructive feedback and even
> collaboration from a committer, specifically Tom, on this one given the
> outstanding user complaints
On 2021-Aug-10, Alvaro Herrera wrote:
> I bring a radical proposal that may be sufficient to close this
> particular hole. What if we made partition only affected their
> top-level parents to become auto-analyzed, and not any intermediate
> ancestors? Any intermediate partitioned partitions
On Tue, Aug 10, 2021 at 1:46 PM Andrew Dunstan wrote:
> No, you're right, although I think it's implied. Maybe we need a
> statement along these lines:
I agree with that, but to me it's more in the scope of what is
expected of committers in general. At a very high level. So it's not
something
Hi,
On Tue, Aug 10, 2021 at 11:13:03AM +0200, Daniel Gustafsson wrote:
> > On 10 Aug 2021, at 11:10, Andreas Karlsson wrote:
> > What is he reason you want to add ^= is there any other databases
> > which uses ^= for inequality?
>
> I assume it's because of Oracle compatibility which AFAIK is
On 10/08/21 8:27 pm, 孙诗浩(思才) wrote:
Hi everyone,
I am doding some jobs in postgres. I want to add "^=" like "!=" and "<>".
One problem is that '^' & '^=' is already used as the exclusive OR
operator in programming languages such as: C, Java, JavaScript, and
Python. See:
On Thu, Aug 5, 2021 at 6:20 AM Paul Guo wrote:
> Rebased.
The commit message for 0001 is not clear enough for me to understand
what problem it's supposed to be fixing. The code comments aren't
really either. They make it sound like there's some problem with
copying symlinks but mostly they just
On 8/10/21 2:16 PM, Michael Meskes wrote:
>> Agreed. How is this, which already exists?
>>
>> https://wiki.postgresql.org/wiki/Release_Management_Team
> That I know, but I don't think it covers the issues we, or I, had up-
> thread. Or do I miss something?
No, you're right, although I
Reviving this thread
2021-08-10 19:05:09.096 UTC [3738] LOG: logical replication apply
worker for subscription "sub_mycluster_alltables" has started
2021-08-10 19:05:09.107 UTC [3739] LOG: logical replication table
synchronization worker for subscription "sub_mycluster_alltables",
table
On Wed, Aug 11, 2021 at 2:12 AM Andres Freund wrote:
> On Tue, Aug 10, 2021, at 15:19, Thomas Munro wrote:
> > Yeah, make check always fails for me on macOS 11. With the attached
> > experimental hack, it fails only occasionally (1 in 8 runs or so). I
> > don't know why.
>
> I suspect you'd
On Tue, Mar 9, 2021 at 10:09 AM David G. Johnston
wrote:
> Frankly, I am hoping for a bit more constructive feedback and even
> collaboration from a committer, specifically Tom, on this one given the
> outstanding user complaints received on the topic, our disagreement regarding
> fixing it
> Agreed. How is this, which already exists?
>
> https://wiki.postgresql.org/wiki/Release_Management_Team
That I know, but I don't think it covers the issues we, or I, had up-
thread. Or do I miss something?
Speaking of RMT, Andrew, Michael, Peter, will you make the final
decision
On Thu, Mar 4, 2021 at 10:01 PM Kyotaro Horiguchi
wrote:
> The patch assumed that CHKPT_START/COMPLETE barrier are exclusively
> used each other, but MarkBufferDirtyHint which delays checkpoint start
> is called in RelationTruncate while delaying checkpoint completion.
> That is not a strange nor
On Tue, Aug 10, 2021 at 08:05:29PM +0200, Michael Meskes wrote:
> > I think my point was that committers should be required to understand
> > the RMT process, and if we need to communicate that better, let's do
> > that. I don't think it should be the responsibility of RMT members
> > to
> >
> I think my point was that committers should be required to understand
> the RMT process, and if we need to communicate that better, let's do
> that. I don't think it should be the responsibility of RMT members
> to
> communicate the RMT process every time they communicate with someone,
> unless
On Tue, 10 Aug 2021 at 22:32, Mahendra Singh Thalor wrote:
>
> On Tue, 10 Aug 2021 at 21:53, Sadhuprasad Patro wrote:
> >
> > > As of now, we are adding handling inside pg_stat_reset for shared
> > > tables but I think we can add a new function with the name of
> > > pg_stat_reset_shared_tables
On Tue, Aug 10, 2021 at 09:37:19AM +0200, Michael Meskes wrote:
> > I do think all committers need to understand the role of the RMT so
> > they
> > can respond appropriately. Do we need to communicate this better?
>
> Being the one who assumed a different procedure, yes please. :)
I think my
On Tue, 10 Aug 2021 at 21:53, Sadhuprasad Patro wrote:
>
> > As of now, we are adding handling inside pg_stat_reset for shared
> > tables but I think we can add a new function with the name of
> > pg_stat_reset_shared_tables to reset stats for all the shared tables.
> > New function will give
> As of now, we are adding handling inside pg_stat_reset for shared
> tables but I think we can add a new function with the name of
> pg_stat_reset_shared_tables to reset stats for all the shared tables.
> New function will give more clarity to the users also. We already have
> a
> 3) I am attaching a .sql file. We can add similar types of test cases for
> shared tables.
> Ex: first reset stats for all shared tables using pg_stat_reset and then
> check stats for all shared tables(all should be zero)
Adding a new test case for this looks difficult as results are not
Greg Stark writes:
> While fixing up a patch I had dealing with temporary tables I noticed
> a bit of a quirk with pg_temp schemas. Namely that we have no actual
> meta data marking them as temporary aside from their names. And we
> don't do anything to protect that -- superuser can happily issue
Michael Paquier writes:
> Regarding 0002, I am not sure. Even if this reduces a lot of
> duplication, which is really nice, enforcing .SECONDARY to not trigger
> with a change impacting Makefile.global.in does not sound very
> appealing to me in the long-run, TBH.
Yeah, I don't like that change
On Tue, Aug 10, 2021 at 9:28 AM Nitin Jadhav
wrote:
> Please find the updated patch attached.
I think this is getting close. The output looks nice. However, I still
see a bunch of issues.
You mentioned previously that you would add documentation, but I do
not see it here.
Amit Kapila writes:
> On Tue, Jul 27, 2021 at 11:29 PM Mark Dilger
> wrote:
>> The documentation for ALTER PUBLICATION ... OWNER TO ... claims the new
>> owner must have CREATE privilege on the database, though superuser can
>> change the ownership in spite of this restriction. No explanation
On 2021/08/10 21:22, torikoshia wrote:
I have updated the patch in this way.
Thanks for updating the patch!
In this patch, getting the plan to the DO statement is as follows.
Looks good to me.
Any thoughts?
+ ereport(LOG_SERVER_ONLY,
+ (errmsg("plan of
> On Aug 9, 2021, at 7:20 PM, Tom Lane wrote:
>
> So I took another look at the code, and it doesn't seem that hard
> to make it act this way. The attached passes regression, but
> I've not beat on it with random strings.
I expect to get back around to testing this in a day or so.
—
Mark
I wrote:
> So AFAICS Perl is acting in the way I'm attributing to POSIX.
> But maybe we should actually read POSIX ...
I went to look at the POSIX spec, and was reminded that it lacks
backrefs altogether. (POSIX specifies the "BRE" and "ERE" regex
flavors as described in our docs, but not
While fixing up a patch I had dealing with temporary tables I noticed
a bit of a quirk with pg_temp schemas. Namely that we have no actual
meta data marking them as temporary aside from their names. And we
don't do anything to protect that -- superuser can happily issue ALTER
SCHEMA RENAME to
On 8/10/21 10:40 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> I will undertake to do the work, once we get the bike-shedding part done.
>> I'll kick that off by suggesting we move all of these to the namespace
>> PgTest, and rename TestLib to Utils, so instead of
>> use TestLib;
>>
On Fri, Jul 16, 2021 at 9:40 AM Tom Lane wrote:
> That would require pg_restore to try to edit the DROP commands during
> restore, which sounds horribly fragile. I'm inclined to think that
> supporting this option only during initial dump is safer.
>
Safer, but not nearly as useful. Maybe see
Apologies, just saw this. I found no problems, those "failures" were just
me missing checkboxes on the commitfest interface. +1 on the patch.
Cheers,
Greg
sob., 19 cze 2021 o 12:14 Amit Kapila napisał(a):
>
> On Fri, Jun 18, 2021 at 11:22 AM Kyotaro Horiguchi
> wrote:
> >
> > At Thu, 17 Jun 2021 12:56:42 -0400, Alvaro Herrera
> > wrote in
> > > On 2021-Jun-17, Kyotaro Horiguchi wrote:
> > >
> > > > I don't see a call to hash_*seq*_search there.
On 2021-Aug-10, Andrew Dunstan wrote:
> I'll kick that off by suggesting we move all of these to the namespace
> PgTest, and rename TestLib to Utils, so [...] you would say
>
> use PgTest::Utils;
> use PgTest::PostgresNode;
WFM.
--
Álvaro Herrera Valdivia, Chile —
Andrew Dunstan writes:
> I will undertake to do the work, once we get the bike-shedding part done.
> I'll kick that off by suggesting we move all of these to the namespace
> PgTest, and rename TestLib to Utils, so instead of
> use TestLib;
> use PostgresNode;
> you would say
> use
On 2021-Jul-30, Amit Kapila wrote:
> I was thinking of using toast pointer but that won't work because it
> can be different on the subscriber-side. I don't see any better ideas
> to fix this issue. This problem seems to be from the time Logical
> Replication has been introduced, so adding others
Hi,
On Tue, Aug 10, 2021, at 15:19, Thomas Munro wrote:
> On Tue, Aug 10, 2021 at 5:43 AM Robert Haas wrote:
> > On Mon, Aug 9, 2021 at 1:30 PM Alvaro Herrera
> > wrote:
> > > How common is to get a failure? I know I've run tests under
> > > EXEC_BACKEND and not seen any failures. Not many
On 5/20/21 5:18 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> While solving a problem with the Beta RPMs, I noticed that they export
>> our perl test modules as capabilities like this:
>> [andrew@f34 x86_64]$ rpm -q --provides -p
>> postgresql14-devel-14-beta1_PGDG.fc34.x86_64.rpm |
On Mon, Aug 9, 2021 at 9:23 PM Noah Misch wrote:
> > I don't presently have a specific idea about how to fix this.
>
> Can't recovery just not delete the directory, create it if doesn't exist, and
> be happy if it does exist? Like the attached WIP. If we think it's possible
> for a crash during
> I'd really like to avoid this. I don't see why it's necessary. You say
> it causes a problem, but you don't explain what problem it causes.
> enable_timeout_at() will disable the timer if not already done. I
> think all we need to do is set scheduled_startup_progress_timeout = 0
> before calling
On 2021-Aug-09, Andres Freund wrote:
> I don't agree. There's a difference between this happening after a manual
> ANALYZE on partition roots, and this continuously happening in production
> workloads due to auto-analyzes...
Hmm. That's not completely untrue.
I bring a radical proposal that
> On 6 Aug 2021, at 21:17, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> Until there is an animal running OpenSSL 3.0.0 in the buildfarm I think this
>> should be HEAD only. Further down the line we need to support OpenSSL 3 in
>> all
>> backbranches IMO since they are all equally likely
On Tue, Aug 10, 2021 at 3:07 PM Masahiko Sawada wrote:
>
> I've attached the latest patches that incorporated all comments I got
> so far. Please review them.
>
Some initial review comments on the v6-0001 patch:
src/backend/replication/logical/proto.c:
(1)
+ TimestampTz committs;
I think it
On Tue, Aug 10, 2021 at 5:43 AM Robert Haas wrote:
> On Mon, Aug 9, 2021 at 1:30 PM Alvaro Herrera wrote:
> > How common is to get a failure? I know I've run tests under
> > EXEC_BACKEND and not seen any failures. Not many runs though.
>
> On macOS, failures are extremely common. Sometimes I
On Fri, Jul 23, 2021 at 6:16 PM Simon Riggs
wrote:
>
> On Thu, 22 Jul 2021 at 06:10, Amit Kapila wrote:
> Complete patch for hash_multicol.v3.patch attached, slightly updated
> from earlier patch.
> Docs, tests, passes make check.
I was looking into the hash_multicoul.v3.patch, I have a
On 2021-07-28 20:44, torikoshia wrote:
On 2021-07-28 03:45, Pavel Stehule wrote:
út 27. 7. 2021 v 20:34 odesílatel Fujii Masao
napsal:
On 2021/07/09 14:05, torikoshia wrote:
On 2021-07-02 23:21, Bharath Rupireddy wrote:
On Tue, Jun 22, 2021 at 8:00 AM torikoshia
wrote:
Updated the
Ranier Vilela писал 2021-08-10 14:21:
Em ter., 10 de ago. de 2021 às 05:53, Yura Sokolov
escreveu:
I went to check SH_GROW and It is `SH_GROW(SH_TYPE *tb, uint32
newsize)`
:-(((
Therefore when `tb->size == SH_MAX_SIZE/2` and we call `SH_GROW(tb,
tb->size * 2)`,
then SH_GROW(tb, 0) is
On Mon, Aug 9, 2021 at 11:31 AM vignesh C wrote:
>
> On Fri, Aug 6, 2021 at 2:00 PM Masahiko Sawada wrote:
> >
> > ---
> > Suppose that a parent table and its child table are defined in
> > different schemas, there is a publication for the schema where only
> > the parent table is defined, and
Em ter., 10 de ago. de 2021 às 05:53, Yura Sokolov
escreveu:
> Good day, hackers.
>
> Our client caught process stuck in tuplehash_grow. There was a query
> like
> `select ts, count(*) from really_huge_partitioned_table group by ts`,
> and
> planner decided to use hash aggregation.
>
> Backtrace
On Tue, Aug 10, 2021 at 3:29 PM Amit Kapila wrote:
>
> On Tue, Aug 10, 2021 at 10:37 AM Masahiko Sawada
> wrote:
> >
> > I've attached the latest patches that incorporated all comments I got
> > so far. Please review them.
> >
>
> I am not able to apply the latest patch
>
Le mar. 10 août 2021 à 18:41, Daniel Gustafsson a écrit :
> > On 10 Aug 2021, at 12:21, David Rowley wrote:
> >
> > I'm strongly against inheriting warts from Oracle for apparently good
> > reason. At the very least, anyone who's using ^= for some other
> > purpose is very likely to be upset
> On 10 Aug 2021, at 12:21, David Rowley wrote:
>
> On Tue, 10 Aug 2021 at 21:13, Daniel Gustafsson wrote:
>>
>>> On 10 Aug 2021, at 11:10, Andreas Karlsson wrote:
>>
>>> What is he reason you want to add ^= is there any other databases which
>>> uses ^= for inequality?
>>
>> I assume it's
On Tue, 10 Aug 2021 at 21:13, Daniel Gustafsson wrote:
>
> > On 10 Aug 2021, at 11:10, Andreas Karlsson wrote:
>
> > What is he reason you want to add ^= is there any other databases which
> > uses ^= for inequality?
>
> I assume it's because of Oracle compatibility which AFAIK is the only
On Tue, Aug 10, 2021 at 11:59 AM Amit Kapila wrote:
>
> On Tue, Aug 10, 2021 at 10:37 AM Masahiko Sawada
> wrote:
> >
> > I've attached the latest patches that incorporated all comments I got
> > so far. Please review them.
> >
>
> I am not able to apply the latest patch
>
On Tue, 10 Aug 2021 at 20:53, Yura Sokolov wrote:
> EXPLAIN shows that there are 2604186278 rows in all partitions, but
> planner
> thinks there will be only 200 unique rows after group by. Looks like we
> was
> mistaken.
This looks unrelated. Looks like the planner used DEFAULT_NUM_DISTINCT.
Dear Meskes and any hackers,
> Yes, at least technically. I think DESCRIBE should accept the cached
> connection name, although it won't really matter.
I sought docs too and I found that Pro*C have such a same policy,
so it might be reasonable:
> On 10 Aug 2021, at 11:10, Andreas Karlsson wrote:
> What is he reason you want to add ^= is there any other databases which uses
> ^= for inequality?
I assume it's because of Oracle compatibility which AFAIK is the only database
supporting ^=.
--
Daniel Gustafsson
On 8/10/21 10:27 AM, 孙诗浩(思才) wrote:
Before send patch review, I want to konw whether the postgres maintainer
will approve my changes.
So, please give me some advice.
Welcome!
I do not think that is a feature which will get much interest from the
developers since it is unclear to me what
Good day, hackers.
Our client caught process stuck in tuplehash_grow. There was a query
like
`select ts, count(*) from really_huge_partitioned_table group by ts`,
and
planner decided to use hash aggregation.
Backtrace shows that oldsize were 2147483648 at the moment. While
newsize
were
Le 30/07/2021 à 23:49, Tom Lane a écrit :
Andres Freund writes:
On 2021-07-30 13:58:51 -0400, Tom Lane wrote:
I've not read this version of the patch, but I see from the cfbot's
results that it's broken postgres_fdw.
I think this may partially be an issue with the way that postgres_fdw
uses
Hi everyone,
I am doding some jobs in postgres. I want to add "^=" like "!=" and "<>".
So i modify the code in scan.l.
Plan 1:
equals_greater "=>"
less_equals "<="
greater_equals ">="
less_greater "<>"
not_equals (!=|\^=)
Maybe i can delete some code to make the code more simple.
Plan 2:
Le 31/07/2021 à 01:28, Andres Freund a écrit :
I'm *very* unconvinced it makes sense to implement a feature like this
in an extension / that we should expose API for that purpose. To me the
top-level transaction state is way too tied to our internals for it to
be reasonably dealt with in an
On Fri, Aug 6, 2021 at 6:32 PM vignesh C wrote:
>
> Thanks for the comments, the attached v19 patch has the fixes for the
> comments.
>
Some more review comments, this time for the v19 patch:
(1) In patch v19-0002, there's still a couple of instances where it
says "publication type" instead
> I do think all committers need to understand the role of the RMT so
> they
> can respond appropriately. Do we need to communicate this better?
Being the one who assumed a different procedure, yes please. :)
Thanks,
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot
> On 10 Aug 2021, at 09:22, Michael Paquier wrote:
>
> On Fri, Jul 30, 2021 at 03:11:49PM +, Jacob Champion wrote:
>> No worries, it's easy enough to unroll the expansion manually. The
>> annoyances without secondary expansion are the duplicated lines for
>> each individual CA and the need
> Okay. So you mean to change DESCRIBE and DEALLOCATE to be able to
> handle cached connection names, as of [1]? For [DE]ALLOCATE, I agree
Yes, at least technically. I think DESCRIBE should accept the cached
connection name, although it won't really matter.
> that it could be a good thing.
Peter,
> I think that there was a snowballing effect here. We both made
> mistakes that compounded. I apologize for my role in this whole mess.
Completely agreed. I think we both took things for granted that the
other one didn't take into account at all. I'm sorry about that, too.
Michael
On Fri, Jul 30, 2021 at 03:11:49PM +, Jacob Champion wrote:
> No worries, it's easy enough to unroll the expansion manually. The
> annoyances without secondary expansion are the duplicated lines for
> each individual CA and the need to introduce .INTERMEDIATE targets so
> that cleanup works as
On Fri, Jul 30, 2021 at 11:22:43AM -0400, Tom Lane wrote:
> Happy to make it so. Anyone have suggestions about the wording of
> the message?
For the archives, this has been applied as of ef12f32, and the new
message seems explicit enough:
+ if (unlikely(portal == NULL))
+ elog(ERROR,
On Tue, Aug 03, 2021 at 01:58:44AM +, shinya11.k...@nttdata.com wrote:
> In the discussion of [1], the option ASENSITIVE was added to DECLARE.
> I have improved its tab completion and attached a patch.
>
> Do you think?
Thanks, fixed.
--
Michael
signature.asc
Description: PGP signature
On Mon, Aug 09, 2021 at 11:07:14AM -0400, Robert Haas wrote:
> On Thu, Aug 5, 2021 at 8:02 PM Tom Lane wrote:
>> I think doing nothing is fine. Given the lack of complaints, we're
>> more likely to break something than fix anything useful.
>
> +1.
FWIW, the only interesting case I have in my
On Tue, Aug 10, 2021 at 10:37 AM Masahiko Sawada wrote:
>
> I've attached the latest patches that incorporated all comments I got
> so far. Please review them.
>
I am not able to apply the latest patch
(v6-0001-Add-errcontext-to-errors-happening-during-applyin) on HEAD,
getting the below error:
On Mon, Aug 09, 2021 at 10:50:29PM +0200, Michael Meskes wrote:
>> On the substance of the issue, one question that I have reading over
>> this thread is whether there's really a bug here at all. It is being
>> represented (and I have not checked whether this is accurate) that
>> the
>> patch
On Tue, Jul 27, 2021 at 11:29 PM Mark Dilger
wrote:
>
> The documentation for ALTER PUBLICATION ... OWNER TO ... claims the new owner
> must have CREATE privilege on the database, though superuser can change the
> ownership in spite of this restriction. No explanation is given for this
>
99 matches
Mail list logo
