Re: Table refer leak in logical replication

On Sat, Apr 17, 2021 at 10:32 PM Amit Kapila wrote: > On Fri, Apr 16, 2021 at 11:55 AM Michael Paquier wrote: > > On Tue, Apr 06, 2021 at 02:25:05PM +0900, Amit Langote wrote: > > > > Attached is v5 that I am finishing with. Much more could be done but > > I don't want to do something too invasi

Re: Performance Evaluation of Result Cache by using TPC-DS

On Wed, 14 Apr 2021 at 17:11, Yuya Watari wrote: > I ran query 62 by "EXPLAIN (ANALYZE, TIMING OFF)" and normally. I > attached these execution results to this e-mail. At this time, I > executed each query only once (not twice). The results are as follows. Thanks for running that again. I see fr

Re: [CLOBBER_CACHE]Server crashed with segfault 11 while executing clusterdb

On Mon, Apr 19, 2021 at 12:25 PM Michael Paquier wrote: > > On Fri, Apr 09, 2021 at 06:45:45PM -0400, Alvaro Herrera wrote: > > We forgot this patch earlier in the commitfest. Do people think we > > should still get it in on this cycle? I'm +1 on that, since it's a > > safety feature poised to p

Re: Replication slot stats misgivings

On Mon, Apr 19, 2021 at 2:14 PM Amit Kapila wrote: > > On Mon, Apr 19, 2021 at 9:00 AM Masahiko Sawada wrote: > > > > On Fri, Apr 16, 2021 at 2:58 PM Amit Kapila wrote: > > > > > > > > > 4. > > > +CREATE VIEW pg_stat_replication_slots AS > > > +SELECT > > > +s.slot_name, > > > +

Re: Performance degradation of REFRESH MATERIALIZED VIEW

At Mon, 19 Apr 2021 13:32:31 +0900, Masahiko Sawada wrote in > On Fri, Apr 16, 2021 at 12:16 PM Kyotaro Horiguchi > wrote: > > AFAICS the page is always empty when RelationGetBufferForTuple > > returned a valid vmbuffer. So the "if" should be an "assert" instead. > > There is a chance that Re

Doubt with [ RANGE partition with TEXT datatype ]

Hi All, Please help me out with my doubt in RANGE partition with TEXT datatype: postgres=# create table tab1 (col1 text) PARTITION BY RANGE (col1); CREATE TABLE postgres=# create table p1 (col1 text); CREATE TABLE -- Partition with range from '5' to '10' shows error: postgres=# alter table tab1

Re: Table refer leak in logical replication

On Fri, Apr 16, 2021 at 3:24 PM Michael Paquier wrote: > On Tue, Apr 06, 2021 at 02:25:05PM +0900, Amit Langote wrote: > > While updating the patch to do so, it occurred to me that maybe we > > could move the ExecInitResultRelation() call into > > create_estate_for_relation() too, in the spirit of

Re: logical replication empty transactions

On Thu, Apr 15, 2021 at 4:39 PM Ajin Cherian wrote: > > > > On Thu, Apr 15, 2021 at 1:29 PM Ajin Cherian wrote: >> >> >> I've rebased the patch and made changes so that the patch supports >> "streaming in-progress transactions" and handling of logical decoding >> messages (transactional and non-

Re: Performance degradation of REFRESH MATERIALIZED VIEW

On Mon, Apr 19, 2021 at 5:04 PM Kyotaro Horiguchi wrote: > > At Mon, 19 Apr 2021 13:32:31 +0900, Masahiko Sawada > wrote in > > On Fri, Apr 16, 2021 at 12:16 PM Kyotaro Horiguchi > > wrote: > > > AFAICS the page is always empty when RelationGetBufferForTuple > > > returned a valid vmbuffer. So

Re: Table refer leak in logical replication

On Mon, Apr 19, 2021 at 1:51 PM Amit Langote wrote: > > On Fri, Apr 16, 2021 at 3:24 PM Michael Paquier wrote: > > On Tue, Apr 06, 2021 at 02:25:05PM +0900, Amit Langote wrote: > > > While updating the patch to do so, it occurred to me that maybe we > > > could move the ExecInitResultRelation() c

Re: [CLOBBER_CACHE]Server crashed with segfault 11 while executing clusterdb

At Mon, 19 Apr 2021 12:56:18 +0530, Amul Sul wrote in > On Mon, Apr 19, 2021 at 12:25 PM Michael Paquier wrote: > > > > On Fri, Apr 09, 2021 at 06:45:45PM -0400, Alvaro Herrera wrote: > > > We forgot this patch earlier in the commitfest. Do people think we > > > should still get it in on this c

Re: Doubt with [ RANGE partition with TEXT datatype ]

Hi Prabhat, On Mon, Apr 19, 2021 at 5:13 PM Prabhat Sahu wrote: > > Hi All, > > Please help me out with my doubt in RANGE partition with TEXT datatype: > > postgres=# create table tab1 (col1 text) PARTITION BY RANGE (col1); > CREATE TABLE > > postgres=# create table p1 (col1 text); > CREATE TABLE

