Re: Issue with point_ops and NaN

At Thu, 01 Apr 2021 09:34:40 +0900 (JST), Kyotaro Horiguchi wrote in > I have to change almost all boolean-returning functions to > tri-state-boolean ones. I'll give it try a bit futther. The attached is a rush work of that, on top of the (rebased version of the) base patch. Disregarding its u

Re: DROP INDEX docs - explicit lock naming

On Tue, Mar 30, 2021 at 11:29:17PM -0400, Greg Rychlewski wrote: > Thanks for pointing that out. I've attached a new patch with several other > updates where I felt confident the docs were referring to an ACCESS > EXCLUSIVE lock. Thanks, applied! I have reviewed the whole and there is one place i

Re: Crash in BRIN minmax-multi indexes

On Wed, Mar 31, 2021 at 6:19 PM Jaime Casanova wrote: > > On Wed, Mar 31, 2021 at 5:25 PM Tomas Vondra > wrote: > > > > Hi, > > > > I think I found the issue - it's kinda obvious, really. We need to > > consider the timezone, because the "time" parts alone may be sorted > > differently. The attac

Re: [HACKERS] logical decoding of two-phase transactions

On Thu, Apr 1, 2021 at 4:58 PM Ajin Cherian wrote: > > > > On Thu, Apr 1, 2021 at 2:29 PM Amit Kapila wrote: >> >> On Tue, Mar 30, 2021 at 5:34 AM Peter Smith wrote: >> > >> > Please find attached the latest patch set v68* >> > >> >> I think this patch is in much better shape than it was few ver

Re: [HACKERS] logical decoding of two-phase transactions

On Thu, Apr 1, 2021 at 8:59 AM Amit Kapila wrote: > > On Tue, Mar 30, 2021 at 5:34 AM Peter Smith wrote: > > > > Please find attached the latest patch set v68* > > > > I think this patch is in much better shape than it was few versions > earlier but I feel still some more work and testing is requ

Re: Add client connection check during the execution of the query

