Re: 2 questions about volatile attribute of pg_proc.

> > >> >> you cannot do it - with this you introduce strong dependency on nested >> objects >> > > What does the plpgsql_check do in this area? I checked the README[1], but > can't find > anything about it. > When you run plpgsql_check with performance warning (disabled by default), then it does

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

On Tue, Apr 20, 2021 at 12:38:26AM -0500, Justin Pryzby wrote: > I don't know if this is related to the other issues, but this seems leaky. And it explains how the context use counter can exceed its threshold. create or replace function fn() returns void language plpgsql as $$ declare rec int;

Re: Performance degradation of REFRESH MATERIALIZED VIEW

On Tue, Apr 20, 2021 at 11:04 AM Bharath Rupireddy wrote: > > On Mon, Apr 19, 2021 at 7:21 PM Masahiko Sawada wrote: > > I’ve updated the patch including the above comment. > > Thanks for the patch. > > I was trying to understand below statements: > + * we check without a buffer

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

On Tue, Apr 20, 2021 at 6:59 AM Kyotaro Horiguchi wrote: > > At Mon, 19 Apr 2021 16:27:25 +0530, Amul Sul wrote in > > On Mon, Apr 19, 2021 at 2:05 PM Kyotaro Horiguchi > > wrote: > > > + smgrwrite(RelationGetSmgr(index), INIT_FORKNUM, > > > BLOOM_METAPAGE_BLKNO, > > >

Re: Table refer leak in logical replication

Thanks for taking a look. On Tue, Apr 20, 2021 at 2:09 PM Michael Paquier wrote: > On Mon, Apr 19, 2021 at 09:44:05PM +0900, Amit Langote wrote: > > Okay, how about the attached then? > > create_estate_for_relation() returns an extra resultRelInfo that's > also saved within

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

I don't know if this is related to the other issues, but this seems leaky. create or replace function fn() returns void language plpgsql as $$ declare rec int; begin SELECT relpages INTO rec FROM pg_class LIMIT 1; end $$; explain analyze SELECT fn() FROM generate_series(1,999);

Re: select 'x' ~ repeat('x*y*z*', 1000);

Thomas Munro writes: > Just an observation: on REL_13_STABLE, $SUBJECT maps in ~170MB of > memory, and on master it's ~204MB. A backend running that was just > nuked by the kernel due to lack of swap space on my tiny buildfarm > animal elver (a VM with 1GB RAM, 2GB swap, not doing much else).

Re: 2 questions about volatile attribute of pg_proc.

On Tue, Apr 20, 2021 at 11:32 AM Pavel Stehule wrote: > > > út 20. 4. 2021 v 5:16 odesílatel Andy Fan > napsal: > >> >> >> On Tue, Apr 20, 2021 at 10:57 AM Pavel Stehule >> wrote: >> >>> >>> >>> út 20. 4. 2021 v 4:47 odesílatel Andy Fan >>> napsal: >>> > - a PL/PGSQL function's

Re: pg_amcheck option to install extension

> On Apr 19, 2021, at 9:22 PM, Michael Paquier wrote: > > On Mon, Apr 19, 2021 at 08:39:06PM -0700, Mark Dilger wrote: >> This is a classic privilege escalation attack. Bob has one >> privilege, and uses it to get another. > > Bob is a superuser, so it has all the privileges of the world

Re: Table refer leak in logical replication

On Mon, Apr 19, 2021 at 09:44:05PM +0900, Amit Langote wrote: > Okay, how about the attached then? create_estate_for_relation() returns an extra resultRelInfo that's also saved within es_opened_result_relations. Wouldn't is be simpler to take the first element from es_opened_result_relations

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

Hello David, Thank you for your reply. > Thanks for running that again. I see from the EXPLAIN ANALYZE output > that the planner did cost the Result Cache plan slightly more > expensive than the Hash Join plan. It's likely that add_path() did > not consider the Hash Join plan to be worth

select 'x' ~ repeat('x*y*z*', 1000);

Hi, Just an observation: on REL_13_STABLE, $SUBJECT maps in ~170MB of memory, and on master it's ~204MB. A backend running that was just nuked by the kernel due to lack of swap space on my tiny buildfarm animal elver (a VM with 1GB RAM, 2GB swap, not doing much else). Could also be related to an

Stale description for pg_basebackup

Hello. It seems to me that there's a stale description in the documentation of pg_basebackup. https://www.postgresql.org/docs/13/app-pgbasebackup.html > Note that there are some limitations in taking a backup from a standby: ... > If you are using -X none, there is no guarantee that all WAL

Re: locking [user] catalog tables vs 2pc vs logical rep

On Wed, Mar 31, 2021 at 5:47 PM vignesh C wrote: > > On Wed, Mar 31, 2021 at 2:35 PM Ajin Cherian wrote: > > > > The patch applies fine on HEAD and "make check" passes fine. No major > > comments on the patch, just a minor comment: > > > > If you could change the error from, " cannot PREPARE a

Re: pg_amcheck option to install extension

On Mon, Apr 19, 2021 at 08:39:06PM -0700, Mark Dilger wrote: > This is a classic privilege escalation attack. Bob has one > privilege, and uses it to get another. Bob is a superuser, so it has all the privileges of the world for this instance. In what is that different from BASE_BACKUP or just

Re: pg_amcheck option to install extension

> On Apr 19, 2021, at 8:06 PM, Michael Paquier wrote: > > On Mon, Apr 19, 2021 at 07:15:23PM -0700, Mark Dilger wrote: >> There is another issue to consider. Installing pg_amcheck in no way >> opens up an avenue of attack that I can see. It is just a client >> application with no special

Re: Replication slot stats misgivings

On Mon, Apr 19, 2021 at 4:48 PM Masahiko Sawada wrote: > > 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

Re: 2 questions about volatile attribute of pg_proc.

út 20. 4. 2021 v 5:16 odesílatel Andy Fan napsal: > > > On Tue, Apr 20, 2021 at 10:57 AM Pavel Stehule > wrote: > >> >> >> út 20. 4. 2021 v 4:47 odesílatel Andy Fan >> napsal: >> >>> >>> >>> > - a PL/PGSQL function's meaning depends on the search path in effect >>> when it is called, unless it

RE: Truncate in synchronous logical replication failed

On Tuesday, April 20, 2021 10:53 AM Ajin Cherian wrote: > On Sat, Apr 17, 2021 at 2:04 PM osumi.takami...@fujitsu.com > > wrote: > > No problem. Thank you for updating the patch. > I've conducted some

Re: 2 questions about volatile attribute of pg_proc.

On Tue, Apr 20, 2021 at 10:57 AM Pavel Stehule wrote: > > > út 20. 4. 2021 v 4:47 odesílatel Andy Fan > napsal: > >> >> >> > - a PL/PGSQL function's meaning depends on the search path in effect >> when it is called, unless it has a SET search_path clause or it fully >> qualifies all object

Re: Bogus collation version recording in recordMultipleDependencies

On Tue, Apr 20, 2021 at 1:48 PM Julien Rouhaud wrote: > On Tue, Apr 20, 2021 at 12:05:27PM +1200, Thomas Munro wrote: > > Yeah, that runs directly into non-trivial locking problems. I felt > > like some of the other complaints could conceivably be addressed in > > time, including dumb stuff like

Re: pg_amcheck option to install extension

On Mon, Apr 19, 2021 at 07:15:23PM -0700, Mark Dilger wrote: > There is another issue to consider. Installing pg_amcheck in no way > opens up an avenue of attack that I can see. It is just a client > application with no special privileges. But installing amcheck > arguably opens a line of

Re: Forget close an open relation in ReorderBufferProcessTXN()

On Sat, Apr 17, 2021 at 1:30 PM Amit Kapila wrote: > On Fri, Apr 16, 2021 at 11:24 PM Andres Freund wrote:> > > This made me take a brief look at pgoutput.c - maybe I am missing > > something, but how is the following not a memory leak? > > > > static void > >

Re: Bogus collation version recording in recordMultipleDependencies

On Mon, Apr 19, 2021 at 07:27:24PM -0700, Peter Geoghegan wrote: > On Mon, Apr 19, 2021 at 6:45 PM Julien Rouhaud wrote: > > > This argument seems completely absurd to me. > > > > I'm not sure why? For glibc at least, I don't see how we could not end up > > raising false positive as you have a

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

On Tue, 20 Apr 2021 at 09:28, Andrew Dunstan wrote: > > > 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 > >> +++

Re: amcheck eating most of the runtime with wal_consistency_checking

On Mon, Apr 19, 2021 at 7:50 PM Michael Paquier wrote: > While testing wal_consistency_checking, I have noticed that by far > most of the runtime is spent within the regression test check_btree on > the series of three queries inserting each 100k tuples. This also > eats most of the run time of

Re: 2 questions about volatile attribute of pg_proc.

út 20. 4. 2021 v 4:47 odesílatel Andy Fan napsal: > > > > - a PL/PGSQL function's meaning depends on the search path in effect > when it is called, unless it has a SET search_path clause or it fully > qualifies all object references, so it isn't actually possible in general > to determine what a

Re: 2 questions about volatile attribute of pg_proc.

> > I'm listening to any obvious reason to reject it. > > Any obvious reason to reject it because of it would be a lose battle for sure, so I would not waste time on it. Or vote up if you think it is possible and useful. -- Best Regards Andy Fan (https://www.aliyun.com/)

amcheck eating most of the runtime with wal_consistency_checking

Hi Peter, While testing wal_consistency_checking, I have noticed that by far most of the runtime is spent within the regression test check_btree on the series of three queries inserting each 100k tuples. This also eats most of the run time of the test on HEAD. Could we for example consider

Re: 2 questions about volatile attribute of pg_proc.

> - a PL/PGSQL function's meaning depends on the search path in effect when it is called, unless it has a SET search_path clause or it fully qualifies all object references, so it isn't actually possible in general to determine what a function calls at definition time I'd think this one as a

HEAD looks clean with wal_consistency_checking = all

Hi all, Like every year, I have done some tests with wal_consistency_checking to see if any inconsistencies have been introduced in WAL replay. And the good news is that I have noticed nothing to worry about. Thanks, -- Michael signature.asc Description: PGP signature

Re: Bogus collation version recording in recordMultipleDependencies

On Mon, Apr 19, 2021 at 6:45 PM Julien Rouhaud wrote: > > This argument seems completely absurd to me. > > I'm not sure why? For glibc at least, I don't see how we could not end up > raising false positive as you have a single glibc version for all its > collations. If a user has say en_US and

Re: pg_amcheck option to install extension

> On Apr 19, 2021, at 6:41 PM, Michael Paquier wrote: > > On Mon, Apr 19, 2021 at 12:53:29PM -0400, Tom Lane wrote: >> FWIW, I think that putting them both in contrib makes the most >> sense from a structural standpoint. >> >> Either way, though, you'll still need the proposed option to >>

Re: Can a child process detect postmaster death when in pg_usleep?

On Thu, Apr 15, 2021 at 11:48 AM Bharath Rupireddy wrote: > > We definitely have replaced a lot of sleeps with latch.c primitives > > over the past few years, since we got WL_EXIT_ON_PM_DEATH and > > condition variables. There may be many more to improve... You > > mentioned autovacuum... yeah,

Re: Performance degradation of REFRESH MATERIALIZED VIEW

On Mon, Apr 19, 2021 at 7:21 PM Masahiko Sawada wrote: > I’ve updated the patch including the above comment. Thanks for the patch. I was trying to understand below statements: + * we check without a buffer lock if the page is empty but the + * caller doesn't need

Re: ANALYZE counts LP_DEAD line pointers as n_dead_tup

On Fri, Apr 16, 2021 at 6:54 PM Peter Geoghegan wrote: > How about just documenting it in comments, as in the attached patch? I > tried to address all of the issues with LP_DEAD accounting together. > Both the issue raised by Masahiko, and one or two others that were > also discussed recently on

Re: Truncate in synchronous logical replication failed

On Sat, Apr 17, 2021 at 2:04 PM osumi.takami...@fujitsu.com < osumi.takami...@fujitsu.com> wrote: > > No problem. Thank you for updating the patch. > I've conducted some cosmetic changes. Could you please check this ? > That's already applied by pgindent. > > I executed RT for this and made no

Re: Bogus collation version recording in recordMultipleDependencies

On Tue, Apr 20, 2021 at 12:05:27PM +1200, Thomas Munro wrote: > > Yeah, that runs directly into non-trivial locking problems. I felt > like some of the other complaints could conceivably be addressed in > time, including dumb stuff like Windows default locale string format > and hopefully some

Re: Bogus collation version recording in recordMultipleDependencies

On Mon, Apr 19, 2021 at 11:13:37AM -0700, Peter Geoghegan wrote: > 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

Re: pg_amcheck option to install extension

On Mon, Apr 19, 2021 at 12:53:29PM -0400, Tom Lane wrote: > FWIW, I think that putting them both in contrib makes the most > sense from a structural standpoint. > > Either way, though, you'll still need the proposed option to > let the executable issue a CREATE EXTENSION to get the shlib >

Re: GSoC 2021 Proposal Document

Hello, On Sat, Apr 17, 2021 at 8:42 PM Nhi Dang wrote: > > Thank you for this document. It looks like there are a couple problems with this - at least if this was intended to be a submission for GSoC 2021: - The deadline for submissions was April 13th (

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

At Mon, 19 Apr 2021 16:27:25 +0530, Amul Sul wrote in > On Mon, Apr 19, 2021 at 2:05 PM Kyotaro Horiguchi > wrote: > > + smgrwrite(RelationGetSmgr(index), INIT_FORKNUM, > > BLOOM_METAPAGE_BLKNO, > > (char *) metapage, true); > > -

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

At Mon, 19 Apr 2021 09:19:36 -0400, Tom Lane wrote in > 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

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

On Mon, Apr 19, 2021 at 7:10 PM Tom Lane wrote: > > I wrote: > > Anyway I'm now inclined to remove that behavior from > > find_computable_ec_member, and adjust comments accordingly. > > After some more testing, that seems like a good thing to do, > so here's a v4. This all looks good to me.

Re: Implementing Incremental View Maintenance

On Mon, 19 Apr 2021 17:40:31 -0400 Tom Lane wrote: > Andrew Dunstan writes: > > This patch (v22c) just crashed for me with an assertion failure on > > Fedora 31. Here's the stack trace: > > > #2  0x0094a54a in ExceptionalCondition > > (conditionName=conditionName@entry=0xa91dae

Re: when the startup process doesn't

Thomas Munro writes: > On Tue, Apr 20, 2021 at 5:55 AM Robert Haas wrote: >> If I had to pick one of these two ideas, I'd pick the one the >> log-based solution, since it seems easier to access and simplifies >> retrospective analysis, but I suspect SQL access would be quite useful >> for some

Re: partial heap only tuples

On Mon, Apr 19, 2021 at 5:09 PM Bruce Momjian wrote: > > A diversity of strategies with fallback behavior is sometimes the best > > strategy. Don't underestimate the contribution of rare and seemingly > > insignificant adverse events. Consider the lifecycle of the data over > > That is an

Re: when the startup process doesn't

On Tue, Apr 20, 2021 at 5:55 AM Robert Haas wrote: > If I had to pick one of these two ideas, I'd pick the one the > log-based solution, since it seems easier to access and simplifies > retrospective analysis, but I suspect SQL access would be quite useful > for some users too, especially in

Re: when the startup process doesn't

On Mon, Apr 19, 2021 at 01:55:13PM -0400, Robert Haas wrote: > 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

Re: Do we need to update copyright for PG11 branch

On Mon, Apr 19, 2021 at 09:20:22AM -0400, Tom Lane wrote: > 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. We

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

I wrote: > Anyway I'm now inclined to remove that behavior from > find_computable_ec_member, and adjust comments accordingly. After some more testing, that seems like a good thing to do, so here's a v4. regards, tom lane diff --git

Re: when the startup process doesn't

On 2021-Apr-19, Robert Haas wrote: > Another possible approach would be to accept connections for > monitoring purposes even during crash recovery. We can't allow access > to any database at that point, since the system might not be > consistent, but we could allow something like a replication

Re: Free port choosing freezes when PostgresNode::use_tcp is used on BSD systems

Alexey Kondratov writes: > And this is an absolute true, on BSD-like systems (macOS and FreeBSD > tested) it hangs on looping through the entire ports range over and over > when $PostgresNode::use_tcp = 1 is set, since bind fails with: Hm. > That way, if it really could happen why not to just

Re: partial heap only tuples

On Sun, Apr 18, 2021 at 04:27:15PM -0700, Peter Geoghegan wrote: > Everybody tends to talk about HOT as if it works perfectly once you > make some modest assumptions, such as "there are no long-running > transactions", and "no UPDATEs will logically modify indexed columns". > But I tend to doubt

Re: Bogus collation version recording in recordMultipleDependencies

On Tue, Apr 20, 2021 at 8:21 AM Tom Lane wrote:> > Thomas Munro writes: > > For example, if you think there actually is a potential better > > plan than using pg_depend for this, that'd definitely be good to know > > about. > > I really dislike using pg_depend, for a couple of reasons: > > *

Re: pg_amcheck contrib application

> On Apr 19, 2021, at 12:50 PM, Robert Haas wrote: > > 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

column-level security policies for application users

Has anyone discussed previously column-level security "policies" or how to best manage/implement them as they don't exist yet? In my mind we have great tools for database administrator users to have column level security with grants, but not application users in a manner akin to RLS. My current

Free port choosing freezes when PostgresNode::use_tcp is used on BSD systems

Hi Hackers, Inside PostgresNode.pm there is a free port choosing routine --- get_free_port(). The comment section there says: # On non-Linux, non-Windows kernels, binding to 127.0.0/24 addresses # other than 127.0.0.1 might fail with EADDRNOTAVAIL. And this is an absolute

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

James Coleman writes: > Two things I wonder: > 1. Should we add tests for the relabel code path? As far as that goes, the Relabel-stripping loops in find_ec_member_matching_expr are already exercised in the core regression tests (I didn't bother to discover exactly where, but a quick coverage

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

I wrote: > I'm not wedded to that name, certainly, but it seems like neither > of these is quite getting at the issue. An EC can be sorted on, > by definition, but there are some things we don't want to sort > on till the final output step. I was trying to think of something > using the

Re: Implementing Incremental View Maintenance

Andrew Dunstan writes: > This patch (v22c) just crashed for me with an assertion failure on > Fedora 31. Here's the stack trace: > #2  0x0094a54a in ExceptionalCondition > (conditionName=conditionName@entry=0xa91dae "queryDesc->sourceText != > NULL", errorType=errorType@entry=0x99b468

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

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

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

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 > >>

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

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]

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: 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

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: 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

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

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

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: 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

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 -

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

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

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: 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

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).

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

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

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

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

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

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

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

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: 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

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: 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: 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: 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

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

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

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

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

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: 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

  1   2   >