Re: Windows default locale vs initdb

po 19. 4. 2021 v 7:43 odesílatel Thomas Munro napsal: > Hi, > > Moving this topic into its own thread from the one about collation > versions, because it concerns pre-existing problems, and that thread > is long. > > Currently initdb sets up template databases with old-style Windows > locale name

Re: Table refer leak in logical replication

On Mon, Apr 19, 2021 at 12:32 PM Amit Langote wrote: > > On Sat, Apr 17, 2021 at 10:32 PM Amit Kapila wrote: > > On Fri, Apr 16, 2021 at 11:55 AM Michael Paquier > > wrote: > > > On Tue, Apr 06, 2021 at 02:25:05PM +0900, Amit Langote wrote: > > > > > > Attached is v5 that I am finishing with.

Re: Doubt with [ RANGE partition with TEXT datatype ]

On Mon, Apr 19, 2021 at 2:16 PM Amit Langote wrote: > Hi Prabhat, > > On Mon, Apr 19, 2021 at 5:13 PM Prabhat Sahu > wrote: > > > > Hi All, > > > > Please help me out with my doubt in RANGE partition with TEXT datatype: > > > > postgres=# create table tab1 (col1 text) PARTITION BY RANGE (col1);

Re: Table refer leak in logical replication

On Mon, Apr 19, 2021 at 6:03 PM Amit Kapila wrote: > On Mon, Apr 19, 2021 at 12:32 PM Amit Langote wrote: > > On Sat, Apr 17, 2021 at 10:32 PM Amit Kapila > > wrote: > > > On Fri, Apr 16, 2021 at 11:55 AM Michael Paquier > > > wrote: > > > > Attached is v5 that I am finishing with. Much more

Re: Table refer leak in logical replication

On Mon, Apr 19, 2021 at 02:33:10PM +0530, Amit Kapila wrote: > On Mon, Apr 19, 2021 at 12:32 PM Amit Langote wrote: >> FWIW, I agree with fixing this bug of 1375422c in as least scary >> manner as possible. Hou-san proposed that we add the ResultRelInfo >> that apply_handle_{insert|update|delete}

Re: Table refer leak in logical replication

On Mon, Apr 19, 2021 at 3:02 PM Michael Paquier wrote: > > On Mon, Apr 19, 2021 at 02:33:10PM +0530, Amit Kapila wrote: > > On Mon, Apr 19, 2021 at 12:32 PM Amit Langote > > wrote: > >> FWIW, I agree with fixing this bug of 1375422c in as least scary > >> manner as possible. Hou-san proposed th

Re: Old Postgresql version on i7-1165g7

Yura Sokolov писал 2021-04-18 23:29: Tom Lane писал 2021-04-13 17:45: Justin Pryzby writes: On Fri, Apr 09, 2021 at 04:28:25PM +0300, Yura Sokolov wrote: Occasinally I found I'm not able to `make check` old Postgresql versions. I've bisected between REL_11_0 and "Rename pg_rewind's copy_fi

Re: Table refer leak in logical replication

On Mon, Apr 19, 2021 at 3:12 PM Amit Kapila wrote: > > On Mon, Apr 19, 2021 at 3:02 PM Michael Paquier wrote: > > > > On Mon, Apr 19, 2021 at 02:33:10PM +0530, Amit Kapila wrote: > > > On Mon, Apr 19, 2021 at 12:32 PM Amit Langote > > > wrote: > > >> FWIW, I agree with fixing this bug of 137542

Re: Table refer leak in logical replication

On Mon, Apr 19, 2021 at 3:25 PM Amit Kapila wrote: > > On Mon, Apr 19, 2021 at 3:12 PM Amit Kapila wrote: > > > > On Mon, Apr 19, 2021 at 3:02 PM Michael Paquier wrote: > > > > > > On Mon, Apr 19, 2021 at 02:33:10PM +0530, Amit Kapila wrote: > > > > On Mon, Apr 19, 2021 at 12:32 PM Amit Langote

Re: Windows default locale vs initdb

On Mon, Apr 19, 2021 at 4:53 AM Pavel Stehule wrote: > > > po 19. 4. 2021 v 7:43 odesílatel Thomas Munro > napsal: > >> Hi, >> >> Moving this topic into its own thread from the one about collation >> versions, because it concerns pre-existing problems, and that thread >> is long. >> >> Currently

Re: Windows default locale vs initdb

po 19. 4. 2021 v 12:52 odesílatel Andrew Dunstan napsal: > > > On Mon, Apr 19, 2021 at 4:53 AM Pavel Stehule > wrote: > >> >> >> po 19. 4. 2021 v 7:43 odesílatel Thomas Munro >> napsal: >> >>> Hi, >>> >>> Moving this topic into its own thread from the one about collation >>> versions, because i