On Tue, Mar 30, 2021 at 10:00 AM Thomas Munro wrote: > If we want to ship this in v14 we have to make a decision ASAP: > > 1. Ship the POLLHUP patch (like v9) that only works reliably on > Linux. Maybe disable the feature completely on other OSes? > 2. Ship the patch that tries to read (like v7

Re: [HACKERS] logical decoding of two-phase transactions

On Thu, Apr 1, 2021 at 2:29 PM Amit Kapila wrote: > On Tue, Mar 30, 2021 at 5:34 AM Peter Smith wrote: > > > > Please find attached the latest patch set v68* > > > > I think this patch is in much better shape than it was few versions > earlier but I feel still some more work and testing is requi

Re: Flaky vacuum truncate test in reloptions.sql

On Thu, Apr 01, 2021 at 12:52:21PM +0900, Masahiko Sawada wrote: > Just to be clear the context, I’m mentioning the following test case: (Coming back a couple of emails later, where indeed I forgot about the business with lazy_check_needs_freeze() that could cause a page to be skipped even if DISA

Re: Parallel INSERT (INTO ... SELECT ...)

On Mon, Mar 22, 2021 at 3:57 PM Greg Nancarrow wrote: > > On Mon, Mar 22, 2021 at 6:28 PM houzj.f...@fujitsu.com > wrote: > > > > > > > > Let me know if these changes seem OK to you. > > > > Yes, these changes look good to me. > > Posting an updated set of patches with these changes... > I have

Re: Support for NSS as a libpq TLS backend

On Wed, Mar 31, 2021 at 10:15:15PM +, Jacob Champion wrote: > I think we're going to need some analogue to PQinitOpenSSL() to help > client applications cut through the mess, but I'm not sure what it > should look like, or how we would maintain any sort of API > compatibility between the two fl

Re: Flaky vacuum truncate test in reloptions.sql

On Thu, Apr 1, 2021 at 12:08 PM Arseny Sher wrote: > > > Masahiko Sawada writes: > > >> I don't think this matters much, as it tests the contrary and the > >> probability of > >> successful test passing (in case of theoretical bug making vacuum to > >> truncate > >> non-empty relation) becomes st

RE: Stronger safeguard for archive recovery not to miss data

Hi, On Wednesday, March 31, 2021 3:06 PM Kyotaro Horiguchi wrote: > At Wed, 31 Mar 2021 15:03:28 +0900 (JST), Kyotaro Horiguchi > wrote in > > At Wed, 31 Mar 2021 02:11:48 +0900, Fujii Masao > > wrote in > > > > So, I would revert all the changes in xlog.c except changing the > > > > warning

Re: MultiXact\SLRU buffers configuration

On Thu, Apr 1, 2021 at 10:09 AM Andrey Borodin wrote: > > 29 марта 2021 г., в 11:26, Andrey Borodin написал(а): > > My TODO list: > > 1. Try to break patch set v13-[0001-0004] > > 2. Think how to measure performance of linear search versus hash search in > > SLRU buffer mapping. > > Hi Thomas! >

Re: [PATCH] add concurrent_abort callback for output plugin

On Wed, Mar 31, 2021 at 7:20 PM Markus Wanner wrote: > > On 31.03.21 15:18, Amit Kapila wrote: > > On Wed, Mar 31, 2021 at 11:55 AM Markus Wanner > >> The last sentences there now seems to relate to just the setting of > >> "concurrent_abort", rather than the whole reason to invoke the > >> prepar

Re: [HACKERS] logical decoding of two-phase transactions

On Tue, Mar 30, 2021 at 5:34 AM Peter Smith wrote: > > Please find attached the latest patch set v68* > I think this patch is in much better shape than it was few versions earlier but I feel still some more work and testing is required. We can try to make it work with the streaming option and do

Re: Flaky vacuum truncate test in reloptions.sql

Arseny Sher writes: > as currently the chance of its failure is close to 1. A typo, to 0 too, of course.

Re: Flaky vacuum truncate test in reloptions.sql

Masahiko Sawada writes: >> I don't think this matters much, as it tests the contrary and the >> probability of >> successful test passing (in case of theoretical bug making vacuum to >> truncate >> non-empty relation) becomes stunningly small. But adding it wouldn't hurt >> either. > > I was co

Re: making update/delete of inheritance trees scale better

On Thu, 1 Apr 2021 at 15:09, Amit Langote wrote: > Note that the patch over there doesn't do anything about > AcquireExecutorLocks() bottleneck, as there are some yet-unsolved race > conditions that were previously discussed here: > > https://www.postgresql.org/message-id/flat/CAKJS1f_kfRQ3ZpjQyHC

Improve error matching patterns in the SSL tests

Hi all, It has been mentioned twice for the last couple of days that some of the SSL tests are not really picky with what they check, which can be annoying when it comes to the testing of other SSL implementations as we cannot really be sure if an error tells more than "SSL error": https://www.pos

Re: Crash in BRIN minmax-multi indexes

On Thu, Apr 1, 2021 at 11:25 AM Tomas Vondra wrote: > As for why the regression tests did not catch this, it's most likely > because the data is likely generated in "nice" ordering, or something > like that. I'll see if I can tweak the ordering to trigger these issues > reliably, and I'll do a bit

Re: Flaky vacuum truncate test in reloptions.sql

On Wed, Mar 31, 2021 at 10:39 PM Arseny Sher wrote: > > > On 3/31/21 4:17 PM, Masahiko Sawada wrote: > > > Is it better to add FREEZE to the first "VACUUM reloptions_test;" as > well? > > I don't think this matters much, as it tests the contrary and the > probability of > successful test passing

Re: multi-install PostgresNode fails with older postgres versions

> On Mar 31, 2021, at 1:07 PM, Mark Dilger wrote: > > > >> On Mar 31, 2021, at 1:05 PM, Andrew Dunstan wrote: >> >> >> On 3/31/21 3:48 PM, Alvaro Herrera wrote: >>> On 2021-Mar-31, Mark Dilger wrote: >>> PostgresNode::start() doesn't work for servers older than version 10, eithe

Re: making update/delete of inheritance trees scale better

On Thu, Apr 1, 2021 at 12:58 AM Tom Lane wrote: > Amit Langote writes: > > On Tue, Mar 30, 2021 at 1:51 PM Tom Lane wrote: > >> Here's a v13 patchset that I feel pretty good about. > > > Thanks. After staring at this for a day now, I do too. > > Thanks for looking! Pushed after some more docs-

Re: a misbehavior of partition row movement (?)

On Tue, Mar 23, 2021 at 6:27 PM Amit Langote wrote: > > Sawada-san, > > On Wed, Mar 10, 2021 at 4:51 PM Masahiko Sawada wrote: > > I looked at the 0001 patch and here are random comments. Please ignore > > a comment if it is already discussed. > > Thanks a lot for the review and sorry for the del

Re: New IndexAM API controlling index vacuum strategies

On Thu, Apr 1, 2021 at 9:58 AM Peter Geoghegan wrote: > > On Wed, Mar 31, 2021 at 4:45 AM Masahiko Sawada wrote: > > Both 0001 and 0002 patch refactors the whole lazy vacuum code. Can we > > merge them? I basically agree with the refactoring made by 0001 patch > > but I'm concerned a bit that hav

Re: Crash in BRIN minmax-multi indexes

On 4/1/21 3:22 AM, Zhihong Yu wrote: > Hi, > -       delta += (float8) addrb[i] - (float8) addra[i]; > -       delta /= 256; > ... > +       delta /= 255; > > May I know why the divisor was changed ? > Yeah, that's a mistake, it should remain 256. Consider two subtractions 1.1.2.255 - 1.1.1.0 =

Re: Proposal: Save user's original authenticated identity for logging

On Wed, Mar 31, 2021 at 04:42:32PM +0900, Michael Paquier wrote: > Attached is an updated patch, with a couple of comments tweaks, the > reworked tests and an indentation done. Jacob has mentioned me that v15 has some false positives in the SSL tests, as we may catch in the backend logs patterns t

Re: Crash in BRIN minmax-multi indexes

Hi, - delta += (float8) addrb[i] - (float8) addra[i]; - delta /= 256; ... + delta /= 255; May I know why the divisor was changed ? Thanks On Wed, Mar 31, 2021 at 3:25 PM Tomas Vondra wrote: > Hi, > > I think I found the issue - it's kinda obvious, really. We need to > conside

Re: Refactor SSL test framework to support multiple TLS libraries

On Wed, Mar 31, 2021 at 10:43:00AM +0900, Michael Paquier wrote: > Jacob has just raised this as an issue for an integration with NLS, > because it may be possible that things fail with "SSL error" but a > different error pattern, causing false positives: > https://www.postgresql.org/message-id/e0f

Re: New IndexAM API controlling index vacuum strategies

On Wed, Mar 31, 2021 at 4:45 AM Masahiko Sawada wrote: > Both 0001 and 0002 patch refactors the whole lazy vacuum code. Can we > merge them? I basically agree with the refactoring made by 0001 patch > but I'm concerned a bit that having such a large refactoring at very > close to feature freeze co

Re: invalid data in file backup_label problem on windows

On Wed, Mar 31, 2021 at 09:33:25AM -0400, David Steele wrote: > Agreed. New patch attached. Thanks, David. > diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml > index c5557d5444..8c9186d277 100644 > --- a/doc/src/sgml/backup.sgml > +++ b/doc/src/sgml/backup.sgml > @@ -913,7 +913,8

Re: Issue with point_ops and NaN

At Wed, 31 Mar 2021 12:01:08 +0200, Laurenz Albe wrote in > On Wed, 2021-03-31 at 15:48 +0900, Kyotaro Horiguchi wrote: > > > > > > > SELECT point('NaN','NaN') <@ polygon('(0,0),(1,0),(1,1),(0,0)'); > > > > > > > ?column? > > > > > > > -- > > > > > > > t > > > > > > > (1 row) > > >

Re: Issue with point_ops and NaN

At Wed, 31 Mar 2021 16:30:41 +0800, Julien Rouhaud wrote in > On Wed, Mar 31, 2021 at 03:48:16PM +0900, Kyotaro Horiguchi wrote: > > > > Thanks! However, Michael's suggestion is worth considering. What do > > you think about makeing NaN-involved comparison return NULL? If you > > agree to tha

Re: Hybrid Hash/Nested Loop joins and caching results from subplans

On Wed, 31 Mar 2021 at 05:34, Zhihong Yu wrote: > > Hi, > In paraminfo_get_equal_hashops(), > > + /* Reject if there are any volatile functions */ > + if (contain_volatile_functions(expr)) > + { > > You can move the above code to just ahead of: > > + if (IsA(expr, Var)) > +

Re: using extended statistics to improve join estimates

Hi, + * has_matching_mcv + * Check whether the list contains statistic of a given kind The method name is find_matching_mcv(). It seems the method initially returned bool but later the return type was changed. + StatisticExtInfo *found = NULL; found normally is associated with bool return

Re: libpq debug log

On 2021-Mar-31, Tom Lane wrote: > While this may have little to do with drongo's issue, > I'm going to take exception to this bit that I see that > the patch added to PQtrace(): > > /* Make the trace stream line-buffered */ > setvbuf(debug_port, NULL, _IOLBF, 0); Mea culpa. I added

Re: Crash in BRIN minmax-multi indexes

On Wed, Mar 31, 2021 at 5:25 PM Tomas Vondra wrote: > > Hi, > > I think I found the issue - it's kinda obvious, really. We need to > consider the timezone, because the "time" parts alone may be sorted > differently. The attached patch should fix this, and it also fixes a > similar issue in the ine

Re: Crash in BRIN minmax-multi indexes

On 4/1/21 12:53 AM, Zhihong Yu wrote: > Hi, > For inet data type fix: > > +       unsigned char a = addra[i]; > +       unsigned char b = addrb[i]; > + > +       if (i >= lena) > +           a = 0; > + > +       if (i >= lenb) > +           b = 0; > > Should the length check precede the addra[i]

Re: Crash in BRIN minmax-multi indexes

Hi, For inet data type fix: + unsigned char a = addra[i]; + unsigned char b = addrb[i]; + + if (i >= lena) + a = 0; + + if (i >= lenb) + b = 0; Should the length check precede the addra[i] ? Something like: unsigned char a; if (i >= lena)

Re: Assertion failure with barriers in parallel hash join

On Wed, Mar 17, 2021 at 8:18 AM Thomas Munro wrote: > > On Wed, Mar 17, 2021 at 6:58 PM Thomas Munro wrote: > > According to BF animal elver there is something wrong with this > > commit. Looking into it. > > Assertion failure reproduced here and understood, but unfortunately > it'll take some m

Re: libpq debug log

I wrote: > What I suspect is some Windows dependency in the way that > 001_libpq_pipeline.pl is setting up the trace output files. While this may have little to do with drongo's issue, I'm going to take exception to this bit that I see that the patch added to PQtrace(): /* Make the trace

Re: New IndexAM API controlling index vacuum strategies

On Wed, Mar 31, 2021 at 9:29 AM Robert Haas wrote: > I can't effectively review 0001 because it both changes the code for > individual functions significantly and reorders them within the file. > I think it needs to be separated into two patches, one of which makes > the changes and the other of w

Re: Assertion failure with barriers in parallel hash join

On Wed, Mar 17, 2021 at 8:18 AM Thomas Munro wrote: > > On Wed, Mar 17, 2021 at 6:58 PM Thomas Munro wrote: > > According to BF animal elver there is something wrong with this > > commit. Looking into it. > > Assertion failure reproduced here and understood, but unfortunately > it'll take some m

Re: Crash in BRIN minmax-multi indexes

Hi, I think I found the issue - it's kinda obvious, really. We need to consider the timezone, because the "time" parts alone may be sorted differently. The attached patch should fix this, and it also fixes a similar issue in the inet data type. As for why the regression tests did not catch this,

Re: What to call an executor node which lazily caches tuples in a hash table?

> Does anyone else like the name "Tuple Cache"? I personally like that name best. It makes sense to me when thinking about looking at an EXPLAIN and trying to understand why this node may be there. The way we look up the value stored in the cache doesn't really matter to me as a user, I'm more thi

Re: libpq debug log

"'alvhe...@alvh.no-ip.org'" writes: > On 2021-Mar-31, Tom Lane wrote: >> So for some reason, opening the trace file fails. >> (I wonder why we don't see an error message for this though.) > .. oh, I think we forgot to set conn->Pfdebug = NULL when creating the > connection. So when we do PQtrace

Re: Support for NSS as a libpq TLS backend

On Fri, 2021-03-26 at 18:05 -0400, Stephen Frost wrote: > * Jacob Champion (pchamp...@vmware.com) wrote: > > Yeah. I was hoping to avoid implementing our own locks and refcounts, > > but it seems like it's going to be required. > > Yeah, afraid so. I think it gets worse, after having debugged som

Re: libpq debug log

On 2021-Mar-31, 'alvhe...@alvh.no-ip.org' wrote: > .. oh, I think we forgot to set conn->Pfdebug = NULL when creating the > connection. So when we do PQtrace(), the first thing it does is > PQuntrace(), and then that tries to do fflush(conn->Pfdebug) ---> crash. > So this should fix it. I tried

Re: libpq debug log

On 2021-Mar-31, Tom Lane wrote: > I wrote: > > That is weird - only test 4 (of 8) runs at all, the rest seem to > > fail to connect. What's different about pipelined_insert? > > Oh ... there's a pretty obvious theory. pipelined_insert is > the only one that is not asked to write a trace file. >

Re: libpq debug log

I wrote: > That is weird - only test 4 (of 8) runs at all, the rest seem to > fail to connect. What's different about pipelined_insert? Oh ... there's a pretty obvious theory. pipelined_insert is the only one that is not asked to write a trace file. So for some reason, opening the trace file fai

Re: libpq debug log

"'alvhe...@alvh.no-ip.org'" writes: > This is not the *only* issue though; at least animal drongo shows a > completely different failure, where the last few tests don't even get to > run, and the server log just has this: That is weird - only test 4 (of 8) runs at all, the rest seem to fail to co

Re: libpq debug log

On 2021-Mar-31, Tom Lane wrote: > I think this is a timing problem that's triggered (on some machines) > by force_parallel_mode = regress. Looking at spurfowl's latest > failure of this type, the postmaster log shows > > 2021-03-31 14:34:54.982 EDT [18233:15] 001_libpq_pipeline.pl LOG: execute

Re: What to call an executor node which lazily caches tuples in a hash table?

Hi, On 2021-03-31 12:29:36 +1300, David Rowley wrote: > Here's a list of a few that were mentioned: > > Probe Cache > Tuple Cache > Keyed Materialize > Hash Materialize > Result Cache > Cache > Hash Cache > Lazy Hash > Reactive Hash > Parameterized Hash > Parameterized Cache > Keyed Inner Cache >

Re: Idea: Avoid JOINs by using path expressions to follow FKs

On 3/31/21 6:54 PM, Pavel Stehule wrote: >> >> >> >> If using the -> notation, you would only need to manually >> inspect the tables involved in the remaining JOINs; >> since you could be confident all uses of -> cannot affect cardinality. >> >> I think this would be a win also for an expert SQL co

Re: Idea: Avoid JOINs by using path expressions to follow FKs

On Wed, Mar 31, 2021, at 22:25, Isaac Morland wrote: > > Maybe I have a different proposal in mind than anybody else, but I don't > think there is a problem with multiple joins to the same table. If the joins > are via the same constraint, then a single join is enough, and if they are > via d

Re: Default role -> Predefined role

Greetings, * Daniel Gustafsson (dan...@yesql.se) wrote: > > On 20 Nov 2020, at 22:13, Stephen Frost wrote: > > Attached is a patch to move from 'default role' terminology to > > 'predefined role' in the documentation. In the code, I figured it made > > more sense to avoid saying either one and i

Re: MultiXact\SLRU buffers configuration

> 29 марта 2021 г., в 11:26, Andrey Borodin написал(а): > > My TODO list: > 1. Try to break patch set v13-[0001-0004] > 2. Think how to measure performance of linear search versus hash search in > SLRU buffer mapping. Hi Thomas! I'm still doing my homework. And to this moment all my catch is

Re: multi-install PostgresNode fails with older postgres versions

On 3/30/21 8:52 PM, Michael Paquier wrote: > On Tue, Mar 30, 2021 at 08:44:26PM -0400, Andrew Dunstan wrote: >> Yeah, it should be validated. All things considered I think just calling >> 'pg_config --version' is probably the simplest validation, and likely to >> be sufficient. >> >> I'll try to

Re: Add docs stub for recovery.conf

Greetings, * Stephen Frost (sfr...@snowman.net) wrote: > * Stephen Frost (sfr...@snowman.net) wrote: > > Awesome, attached is just a rebase (not that anything really changed). > > Unless someone wants to speak up, I'll commit this soonish (hopefully > > tomorrow, but at least sometime later this w

Re: Idea: Avoid JOINs by using path expressions to follow FKs

On Wed, 31 Mar 2021 at 15:32, Joel Jacobson wrote: > On Wed, Mar 31, 2021, at 19:16, Julien Rouhaud wrote: > > On Wed, Mar 31, 2021 at 5:19 PM Joel Jacobson wrote: > > > > If using the -> notation, you would only need to manually > > inspect the tables involved in the remaining JOINs; > > since

Re: libpq debug log

"'alvhe...@alvh.no-ip.org'" writes: > So crake failed. The failure is that it doesn't print the DataRow > messages. That's quite odd. We see this in the trace log: I think this is a timing problem that's triggered (on some machines) by force_parallel_mode = regress. Looking at spurfowl's late

RFC: Table access methods and scans

Hi all, I started looking into how table scans are handled for table access methods and have discovered a few things that I find odd. I cannot find any material regarding why this particular choice was made (if anybody has pointers, I would be very grateful). I am quite new to PostgreSQL so forgi

Re: multi-install PostgresNode fails with older postgres versions

> On Mar 31, 2021, at 1:05 PM, Andrew Dunstan wrote: > > > On 3/31/21 3:48 PM, Alvaro Herrera wrote: >> On 2021-Mar-31, Mark Dilger wrote: >> >>> PostgresNode::start() doesn't work for servers older than version 10, >>> either. If I hack that function to sleep until the postmaster.pid >>> f

Re: multi-install PostgresNode fails with older postgres versions

On 3/31/21 3:48 PM, Alvaro Herrera wrote: > On 2021-Mar-31, Mark Dilger wrote: > >> PostgresNode::start() doesn't work for servers older than version 10, >> either. If I hack that function to sleep until the postmaster.pid >> file exists, it works, but that is really ugly and is just to prove to

Re: Idea: Avoid JOINs by using path expressions to follow FKs

On Wed, Mar 31, 2021, at 21:32, Joel Jacobson wrote: > SELECT DISTINCT customers.company_name > FROM order_details->products > JOIN order_details->orders->customers > WHERE products.product_name = 'Chocolade'; Hm, maybe the operator shouldn't be allowed directly after FROM, but only used with a j

Re: Crash in record_type_typmod_compare

Hi, On 2021-03-31 13:26:34 +, Sait Talha Nisanci wrote: > diff --git a/src/backend/utils/cache/typcache.c > b/src/backend/utils/cache/typcache.c > index 4915ef5934..4757e8fa80 100644 > --- a/src/backend/utils/cache/typcache.c > +++ b/src/backend/utils/cache/typcache.c > @@ -1970,18 +1970,16 @

Re: multi-install PostgresNode fails with older postgres versions

On 2021-Mar-31, Mark Dilger wrote: > PostgresNode::start() doesn't work for servers older than version 10, > either. If I hack that function to sleep until the postmaster.pid > file exists, it works, but that is really ugly and is just to prove to > myself that it is a timing issue. There were a

Re: multi-install PostgresNode fails with older postgres versions

> On Mar 30, 2021, at 5:41 PM, Mark Dilger wrote: > > 1) PostgresNode::init() doesn't work for older server versions PostgresNode::start() doesn't work for servers older than version 10, either. If I hack that function to sleep until the postmaster.pid file exists, it works, but that is r

Re: Crash in record_type_typmod_compare

Andres Freund writes: > On 2021-03-31 13:10:50 -0400, Tom Lane wrote: >> Couldn't we just >> teach record_type_typmod_compare to say "not equal" if it sees a >> null tupdesc? > Won't that lead to an accumulation of dead hash table entries over time? Yeah, if you have repeat failures there, which

Re: Idea: Avoid JOINs by using path expressions to follow FKs

On Wed, Mar 31, 2021, at 19:16, Julien Rouhaud wrote: > On Wed, Mar 31, 2021 at 5:19 PM Joel Jacobson > wrote: > > > > If using the -> notation, you would only need to manually > > inspect the tables involved in the remaining JOINs; > > since you could be confident all

Re: Redundant errdetail prefix "The error was:" in some logical replication messages

Peter Smith writes: > PSA version 2 of this patch which adopts your suggestions. LGTM, pushed. regards, tom lane

Re: Crash in record_type_typmod_compare

Hi, On 2021-03-31 13:10:50 -0400, Tom Lane wrote: > Sait Talha Nisanci writes: > >> We should probably do > >> HASH_ENTER > >> only after we have a valid entry so that we

Re: Idea: Avoid JOINs by using path expressions to follow FKs

SAP has implemented something similar all across their stack. In their HANA database, application platform ABAP and also their cloud. So clearly they find it very popular:-) It is called CDS (Core Data Services) views. Here is a quick overview: - Superset of SQL to declare views and association

Re: row filtering for logical replication

Hi, As far as I can tell you have not *AT ALL* addressed that it is *NOT SAFE* to evaluate arbitrary expressions from within an output plugin. Despite that having been brought up multiple times. > +static ExprState * > +pgoutput_row_filter_prepare_expr(Node *rfnode, EState *estate) > +{ > +

Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

Alvaro Herrera writes: > I added that test as promised, and I couldn't find any problems, so I > have pushed it. Buildfarm testing suggests there's an issue under CLOBBER_CACHE_ALWAYS: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=trilobite&dt=2021-03-29%2018%3A14%3A24 specifically d

Re: Crash in BRIN minmax-multi indexes

On 3/31/21 8:20 PM, Zhihong Yu wrote: > Hi, > In build_distances(): > >         a1 = eranges[i].maxval; >         a2 = eranges[i + 1].minval; > > It seems there was overlap between the successive ranges, leading to > delta = -678500 > I've been unable to reproduce this, so far :-( How exact

Re: Crash in BRIN minmax-multi indexes

Hi, In build_distances(): a1 = eranges[i].maxval; a2 = eranges[i + 1].minval; It seems there was overlap between the successive ranges, leading to delta = -678500 FYI On Wed, Mar 31, 2021 at 10:30 AM Jaime Casanova < jcasa...@systemguards.com.ec> wrote: > Hi, > > Just found

Re: ModifyTable overheads in generic plans

Amit Langote writes: > [ v14-0002-Initialize-result-relation-information-lazily.patch ] Needs YA rebase over 86dc90056. regards, tom lane

Re: "has_column_privilege()" issue with attnums and non-existent columns

On 3/30/21 8:17 PM, Joe Conway wrote: On 3/30/21 6:22 PM, Tom Lane wrote: Joe Conway writes: Heh, I missed the forest for the trees it seems. That version undid the changes fixing what Ian was originally complaining about. Duh, right. It would be a good idea for there to be a code comment e

Re: pgbench - add pseudo-random permutation function

Hello Dean, OK, attached is an update making this change and simplifying the rotate code, which hopefully just leaves the question of what (if anything) to do with pg_erand48(). Yep. While looking at it, I have some doubts on this part: m = (uint64) (pg_erand48(random_state.xseed) * (mask

Re: pg_amcheck contrib application

On Wed, Mar 31, 2021 at 1:44 PM Mark Dilger wrote: > I read "exclusively locks" as meaning it takes an ExclusiveLock, but the code > shows that it takes an AccessExclusiveLock. I think the docs are pretty > misleading here, though I understand that grammatically it is hard to say > "accessivel

Re: pg_amcheck contrib application

> On Mar 31, 2021, at 10:31 AM, Mark Dilger > wrote: > > > >> On Mar 31, 2021, at 10:11 AM, Robert Haas wrote: >> >> On Wed, Mar 31, 2021 at 12:34 AM Mark Dilger >> wrote: >>> I'm not looking at the old VACUUM FULL code, but my assumption is that if >>> the xvac code were resurrected, t

Re: pg_amcheck contrib application

On Wed, Mar 31, 2021 at 1:31 PM Mark Dilger wrote: > Actually, that makes a lot of sense without even looking at the old code. I > was implicitly assuming that the toast table was undergoing a VF also, and > that the toast pointers in the main table tuples would be updated to point to > the ne

Re: making update/delete of inheritance trees scale better

On Wed, Mar 31, 2021 at 1:24 PM Tom Lane wrote: > I agree that we have some existing behavior that's related to this, but > it's still messy, and I couldn't find any evidence that suggested that the > runtime lookup costs anything. Typical subplans are going to deliver > long runs of tuples from

using extended statistics to improve join estimates

Hi, So far the extended statistics are applied only at scan level, i.e. when estimating selectivity for individual tables. Which is great, but joins are a known challenge, so let's try doing something about it ... Konstantin Knizhnik posted a patch [1] using functional dependencies to improve joi

Re: pg_amcheck contrib application

> On Mar 31, 2021, at 10:11 AM, Robert Haas wrote: > > On Wed, Mar 31, 2021 at 12:34 AM Mark Dilger > wrote: >> I'm not looking at the old VACUUM FULL code, but my assumption is that if >> the xvac code were resurrected, then when a tuple is moved off by a VACUUM >> FULL, the old tuple and

Crash in BRIN minmax-multi indexes

Hi, Just found $SUBJECT involving time with time zone and a subselect. I still don't have narrowed to the exact table/index minimal schema but if you run this query on the regression database it will creash. ``` update public.brintest_multi set timetzcol = (select tz from generate_series('2021-

Re: making update/delete of inheritance trees scale better

Robert Haas writes: > On Tue, Mar 30, 2021 at 12:51 AM Tom Lane wrote: >> Maybe that could be made more robust, but the other problem >> is that the EXPLAIN output is just about unreadable; nobody will >> understand what "(0)" means. > I think this was an idea that originally came from me, promp

Re: Idea: Avoid JOINs by using path expressions to follow FKs

On Wed, Mar 31, 2021 at 5:19 PM Joel Jacobson wrote: > > If using the -> notation, you would only need to manually > inspect the tables involved in the remaining JOINs; > since you could be confident all uses of -> cannot affect cardinality. Talking about that, do you have some answers to the poi

Re: pg_amcheck contrib application

On Wed, Mar 31, 2021 at 12:34 AM Mark Dilger wrote: > I'm not looking at the old VACUUM FULL code, but my assumption is that if the > xvac code were resurrected, then when a tuple is moved off by a VACUUM FULL, > the old tuple and associated toast cannot be pruned until concurrent > transaction

Re: Crash in record_type_typmod_compare

Sait Talha Nisanci writes: >> We should probably do >> HASH_ENTER >> only after we have a valid entry so that we don't end up with a NULL entry >> in the cache even if an

Re: making update/delete of inheritance trees scale better

On Tue, Mar 30, 2021 at 12:51 AM Tom Lane wrote: > Maybe that could be made more robust, but the other problem > is that the EXPLAIN output is just about unreadable; nobody will > understand what "(0)" means. I think this was an idea that originally came from me, prompted by what we already do fo

Re: Idea: Avoid JOINs by using path expressions to follow FKs

> > > > If using the -> notation, you would only need to manually > inspect the tables involved in the remaining JOINs; > since you could be confident all uses of -> cannot affect cardinality. > > I think this would be a win also for an expert SQL consultant working > with a new complex data model

Re: Prevent query cancel packets from being replayed by an attacker (From TODO)

On Wed, Mar 31, 2021 at 5:44 PM Laurenz Albe wrote: > > On Wed, 2021-03-31 at 16:54 +0300, Sebastian Cabot wrote: > > My name is Sebastian and I am new to this list and community. > > I have been following PostgreSQL for several years and I love the work done > > on > > it, but I never had the c

Re: New IndexAM API controlling index vacuum strategies

On Mon, Mar 29, 2021 at 12:16 AM Peter Geoghegan wrote: > And now here's v8, which has the following additional cleanup: I can't effectively review 0001 because it both changes the code for individual functions significantly and reorders them within the file. I think it needs to be separated into

Re: making update/delete of inheritance trees scale better

Amit Langote writes: > On Tue, Mar 30, 2021 at 1:51 PM Tom Lane wrote: >> Here's a v13 patchset that I feel pretty good about. > Thanks. After staring at this for a day now, I do too. Thanks for looking! Pushed after some more docs-fiddling and a final read-through. I think the only code cha

Re: Allow an alias to be attached directly to a JOIN ... USING

On 23.03.21 00:18, Tom Lane wrote: However, ParseNamespaceItem as it stands needs some help for this. It has a wired-in assumption that p_rte->eref describes the table and column aliases exposed by the nsitem. 0001 below fixes this by creating a separate p_names field in an nsitem. (There are

Re: TRUNCATE on foreign table

2021年3月30日(火) 2:53 Fujii Masao : > > On 2021/03/28 2:37, Kazutaka Onishi wrote: > > Fujii-san, > > > > Thank you for your review! > > Now I prepare v5 patch and I'll answer to your each comment. please > > check this again. > > Thanks a lot! > > > 5. For example, we can easily do that by truncate f

Re: unconstrained memory growth in long running procedure stored procedure after upgrading 11-12

On Tue, Mar 30, 2021 at 7:14 PM Tom Lane wrote: > > Justin Pryzby writes: > > On Tue, Mar 30, 2021 at 04:17:03PM -0500, Merlin Moncure wrote: > >> We just upgraded from postgres 11 to 12.6 and our server is running > >> out of memory and rebooting about 1-2 times a day. > > > I haven't tried your

Re: cursor already in use, UPDATE RETURNING bug?

On Wed, Mar 31, 2021 at 7:50 AM Ashutosh Bapat wrote: > > On Wed, Mar 31, 2021 at 6:09 AM Jaime Casanova > > > > > -- this fails > > update t2 set i = 5 returning cursor_bug() as c1; > > ERROR: cursor "c1" already in use > > CONTEXT: PL/pgSQL function cursor_bug() line 6 at OPEN > > but that's c

  1   2   >