Re: Issue with point_ops and NaN

At Wed, 31 Mar 2021 15:46:16 +0900 (JST), Kyotaro Horiguchi wrote in > At Wed, 31 Mar 2021 09:26:00 +0900, Michael Paquier > wrote in > > On Tue, Mar 30, 2021 at 11:39:40PM +0800, Julien Rouhaud wrote: > > > On Tue, Mar 30, 2021 at 11:02:32AM -0400, Tom Lane wrote: > > >> Agreed --- one could

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

On Tue, Mar 30, 2021 at 11:15:48PM +, Jacob Champion wrote: > Rather than putting Postgres log data into the Perl logs, I rotate the > logs exactly once at the beginning -- so that there's an > old 001_ssltests_primary.log, and a new 001_ssltests_primary_1.log -- > and then every time we trunca

Re: pgbench - add pseudo-random permutation function

Hello Dean, First, I have a thing against erand48. Yeah, that's probably a fair point. However, all the existing pgbench random functions are using it, so I think it's fair enough for permute() to do the same (and actually 2^48 is pretty huge). Switching to a 64-bit PRNG might not be a ba

Re: Issue with point_ops and NaN

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 that, I'll make a further change to the patch. As I mentioned in [1] I thin

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

On Tue, Mar 16, 2021 at 1:36 AM vignesh C wrote: > On Tue, Feb 23, 2021 at 3:59 AM Andres Freund wrote: > > > > Hi, > > > > The 2pc decoding added in > > > > commit a271a1b50e9bec07e2ef3a05e38e7285113e4ce6 > > Author: Amit Kapila > > Date: 2021-01-04 08:34:50 +0530 > > > > Allow decoding

Re: [PATCH] add concurrent_abort callback for output plugin

On Wed, Mar 31, 2021 at 5:25 PM Markus Wanner < markus.wan...@enterprisedb.com> wrote: > > The last sentences there now seems to relate to just the setting of > "concurrent_abort", rather than the whole reason to invoke the > prepare_cb. And the reference to the "gid" is a bit lost. Maybe: > >

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

On Wed, Mar 31, 2021, at 08:18, Julien Rouhaud wrote: > On Wed, Mar 31, 2021 at 12:50:19AM +0200, Joel Jacobson wrote: > > On Tue, Mar 30, 2021, at 22:01, Isaac Morland wrote: > > > On Tue, 30 Mar 2021 at 15:33, Joel Jacobson > > > wrote: > > >>> Also, should the join b

Shared buffers advice for windows in the wiki

Hello, The wiki page [1] still mentions that : "On Windows the useful range (for shared buffers) is 64MB to 512MB". The topic showed up in a pgtune discussion [2]. Is it possible to remove this advice or add that since pg10 it no longer holds true [3] ? Benoit [1] https://wiki.postgresql.org/wi

Re: Shared buffers advice for windows in the wiki

On Wed, 31 Mar 2021 at 22:39, talk to ben wrote: > Is it possible to remove this advice or add that since pg10 it no longer > holds true [3] ? I've just removed all mention of it from the wiki. David

Re: Lowering the ever-growing heap->pd_lower

On Wed, 31 Mar 2021 at 05:35, Peter Geoghegan wrote: > > On Wed, Mar 10, 2021 at 6:01 AM Matthias van de Meent > wrote: > > > The case I was concerned about back when is that there are various bits of > > > code that may visit a page with a predetermined TID in mind to look at. > > > An index loo

Re: Asynchronous Append on postgres_fdw nodes.

On Tue, Mar 30, 2021 at 8:40 PM Etsuro Fujita wrote: > I'm happy with the patch, so I'll commit it if there are no objections. Pushed. Best regards, Etsuro Fujita

Re: Issue with point_ops and NaN

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) > > > > > > > > Agreed --- one could make an argument for either 'false' or NU

Re: SQL-standard function body

On Tue, Mar 23, 2021 at 11:28:55PM -0500, Jaime Casanova wrote: > On Fri, Mar 19, 2021 at 8:49 AM Peter Eisentraut > wrote: > > > > Right. Here is a new patch with that fix added and a small conflict > > resolved. > > Great. > > It seems print_function_sqlbody() is not protected to avoid receiv

Crash in record_type_typmod_compare

Hello, In citus, we have seen the following crash backtraces because of a NULL tupledesc multiple times and we weren't sure if this was related to citus or postgres: #0 equalTupleDescs (tupdesc1=0x0, tupdesc2=0x1b9f3f0) at tupdesc.c:417 417 tupdesc.c: No such file or directory. #0 equalT

Re: Failed assertion on standby while shutdown

On 2021-03-30 20:44, Maxim Orlov wrote: 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 All the tests passed succe

Re: "box" type description

Re: Kyotaro Horiguchi > Returing to the description of pg_types, it should be changed like > this following the discussion here. > > - pg_catalog | box | geometric box '(lower left,upper right)' > + pg_catalog | box | geometric box 'lower left,upper right' > > But I find it hard to read. I fixe

Re: New IndexAM API controlling index vacuum strategies

On Wed, Mar 31, 2021 at 12:01 PM Peter Geoghegan wrote: > > On Sun, Mar 28, 2021 at 9:16 PM Peter Geoghegan wrote: > > And now here's v8, which has the following additional cleanup: > > And here's v9, which has improved commit messages for the first 2 > patches, and many small tweaks within all 4

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

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 transaction that has a > lock on user catalog/system table(s)" >