Re: [CLOBBER_CACHE]Server crashed with segfault 11 while executing clusterdb

On Mon, Apr 19, 2021 at 2:05 PM Kyotaro Horiguchi wrote: > > At Mon, 19 Apr 2021 12:56:18 +0530, Amul Sul wrote in > > On Mon, Apr 19, 2021 at 12:25 PM Michael Paquier > > wrote: > > > > > > On Fri, Apr 09, 2021 at 06:45:45PM -0400, Alvaro Herrera wrote: > > > > We forgot this patch earlier in

Re: Replication slot stats misgivings

On Fri, Apr 16, 2021 at 3:16 PM Amit Kapila wrote: > > On Mon, Apr 12, 2021 at 2:57 PM vignesh C wrote: > > > > On Sat, Mar 20, 2021 at 9:26 AM Amit Kapila wrote: > > > > > > On Sat, Mar 20, 2021 at 12:22 AM Andres Freund wrote: > > > > > > > > And then more generally about the feature: > > > >

Re: Performance degradation of REFRESH MATERIALIZED VIEW

On Mon, Apr 19, 2021 at 1:57 PM Masahiko Sawada wrote: > > On Mon, Apr 19, 2021 at 5:04 PM Kyotaro Horiguchi > wrote: > > > > At Mon, 19 Apr 2021 13:32:31 +0900, Masahiko Sawada > > wrote in > > > On Fri, Apr 16, 2021 at 12:16 PM Kyotaro Horiguchi > > > wrote: > > > > AFAICS the page is always

Re: Table refer leak in logical replication

On Mon, Apr 19, 2021 at 7:00 PM Amit Kapila wrote: > On Mon, Apr 19, 2021 at 3:25 PM Amit Kapila wrote: > > On Mon, Apr 19, 2021 at 3:12 PM Amit Kapila wrote: > > > On Mon, Apr 19, 2021 at 3:02 PM Michael Paquier > > > wrote: > > > > On Mon, Apr 19, 2021 at 02:33:10PM +0530, Amit Kapila wrote:

Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:not tested Hi, Andrei I tested your patch, and it works well. I also prefer tim

Re: Reduce the number of special cases to build contrib modules on windows

On Wed, 3 Mar 2021 at 22:37, David Rowley wrote: > I've attached a rebased patch. I've rebased this again. I also moved away from using hash tables for storing references and libraries. I was having some problems getting psql to compile due to the order of the dependencies being reversed due to

Re: Table refer leak in logical replication

On Mon, Apr 19, 2021 at 08:09:05PM +0900, Amit Langote wrote: > On Mon, Apr 19, 2021 at 7:00 PM Amit Kapila wrote: >> It seems like the memory will be freed after we apply the truncate >> because we reset the ApplyMessageContext after applying each message, >> so maybe we don't need to bother abou

Re: [CLOBBER_CACHE]Server crashed with segfault 11 while executing clusterdb

On Mon, Apr 19, 2021 at 04:27:25PM +0530, Amul Sul wrote: > On Mon, Apr 19, 2021 at 2:05 PM Kyotaro Horiguchi > wrote: > > > > At Mon, 19 Apr 2021 12:56:18 +0530, Amul Sul wrote in > > > On Mon, Apr 19, 2021 at 12:25 PM Michael Paquier > > > wrote: > > > > > > > > On Fri, Apr 09, 2021 at 06:45

Re: Table refer leak in logical replication

On Mon, Apr 19, 2021 at 5:20 PM Michael Paquier wrote: > > On Mon, Apr 19, 2021 at 08:09:05PM +0900, Amit Langote wrote: > > On Mon, Apr 19, 2021 at 7:00 PM Amit Kapila wrote: > >> It seems like the memory will be freed after we apply the truncate > >> because we reset the ApplyMessageContext aft

Re: [CLOBBER_CACHE]Server crashed with segfault 11 while executing clusterdb

On Mon, Apr 19, 2021 at 05:35:52PM +0900, Kyotaro Horiguchi wrote: > Isn't this a kind of open item? This does not qualify as an open item because it is not an actual bug IMO, neither is it a defect of the existing code, so it seems appropriate to me to not list it. -- Michael signature.asc Desc

Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements

Hi, Martin On Mon, 2021-04-19 at 11:39 +, Chengxi Sun wrote: > I tested your patch, and it works well. I also prefer timestamp > inseatead of dealloc num. > I think it can provide more useful details about query statements. > Thank you for your review. Certainly, timestamp is valuable here. D

Re: multi-install PostgresNode fails with older postgres versions

On 4/17/21 12:35 PM, Andrew Dunstan wrote: > >> OK, here is more WIP on this item. I have drawn substantially on Mark's >> and Jehan-Guillaime's work, but it doesn't really resemble either, and I >> take full responsibility for it. >> >> The guiding principles have been: >> >> . avoid doing versi

Re: Forget close an open relation in ReorderBufferProcessTXN()

On Sat, Apr 17, 2021 at 12:01 PM Amit Kapila wrote: > > On Fri, Apr 16, 2021 at 11:24 PM Andres Freund wrote: > > > > > > > I think it is also important to *not* acquire any lock on relation > > > otherwise it can lead to some sort of deadlock or infinite wait in the > > > decoding process. Consi

Re: multi-install PostgresNode fails with older postgres versions

On Mon, Apr 19, 2021 at 08:11:01AM -0400, Andrew Dunstan wrote: > As far as I know, without any compatibility changes the module is fully > compatible with releases 13 and 12, and with releases 11 and 10 so long > as you don't want a standby, and with releases 9.6 and 9.5 if you also > don't want a

Do we need to update copyright for PG11 branch

hi, all Recently, I found the copyright info for PG11 branch still is "Portions Copyright (c) *1996-2018*, PostgreSQL Global Development Group". Do we need to update it? regards, ChenBo -- Sent from: https://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html

Re: Table refer leak in logical replication

On Mon, Apr 19, 2021 at 6:32 PM Michael Paquier wrote: > On Mon, Apr 19, 2021 at 02:33:10PM +0530, Amit Kapila wrote: > > On Mon, Apr 19, 2021 at 12:32 PM Amit Langote > > wrote: > >> FWIW, I agree with fixing this bug of 1375422c in as least scary > >> manner as possible. Hou-san proposed that

Commit 86dc90056 - Rework planning and execution of UPDATE and DELETE

Hi. With the commit mentioned in the $subject, I am seeing the change in behaviour with the varlena header size. Please consider the below test: postgres@83795=#CREATE TABLE test_storage_char(d char(20)); CREATE TABLE postgres@83795=#INSERT INTO test_storage_char SELECT REPEAT('e', 20); INSERT 0

Re: [CLOBBER_CACHE]Server crashed with segfault 11 while executing clusterdb

Michael Paquier writes: > On Mon, Apr 19, 2021 at 05:35:52PM +0900, Kyotaro Horiguchi wrote: >> Isn't this a kind of open item? > This does not qualify as an open item because it is not an actual bug > IMO, neither is it a defect of the existing code, so it seems > appropriate to me to not list i

Re: Do we need to update copyright for PG11 branch

bchen90 writes: > Recently, I found the copyright info for PG11 branch still is "Portions > Copyright (c) *1996-2018*, PostgreSQL Global Development Group". Do we need > to update it? No, that's not our practice. regards, tom lane

Re: Performance degradation of REFRESH MATERIALIZED VIEW

On Mon, Apr 19, 2021 at 8:04 PM Bharath Rupireddy wrote: > > On Mon, Apr 19, 2021 at 1:57 PM Masahiko Sawada wrote: > > > > On Mon, Apr 19, 2021 at 5:04 PM Kyotaro Horiguchi > > wrote: > > > > > > At Mon, 19 Apr 2021 13:32:31 +0900, Masahiko Sawada > > > wrote in > > > > On Fri, Apr 16, 2021 a

Re: multi-install PostgresNode fails with older postgres versions

On 4/19/21 8:32 AM, Michael Paquier wrote: > On Mon, Apr 19, 2021 at 08:11:01AM -0400, Andrew Dunstan wrote: >> As far as I know, without any compatibility changes the module is fully >> compatible with releases 13 and 12, and with releases 11 and 10 so long >> as you don't want a standby, and wi

Re: Windows default locale vs initdb

On Mon, Apr 19, 2021 at 11:52 AM Andrew Dunstan wrote: > > My understanding from Microsoft staff at conferences is that Azure's > PostgreSQL SAS runs on linux, not WIndows. > This is from a regular Azure Database for PostgreSQL single server: postgres=> select version();

Re: Commit 86dc90056 - Rework planning and execution of UPDATE and DELETE

Rushabh Lathia writes: > With the commit mentioned in the $subject, I am seeing the > change in behaviour with the varlena header size. Interesting. AFAICS, the new behavior is correct and the old is wrong. SET STORAGE PLAIN is supposed to disable use of TOAST features, including short varlena h

Re: Commit 86dc90056 - Rework planning and execution of UPDATE and DELETE

On Mon, Apr 19, 2021 at 10:00 PM Rushabh Lathia wrote: > > Hi. > > With the commit mentioned in the $subject, I am seeing the > change in behaviour with the varlena header size. Please > consider the below test: > > postgres@83795=#CREATE TABLE test_storage_char(d char(20)); > CREATE TABLE > post

Re: multi-install PostgresNode fails with older postgres versions

> On Apr 19, 2021, at 5:11 AM, Andrew Dunstan wrote: > > I think therefore I'm inclined for now to do nothing for old version > compatibility. I agree with waiting until the v15 development cycle. > I would commit the fix for the IPC::Run caching glitch, > and version detection Thank you.

Re: track_planning causing performance regression