Re: row filtering for logical replication

On Wed, Mar 31, 2021 at 7:17 AM Euler Taveira wrote: > > On Tue, Mar 30, 2021, at 8:23 AM, Amit Kapila wrote: > > On Mon, Mar 29, 2021 at 6:47 PM Euler Taveira wrote: > > > Few comments: > == > 1. How can we specify row filters for multiple tables for a > publication? Consider a case

Re: cursor already in use, UPDATE RETURNING bug?

On Wed, Mar 31, 2021 at 6:09 AM Jaime Casanova wrote: > > Hi, > > Just noted an interesting behaviour when using a cursor in a function > in an UPDATE RETURNING (note that INSERT RETURNING has no problem). > > I have seen this problem in all versions I tested (9.4 thru master). > Steps to reproduc

Re: making update/delete of inheritance trees scale better

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. > My original thought for replacing the "fake variable" design was to > add another RTE holding the extra variables, and then have setref

Re: pgbench - add pseudo-random permutation function

On Wed, 31 Mar 2021 at 09:02, Fabien COELHO wrote: > > >> First, I have a thing against erand48. > > > Also, there is a 64 bits seed provided to the function which instantly > ignores 16 of them, which looks pretty silly to me. > Yeah, that was copied from set_random_seed(). > At least, I sugges

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On Wed, Mar 31, 2021 at 11:25:32AM +0800, Julien Rouhaud wrote: > On Thu, Mar 25, 2021 at 10:36:38AM +0800, Julien Rouhaud wrote: > > On Wed, Mar 24, 2021 at 01:02:00PM -0300, Alvaro Herrera wrote: > > > On 2021-Mar-24, Julien Rouhaud wrote: > > > > > > > From e08c9d5fc86ba722844d97000798de868890a

Re: UniqueKey on Partitioned table.

> b). How to present the element > in UniqueKey. Prue EquivalenceClasses or Mix of Expr and EquivalenceClass as > we just talked about. I think the reason we add ECs for sort expressions is to use transitive relationship. The EC may start with a single member but later in the planning that member

Re: Flaky vacuum truncate test in reloptions.sql

On Tue, Mar 30, 2021 at 10:22 PM Arseny Sher wrote: > > On 3/30/21 10:12 AM, Michael Paquier wrote: > > > Yep, this is the same problem as the one discussed for c2dc1a7, where > > a concurrent checkpoint may cause a page to be skipped, breaking the > > test. > > Indeed, Alexander Lakhin pointed

Re: [PATCH] add concurrent_abort callback for output plugin

On Wed, Mar 31, 2021 at 11:55 AM Markus Wanner wrote: > > On 31.03.21 06:39, Amit Kapila wrote: > > I have slightly adjusted the comments, docs, and commit message. What > > do you think about the attached? > > Thank you both, Amit and Ajin. This looks good to me. > > Only one minor gripe: > > >

Re: [PATCH] Allow multiple recursive self-references

Based on Toms feedback, and due to the fact that SQL:2021 forbidsnon-linear recursion, version 2 of the patch allows only linearrecursion. Therefore, later SQL committee decisions on non-linearrecursion should not be problematic.> [LIN] PostgreSQL does not allow multiple references to the recursive

Re: invalid data in file backup_label problem on windows

On 3/29/21 4:34 AM, Magnus Hagander wrote: On Mon, Mar 29, 2021 at 7:01 AM Michael Paquier wrote: On Sun, Mar 28, 2021 at 09:29:10AM -0400, Andrew Dunstan wrote: - vital to the backup working, and must be written without modification. + vital to the backup working and must be written

Re: Flaky vacuum truncate test in reloptions.sql

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 (in case of theoretical bug making vacuum to truncate non-empty

Re: [PATCH] add concurrent_abort callback for output plugin

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 prepare_cb. And the reference to the "gid" is a bit lost. Maybe: "Thus e

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

Hello, 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 chance (time) to join. I was going through the TODO list and studied the code and the thread discussing the optional fixes a

Re: [PATCH] Allow multiple recursive self-references

Sorry, I didn't append the patch properly. Best wishes, --Denis v2-0001-Allow-multiple-recursive-self-references.patch Description: Binary data

Re: Crash in record_type_typmod_compare

>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 intermediate error happens. I will

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On 2021-Mar-31, Bruce Momjian wrote: > On Wed, Mar 31, 2021 at 11:25:32AM +0800, Julien Rouhaud wrote: > > On Thu, Mar 25, 2021 at 10:36:38AM +0800, Julien Rouhaud wrote: > > > On Wed, Mar 24, 2021 at 01:02:00PM -0300, Alvaro Herrera wrote: > > > > I find it odd that there's executor code that ac

Re: Calendar support in localization

On Tue, Mar 30, 2021 at 11:16 AM Daniel Verite wrote: > > The conversions from julian dates are not necessarily hard, but the > I/O functions means having localized names for all days, months, eras > of all calendars in all supported languages. If you're thinking of > implementing this from scrat

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

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 chance (time) to join. > > I was going through the TODO list and stu

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

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

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

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

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

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

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

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

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

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

"'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: 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: 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: 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: 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: 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: 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, 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: 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

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

  1   2   >