On 2021/04/19 8:36, Justin Pryzby wrote: Reviewing this change which was committed last year as 321fa6a4a26c9b649a0fbec9fc8b019f19e62289 On Fri, Jul 03, 2020 at 03:57:38PM +0900, Fujii Masao wrote: On 2020/07/03 13:05, Pavel Stehule wrote: pá 3. 7. 2020 v 4:39 odesílatel Fujii Masao napsa

Re: track_planning causing performance regression

On Mon, Apr 19, 2021 at 11:44:05PM +0900, Fujii Masao wrote: > On 2021/04/19 8:36, Justin Pryzby wrote: > > Reviewing this change which was committed last year as > > 321fa6a4a26c9b649a0fbec9fc8b019f19e62289 > > > > On Fri, Jul 03, 2020 at 03:57:38PM +0900, Fujii Masao wrote: > > > On 2020/07/03 1

Re: Commit 86dc90056 - Rework planning and execution of UPDATE and DELETE

I wrote: > Rushabh Lathia writes: >> With the commit mentioned in the $subject, I am seeing the >> change in behaviour with the varlena header size. > Interesting. AFAICS, the new behavior is correct and the old is wrong. > SET STORAGE PLAIN is supposed to disable use of TOAST features, includin

Re: [HACKERS] [PATCH] Caching for stable expressions with constant arguments v3

On Sat, Dec 17, 2011 at 12:25 PM Marti Raudsepp wrote: > Ah, one more trick for testing this patch: if you build with > -DDEBUG_CACHEEXPR=1 then EXPLAIN VERBOSE displays cached > subexpressions between a CACHE[...] marker. Unless I missed something, this 2011 thread is the latest one about this p

Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch

Peter Eisentraut writes: > The extract(julian from timestamp) is still a bit in the slow mode, but > as I previously stated, it's not documented and gives the wrong result, > so it's not clear whether it should be fixed and what it should do. I > think I'll register that part as an open item i

Re: Commit 86dc90056 - Rework planning and execution of UPDATE and DELETE

On Mon, Apr 19, 2021 at 10:34 AM Amit Langote wrote: > After 86dc90056, the new tuple is computed with the target table's > actual TupleDesc, so the new value respects the column's attstorage, > which makes me think the new behavior is not wrong. I would not have expected SET STORAGE PLAIN to dis

Re: Commit 86dc90056 - Rework planning and execution of UPDATE and DELETE

Robert Haas writes: > On Mon, Apr 19, 2021 at 10:34 AM Amit Langote wrote: >> After 86dc90056, the new tuple is computed with the target table's >> actual TupleDesc, so the new value respects the column's attstorage, >> which makes me think the new behavior is not wrong. > I would not have expec

回覆: 回复: Core dump happens when execute sql CREATE VIEW v1(c1) AS (SELECT ('4' COLLATE "C")::INT FROM generate_series(1, 10));

Consider the SQL statement 'SELECT (('1' COLLATE "C") ||(B'1'));' . Intuitively, the result will be '11' and the result is '11' in pg 13.2 release as well. The function stack is make_fn_arguments -> coerce_type, which means that the param "Node *node" of function coerce_type could be a CollateE

Re: More info on pg_stat_activity Wait Event Name when is DataFileRead

I´m sure problem was hardware and I hope it does not occur anymore. If I have a logical replication and on replica I do a Vacuum Full, Cluster or any other EXCLUSIVE LOCK operation which, replication will wait for that. I was thinking was about a time to release that lock, or in my situation a har

Re: Reduce the number of special cases to build contrib modules on windows

> diff --git a/src/tools/msvc/MSBuildProject.pm > b/src/tools/msvc/MSBuildProject.pm > index ebb169e201..68606a296d 100644 > --- a/src/tools/msvc/MSBuildProject.pm > +++ b/src/tools/msvc/MSBuildProject.pm > @@ -310,11 +310,12 @@ sub WriteItemDefinitionGroup > my $targetmachine = > $s

Re: Windows default locale vs initdb

On 4/19/21 10:26 AM, Dave Page wrote: > > > On Mon, Apr 19, 2021 at 11:52 AM Andrew Dunstan > wrote: > > > My understanding from Microsoft staff at conferences is that > Azure's PostgreSQL SAS runs on  linux, not WIndows. > > > This is from a regular Azure Dat

Re: pg_amcheck option to install extension

On 4/18/21 7:32 PM, Alvaro Herrera wrote: > On 2021-Apr-18, Andrew Dunstan wrote: > >> On 4/17/21 3:43 PM, Mark Dilger wrote: >>> I'd also like your impressions on whether we're likely to move >>> contrib/amcheck into core anytime soon. If so, is it worth adding >>> an option that we'll soon nee

Re: multi-install PostgresNode fails with older postgres versions

On 4/19/21 10:43 AM, Mark Dilger wrote: > >> On Apr 19, 2021, at 5:11 AM, Andrew Dunstan wrote: >> >> I think therefore I'm inclined for now to do nothing for old version >> compatibility. > I agree with waiting until the v15 development cycle. > >> I would commit the fix for the IPC::Run caching

Re: pg_amcheck option to install extension

> On Apr 19, 2021, at 9:32 AM, Andrew Dunstan wrote: > > > On 4/18/21 7:32 PM, Alvaro Herrera wrote: >> On 2021-Apr-18, Andrew Dunstan wrote: >> >>> On 4/17/21 3:43 PM, Mark Dilger wrote: I'd also like your impressions on whether we're likely to move contrib/amcheck into core anyti

Re: terminate called after throwing an instance of 'std::bad_alloc'

Hi, On 2021-04-17 19:13:24 -0500, Justin Pryzby wrote: > I'm now realizing that that's RAM use for a single query, not from continuous > leaks across multiple queries. What's the memory usage with inlining disabled, and whats the usage without jit? > This is still true with the patch even if I

Re: Commit 86dc90056 - Rework planning and execution of UPDATE and DELETE

On Mon, Apr 19, 2021 at 12:13 PM Tom Lane wrote: > Au contraire. The reason that mode exists at all (for varlena types) > is to support data types that haven't been updated for TOAST. Perhaps > that's now the empty set, but it's not really our job to take away the > capability. If you really wa

Re: 回覆: 回复: Core dump happens when execute sql CREATE VIEW v1(c1) AS (SELECT ('4' COLLATE "C")::INT FROM generate_series(1, 10));

Yulin PEI writes: > Let's look at your patch: > ``` > // node is ('1' COLLATE "C") > // targetType is varbit and it is non-collatable > if (IsA(node, CollateExpr) && type_is_collatable(targetTypeId)) > { > // we will not reach here. That's not the committed patch, though. I realized after post

Re: pg_amcheck option to install extension

On Mon, Apr 19, 2021 at 12:37 PM Mark Dilger wrote: > > OK, so let's fix it. If amcheck is going to stay in contrib then ISTM > > pg_amcheck should move there. I can organize that if there's agreement. > > Or else let's move amcheck as Alvaro suggests. > > Ah, no. I wrote pg_amcheck in contrib or

Re: pg_amcheck option to install extension

Andrew Dunstan writes: > OK, so let's fix it. If amcheck is going to stay in contrib then ISTM > pg_amcheck should move there. I can organize that if there's agreement. > Or else let's move amcheck as Alvaro suggests. FWIW, I think that putting them both in contrib makes the most sense from a str

Re: More info on pg_stat_activity Wait Event Name when is DataFileRead

On Mon, Apr 19, 2021 at 12:17 PM PegoraroF10 wrote: > I´m sure problem was hardware and I hope it does not occur anymore. > If I have a logical replication and on replica I do a Vacuum Full, Cluster > or any other EXCLUSIVE LOCK operation which, replication will wait for that. > I was thinking was

Re: multi-install PostgresNode fails with older postgres versions

On Mon, 19 Apr 2021 07:43:58 -0700 Mark Dilger wrote: > > On Apr 19, 2021, at 5:11 AM, Andrew Dunstan wrote: > > > > I think therefore I'm inclined for now to do nothing for old version > > compatibility. > > I agree with waiting until the v15 development cycle. Agree.

Re: Commit 86dc90056 - Rework planning and execution of UPDATE and DELETE

Robert Haas writes: > On Mon, Apr 19, 2021 at 12:13 PM Tom Lane wrote: >> Au contraire. The reason that mode exists at all (for varlena types) >> is to support data types that haven't been updated for TOAST. > This kind of begs the question of whether you have the right idea > about what PLAIN

Re: Commit 86dc90056 - Rework planning and execution of UPDATE and DELETE

On Mon, Apr 19, 2021 at 1:03 PM Tom Lane wrote: > That doco is explaining the users-eye view of it. Places addressed > to datatype developers, such as the CREATE TYPE reference page, see > it a bit differently. CREATE TYPE for instance points out that > > All storage values other than plain

Re: pg_amcheck option to install extension

> On Apr 19, 2021, at 9:53 AM, Tom Lane wrote: > > Andrew Dunstan writes: >> OK, so let's fix it. If amcheck is going to stay in contrib then ISTM >> pg_amcheck should move there. I can organize that if there's agreement. >> Or else let's move amcheck as Alvaro suggests. > > FWIW, I think th

Re: multi-install PostgresNode fails with older postgres versions

On Mon, 19 Apr 2021 12:37:08 -0400 Andrew Dunstan wrote: > > On 4/19/21 10:43 AM, Mark Dilger wrote: > > > >> On Apr 19, 2021, at 5:11 AM, Andrew Dunstan wrote: > >> > >> I think therefore I'm inclined for now to do nothing for old version > >> compatibility. > > I agree with waiting until the

Re: multi-install PostgresNode fails with older postgres versions

> On Apr 19, 2021, at 10:25 AM, Jehan-Guillaume de Rorthais > wrote: > > On Mon, 19 Apr 2021 12:37:08 -0400 > Andrew Dunstan wrote: > >> >> On 4/19/21 10:43 AM, Mark Dilger wrote: >>> On Apr 19, 2021, at 5:11 AM, Andrew Dunstan wrote: I think therefore I'm inclined for no

Re: Bogus collation version recording in recordMultipleDependencies

Hi, On 2021-04-18 11:29:42 -0400, Tom Lane wrote: > I'm not sure that an error in this direction is all that much more > problematic than the other direction. If it's okay to claim that > indexes need to be rebuilt when they don't really, then we could just > drop this entire overcomplicated infr

Re: terminate called after throwing an instance of 'std::bad_alloc'

On Mon, Apr 19, 2021 at 09:41:30AM -0700, Andres Freund wrote: > On 2021-04-17 19:13:24 -0500, Justin Pryzby wrote: > > I'm now realizing that that's RAM use for a single query, not from > > continuous > > leaks across multiple queries. > > What's the memory usage with inlining disabled, and what

Re: multi-install PostgresNode fails with older postgres versions

On Mon, 19 Apr 2021 10:35:39 -0700 Mark Dilger wrote: > > On Apr 19, 2021, at 10:25 AM, Jehan-Guillaume de Rorthais > > wrote: > > > > On Mon, 19 Apr 2021 12:37:08 -0400 > > Andrew Dunstan wrote: > > > >> > >> On 4/19/21 10:43 AM, Mark Dilger wrote: > >>> > On Apr 19, 2021, at 5:

Re: Bogus collation version recording in recordMultipleDependencies

Andres Freund writes: > On 2021-04-18 11:29:42 -0400, Tom Lane wrote: >> I'm not sure that an error in this direction is all that much more >> problematic than the other direction. If it's okay to claim that >> indexes need to be rebuilt when they don't really, then we could just >> drop this ent

when the startup process doesn't

Hi, I've noticed that customers not infrequently complain that they start postgres and then the system doesn't come up for a while and they have no idea what's going on and are (understandably) worried. There are probably a number of reasons why this can happen, but the ones that seem to come up m

Re: Bogus collation version recording in recordMultipleDependencies

On Mon, Apr 19, 2021 at 10:53 AM Tom Lane wrote: > I think that the real fundamental bug is supposing that static analysis > can give 100% correct answers. Even if it did do so in a given state > of the database, consider this counterexample: > > create type myrow as (f1 int, f2 int); > create ta

Re: Bogus collation version recording in recordMultipleDependencies

On Sun, Apr 18, 2021 at 4:23 AM Julien Rouhaud wrote: > So IIUC the issue here is that the code could previously record useless > collation version dependencies in somes cases, which could lead to false > positive possible corruption messages (and of course additional bloat on > pg_depend). False

Re: Windows default locale vs initdb

On 19.04.21 07:42, Thomas Munro wrote: It looks like one possibility, since Vista, is to call GetUserDefaultLocaleName()[2], which doesn't appear to have been discussed before on this list. That doesn't allow you to ask for the default for each individual category, but I don't know if that is ev

Re: multi-install PostgresNode fails with older postgres versions

> On Apr 19, 2021, at 10:50 AM, Jehan-Guillaume de Rorthais > wrote: > >> The community needs a single shared PostgresNode implementation that can be >> used by scripts which reproduce bugs. > > Which means it could be OK to have a PostgresNode implementation, leaving in > core source-tree,

Re: Bogus collation version recording in recordMultipleDependencies

Peter Geoghegan writes: > On Mon, Apr 19, 2021 at 10:53 AM Tom Lane wrote: >> I think that the real fundamental bug is supposing that static analysis >> can give 100% correct answers. > Is it really the case that static analysis of the kind that you'd need > to make this 100% robust is fundament

Re: pg_amcheck option to install extension

On 4/19/21 1:25 PM, Mark Dilger wrote: > >> On Apr 19, 2021, at 9:53 AM, Tom Lane wrote: >> >> Andrew Dunstan writes: >>> OK, so let's fix it. If amcheck is going to stay in contrib then ISTM >>> pg_amcheck should move there. I can organize that if there's agreement. >>> Or else let's move amch

Synchronous commit behavior during network outage

Hello all, I would like to know your opinion on the following behaviour I see for PostgreSQL setup with synchronous replication. This behaviour happens in a special use case. In this use case, there are 2 synchronous replicas with the following config (truncated): - 2 nodes - synchronous_sta

Re: proposal - log_full_scan

ne 18. 4. 2021 v 16:09 odesílatel Pavel Stehule napsal: > > > ne 18. 4. 2021 v 14:28 odesílatel Julien Rouhaud > napsal: > >> On Sun, Apr 18, 2021 at 06:21:56AM +0200, Pavel Stehule wrote: >> > >> > The extension like pg_qualstat is good, but it does different work. >> >> Yes definitely. It was

Re: Bogus collation version recording in recordMultipleDependencies

On Mon, Apr 19, 2021 at 11:49 AM Tom Lane wrote: > I didn't mean to imply that it's necessarily theoretically impossible, > but given our lack of visibility into what a function or operator > will do, plus the way that the collation feature was bolted on > with minimal system-level redesign, it's

Re: Bogus collation version recording in recordMultipleDependencies

On Tue, Apr 20, 2021 at 5:53 AM Tom Lane wrote: > I think that the real fundamental bug is supposing that static analysis > can give 100% correct answers. ... Well, the goal was to perform analysis to the extent possible statically since that would cover the vast majority of cases and is practic

Re: pg_amcheck contrib application

On Thu, Apr 15, 2021 at 1:07 PM Mark Dilger wrote: > I have added the verb "has" rather than "contains" because "has" is more > consistent with the phrasing of other similar corruption reports. That makes sense. I think it's odd that a range of extraneous chunks is collapsed into a single repor

Re: Bogus collation version recording in recordMultipleDependencies

Thomas Munro writes: > ... The question > on my mind is whether reverting the feature and trying again for 15 > could produce anything fundamentally better at a design level, or > would just fix problems in the analyser code that we could fix right > now. Well, as I said, I think what we ought to

Re: Allowing to create LEAKPROOF functions to non-superuser

On Fri, Apr 16, 2021 at 3:57 AM Noah Misch wrote: > On Mon, Apr 12, 2021 at 02:35:27PM -0700, Andres Freund wrote: > > On 2021-04-12 17:14:20 -0400, Tom Lane wrote: > > > I doubt that falsely labeling a function LEAKPROOF can get you more > > > than the ability to read data you're not supposed to

Re: Allowing to create LEAKPROOF functions to non-superuser

Robert Haas writes: > On Fri, Apr 16, 2021 at 3:57 AM Noah Misch wrote: >> Hence, I do find it reasonable to let pg_read_all_data be sufficient for >> setting LEAKPROOF. I would not consult datdba, because datdba currently has >> no special read abilities. It feels too weird to let BYPASSRLS st

Re: "could not find pathkey item to sort" for TPC-DS queries 94-96

On Sun, Apr 18, 2021 at 1:21 PM Tom Lane wrote: > > I wrote: > > I think it's time for some refactoring of this code so that we can > > actually share the logic. Accordingly, I propose the attached. > > After sleeping on it, here's an improved version that gets rid of > an unnecessary assumption

Re: Implementing Incremental View Maintenance

On 4/7/21 5:25 AM, Yugo NAGATA wrote: > Hi, > > I rebased the patch because the cfbot failed. > > Regards, > Yugo Nagata This patch (v22c) just crashed for me with an assertion failure on Fedora 31. Here's the stack trace: [New LWP 333090] [Thread debugging using libthread_db enabled] Using

Re: "could not find pathkey item to sort" for TPC-DS queries 94-96

On Sat, Apr 17, 2021 at 3:39 PM Tom Lane wrote: > ... > Also, I don't much care for either the name or API of > find_em_expr_usable_for_sorting_rel. The sole current caller only > really needs a boolean result, and if it did need more than that > it'd likely need the whole EquivalenceMember not j

Re: Allowing to create LEAKPROOF functions to non-superuser

On Mon, Apr 19, 2021 at 4:32 PM Tom Lane wrote: > Robert Haas writes: > > On Fri, Apr 16, 2021 at 3:57 AM Noah Misch wrote: > >> Hence, I do find it reasonable to let pg_read_all_data be sufficient for > >> setting LEAKPROOF. I would not consult datdba, because datdba currently > >> has > >> n

Re: Reduce the number of special cases to build contrib modules on windows

On 4/19/21 12:24 PM, Alvaro Herrera wrote: >> diff --git a/src/tools/msvc/MSBuildProject.pm >> b/src/tools/msvc/MSBuildProject.pm >> index ebb169e201..68606a296d 100644 >> --- a/src/tools/msvc/MSBuildProject.pm >> +++ b/src/tools/msvc/MSBuildProject.pm >> @@ -310,11 +310,12 @@ sub WriteItemDefin

Re: "could not find pathkey item to sort" for TPC-DS queries 94-96

James Coleman writes: > I forgot to comment on this in my previous email, but it seems to me > that relation_has_safe_ec_member, while less wordy, isn't quite > descriptive enough. Perhaps something like > relation_has_sort_safe_ec_member? I'm not wedded to that name, certainly, but it seems like

Re: Allowing to create LEAKPROOF functions to non-superuser

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Apr 19, 2021 at 4:32 PM Tom Lane wrote: > > Robert Haas writes: > > > On Fri, Apr 16, 2021 at 3:57 AM Noah Misch wrote: > > >> Hence, I do find it reasonable to let pg_read_all_data be sufficient for > > >> setting LEAKPROOF. I

  1   2   >