Re: proposal - plpgsql unique statement id

On 04/01/2019 15:07, Pavel Stehule wrote: > pá 4. 1. 2019 v 13:58 odesílatel Peter Eisentraut > > napsal: > > On 13/11/2018 14:35, Pavel Stehule wrote: > > I am try to enhance plpgsql_check about profiler functionality and I > > have to solve

Re: using expression syntax for partition bounds

On 16/01/2019 08:41, Amit Langote wrote: > OK, will change it back to partition_bound_expr. Removing "bound" from it > makes the term ambiguous? Yeah, let's leave it in. > How about the following note in the documentation: > > + Although volatile expressions such as > +

Re: Protect syscache from bloating with negative cache entries

Hello. At Fri, 18 Jan 2019 11:46:03 +1300, Gavin Flower wrote in <4e62e6b7-0ffb-54ae-3757-5583fcca3...@archidevsys.co.nz> > On 18/01/2019 08:48, Bruce Momjian wrote: > > On Thu, Jan 17, 2019 at 11:33:35AM -0500, Robert Haas wrote: > >> The flaw in your thinking, as it seems to me, is that in

Re: Python versions (was Re: RHEL 8.0 build)

On 16/01/2019 17:30, Tom Lane wrote: >> The following are listed but don't affect any other tests, so I didn't >> include them: > >> BISON >> DTRACE >> DTRACEFLAGS >> FLEX >> XML2_CONFIG > > (slightly confused ...) Surely XML2_CONFIG feeds into what we choose for > CPPFLAGS? If that doesn't

RE: Libpq support to connect to standby server as priority

From: Tsunakawa, Takayuki [mailto:tsunakawa.ta...@jp.fujitsu.com] > As for prefer-standby/prefer-read, if host parameter specifies host1,host2 > in this order, and host1 is the primary with > default_transaction_read_only=true, does the app get a connection to host1? > I want to connect to host2

Re: pg_dump multi VALUES INSERT

On Fri, Jan 18, 2019 at 7:14 AM David Rowley wrote: > On Fri, 18 Jan 2019 at 01:15, Surafel Temesgen > wrote: > > The attache patch use your method mostly > > I disagree with the "mostly" part. As far as I can see, you took the > idea and then made a series of changes to completely break it.

Re: Libpq support to connect to standby server as priority

>> If you need some input from me regarding finding a primary node, >> please say so. While working on Pgpool-II project, I learned the >> necessity in a hard way. >> >> > I would really like to have a consistent way of doing this, and consistent > terms for the connection parameters. > > that

RE: Libpq support to connect to standby server as priority

From: Haribabu Kommi [mailto:kommi.harib...@gmail.com] > IMO, if we try to use only pg_is_in_recovery() only to decide to connect, > we may not > support all the target_session_attrs that are possible. how about using > both to decide? I favor adding a new parameter like target_server_type whose

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

BTW, if you're wondering why curculio is still failing the pgbench test, all is explained here: https://man.openbsd.org/srandom Or at least most is explained there. While curculio is unsurprisingly failing all four seeded_random tests, when I try it locally on an OpenBSD 6.4 installation, only

Re: Delay locking partitions during INSERT and UPDATE

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, failed Spec compliant: tested, failed Documentation:tested, failed Hi, Increasing the number of clients, I benchmarked with a

Re: Libpq support to connect to standby server as priority

On Fri, Jan 18, 2019 at 2:34 PM Tsunakawa, Takayuki < tsunakawa.ta...@jp.fujitsu.com> wrote: > From: Laurenz Albe [mailto:laurenz.a...@cybertec.at] > > I think that transaction_read_only is good. > > > > If it is set to false, we are sure to be on a replication primary or > > stand-alone server,

Simplify set of flags used by MyXactFlags

Hi all, c5660e0 has introduced a new flag for MyXactFlags to restrict two-phase commit from working with temporary objects, and as a matter of fact XACT_FLAGS_ACCESSEDTEMPREL has been kept around to keep the error handling message compatible with past versions, still it is weird to keep both

Re: speeding up planning with partitions

Tsunakawa-san, On 2019/01/18 14:12, Tsunakawa, Takayuki wrote: > From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] >> Are you saying that, when using auto mode, all executions of the query >> starting from 7th are slower than the first 5 executions? That is, the >> latency of creating

Re: problems with foreign keys on partitioned tables

On 2019/01/18 7:54, Alvaro Herrera wrote: > On 2019-Jan-09, Amit Langote wrote: > >> 1. Foreign keys of partitions stop working correctly after being detached >> from the parent table > >> This happens because the action triggers defined on the PK relation (pk) >> refers to p as the referencing

RE: speeding up planning with partitions

Imai-san, From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] > On 2019/01/09 11:08, Imai, Yoshikazu wrote: > > I wonder why force_custom_plan is faster than auto after applied the patch. > > > > When we use PREPARE-EXECUTE, a generic plan is created and used if its > cost is > > cheaper

Re: pg_dump multi VALUES INSERT

On Thu, Jan 17, 2019 at 5:15 AM Surafel Temesgen wrote: > On Fri, Jan 4, 2019 at 3:08 PM David Rowley > wrote: >> >> On Mon, 31 Dec 2018 at 18:58, Surafel Temesgen wrote: >> >> >> 2. Is --insert-multi a good name? What if they do --insert-multi=1? >> That's not very "multi". Is

Re: Fix function name in commet in vacuumlazy.c

On Fri, Jan 18, 2019 at 12:50:15PM +0900, Masahiko Sawada wrote: > Attached small patch fixes the function name heap_vacuum_rel in the comment. > > s/vacuum_heap_rel/heap_vacuum_rel/ Fixed, thanks. -- Michael signature.asc Description: PGP signature

Re: Pluggable Storage - Andres's take

On Tue, 15 Jan 2019 at 17:58, Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > On Tue, Jan 15, 2019 at 10:52 AM Amit Khandekar > > wrote: > > > > Need to bump K_VERS_MINOR as well. > > I've bumped it up, but somehow this change escaped the previous version. Now > should be there, thanks! > > >

Re: ArchiveEntry optional arguments refactoring

On Wed, 16 Jan 2019 at 17:45, Dmitry Dolgov <9erthali...@gmail.com> wrote: > > Hi, > > During the discussion in [1] an idea about refactoring ArchiveEntry was > suggested. The reason is that currently this function has significant number > of > arguments that are "optional", and every change that

Re: draft patch for strtof()

This one builds ok on appveyor with at least three different VS versions. Though I've not tried the exact combination of commands used by cfbot... yet. -- Andrew (irc:RhodiumToad) diff --git a/configure b/configure index 06fc3c6835..e3176e24e9 100755 --- a/configure +++ b/configure @@ -15802,6

Re: Tid scan improvements

Hi all, I am a bit stuck and I think it's best to try to explain where. I'm still rebasing the patches for the changes Tom made to support parameterised TID paths for joins. While the addition of join support itself does not really touch the same code, the modernisation -- in particular,

Re: pg_dump multi VALUES INSERT

On Fri, 18 Jan 2019 at 01:15, Surafel Temesgen wrote: > The attache patch use your method mostly I disagree with the "mostly" part. As far as I can see, you took the idea and then made a series of changes to completely break it. For bonus points, you put back my comment change to make it

Re: current_logfiles not following group access and instead follows log_file_mode permissions

On Thu, Jan 17, 2019 at 5:49 AM Stephen Frost wrote: > Greetings, > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Stephen Frost writes: > > > * Michael Paquier (mich...@paquier.xyz) wrote: > > >> On Tue, Jan 15, 2019 at 10:53:30AM -0500, Tom Lane wrote: > > >>> On reflection, maybe the problem

Thread-unsafe coding in ecpg

I've found that a couple of different OpenBSD 6.4 machines fall over badly in the ecpg regression tests, with output like test sql/parser ... ok test thread/thread... stdout stderr FAILED (test process was terminated by signal 6: Abort trap) test

Fix function name in commet in vacuumlazy.c

Hi, Attached small patch fixes the function name heap_vacuum_rel in the comment. s/vacuum_heap_rel/heap_vacuum_rel/ Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center fix_heap_vacuum_rel.patch Description: Binary data

RE: Libpq support to connect to standby server as priority

From: Laurenz Albe [mailto:laurenz.a...@cybertec.at] > I think that transaction_read_only is good. > > If it is set to false, we are sure to be on a replication primary or > stand-alone server, which is enough to know for the load balancing use case. As Tatsuo-san said, setting

Shouldn't current_schema() be at least PARALLEL RESTRICTED?

Hi all, While working on the recent issues with 2PC and temporary objects I have added a test case based on current_schema() for the first time in history, and the buildfarm complained about it, as mentioned here: https://www.postgresql.org/message-id/20190118005949.gd1...@paquier.xyz The has

Re: Feature: temporary materialized views

Hi! On Thu, Jan 17, 2019 at 2:40 PM Andreas Karlsson wrote: > I did some functional testing today and everything seems to work as > expected other than that the tab completion for psql seems to be missing. Thanks. I can add those as soon as I figure how. :-) So what are next steps here besides

Re: Feature: temporary materialized views

Hi! On Thu, Jan 17, 2019 at 9:53 AM Andreas Karlsson wrote: > > What is the stumbling block to just leaving that alone? > > I think the issue Mitar ran into is that the temporary materialized view > is created in the rStartup callback of the receiver which happens after >

Re: [HACKERS] Block level parallel vacuum

On Tue, Jan 15, 2019 at 6:00 PM Masahiko Sawada wrote: > > Rebased. > I started reviewing the patch, I didn't finish my review yet. Following are some of the comments. +PARALLEL N + + + Execute index vacuum and cleanup index in parallel with I doubt that user can understand

Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)

On Thu, Jan 17, 2019 at 5:09 PM Peter Geoghegan wrote: > In the kludgey patch that I posted, the 4-byte value is manufactured > artificially within a backend in descending order. That may have a > slight advantage over object oid, even after the pg_depend correctness > issues are addressed. A

Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)

On Thu, Jan 17, 2019 at 4:40 PM Tom Lane wrote: > Yeah, that's the policy we've followed so far, but I remain concerned > about its effects on the regression tests. There are a lot of places > where we print full DROP CASCADE output because "it hasn't failed yet". > I fear every one of those is

Re: Libpq support to connect to standby server as priority

On Thu, 17 Jan 2019 at 19:56, Tatsuo Ishii wrote: > >> > I'm curious; under what circumstances would the above occur? > >> > >> Former primary goes down and one of standbys is promoting but it is > >> not promoted to new primary yet. > >> > > > > seems like JDBC might have some work to

Re: Libpq support to connect to standby server as priority

>> > I'm curious; under what circumstances would the above occur? >> >> Former primary goes down and one of standbys is promoting but it is >> not promoted to new primary yet. >> > > seems like JDBC might have some work to do...Thanks > > I'm going to wait to implement until we resolve this

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

On Thu, Jan 17, 2019 at 07:21:08PM -0500, Tom Lane wrote: > Sorry, I don't buy this line of argument. Reasonable test design requires > making cost/benefit tradeoffs: the cost to run the test over and over, > and the cost to maintain the test itself (e.g. fix portability issues in > it) have to

Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)

Peter Geoghegan writes: > On Thu, Jan 17, 2019 at 12:42 PM Tom Lane wrote: >> Now, perhaps we should make such stability a design goal, as it'd allow >> us to get rid of some "suppress the cascade outputs" hacks in the >> regression tests. But it's a bit of a new feature. If we wanted to >> do

Re: Libpq support to connect to standby server as priority

On Thu, 17 Jan 2019 at 19:38, Tatsuo Ishii wrote: > >> >> >> > From: Tatsuo Ishii [mailto:is...@sraoss.co.jp] > >> >> >> >> But pg_is_in_recovery() returns true even for a promoting > >> standby. So > >> >> >> >> you have to wait and retry to send pg_is_in_recovery() until it > >> >> >> >>

Re: Libpq support to connect to standby server as priority

>> >> >> > From: Tatsuo Ishii [mailto:is...@sraoss.co.jp] >> >> >> >> But pg_is_in_recovery() returns true even for a promoting >> standby. So >> >> >> >> you have to wait and retry to send pg_is_in_recovery() until it >> >> >> >> finishes the promotion to find out it is now a primary. I am not >>

Re: Libpq support to connect to standby server as priority

On Thu, 17 Jan 2019 at 19:09, Tsunakawa, Takayuki < tsunakawa.ta...@jp.fujitsu.com> wrote: > From: Dave Cramer [mailto:p...@fastcrypt.com] > > >> 2) If there's no node on which pg_is_in_recovery() returns > false, > > then > > >>we need to retry until we find it. To not retry

Re: Libpq support to connect to standby server as priority

On Thu, 17 Jan 2019 at 19:15, Tatsuo Ishii wrote: > > On Thu, 17 Jan 2019 at 18:03, Tatsuo Ishii wrote: > > > >> > On Wed, 16 Jan 2019 at 01:02, Tatsuo Ishii > wrote: > >> > > >> >> > From: Tatsuo Ishii [mailto:is...@sraoss.co.jp] > >> >> >> But pg_is_in_recovery() returns true even for a

Re: pgsql: Remove references to Majordomo

On Thu, Jan 17, 2019 at 01:04:44PM +, Magnus Hagander wrote: > Remove references to Majordomo > > Lists are not handled by Majordomo anymore and haven't been for a while, > so remove the reference and instead direct people to the list server. Wouldn't it be better to also switch the

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

Fabien COELHO writes: >> I am, TBH, inclined to fix this by removing that test case rather >> than teaching it another spelling to accept. I think it's very >> hard to make the case that tests like this one are anything but >> a waste of developer and buildfarm time. When they are also a >>

Re: Libpq support to connect to standby server as priority

> On Thu, 17 Jan 2019 at 18:03, Tatsuo Ishii wrote: > >> > On Wed, 16 Jan 2019 at 01:02, Tatsuo Ishii wrote: >> > >> >> > From: Tatsuo Ishii [mailto:is...@sraoss.co.jp] >> >> >> But pg_is_in_recovery() returns true even for a promoting standby. So >> >> >> you have to wait and retry to send

RE: Libpq support to connect to standby server as priority

From: Dave Cramer [mailto:p...@fastcrypt.com] > >> 2) If there's no node on which pg_is_in_recovery() returns false, > then > >>we need to retry until we find it. To not retry forever, there > >>should be a timeout counter parameter. > Checking the code I see we actually

Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)

On Thu, Jan 17, 2019 at 12:42 PM Tom Lane wrote: > So I poked around for awhile with running the regression tests under > ignore_system_indexes. There seem to be a number of issues involved > here. To a significant extent, they aren't bugs, at least not according > to the original conception of

Re: Libpq support to connect to standby server as priority

On Thu, 17 Jan 2019 at 18:03, Tatsuo Ishii wrote: > > On Wed, 16 Jan 2019 at 01:02, Tatsuo Ishii wrote: > > > >> > From: Tatsuo Ishii [mailto:is...@sraoss.co.jp] > >> >> But pg_is_in_recovery() returns true even for a promoting standby. So > >> >> you have to wait and retry to send

Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)

I wrote: > Also, I am suspicious that this implementation fails on point 3 > anyway ... If nothing else, it looks like ALTER OBJECT DEPENDS ON > EXTENSION can be used to attach a random dependency to just > about anything. Yup: regression=# drop table if exists idxpart cascade; DROP TABLE

Re: draft patch for strtof()

> "Andrew" == Andrew Gierth writes: Andrew> Because it turns out that Windows (at least the version running Andrew> on Appveyor) completely fucks this up; strtof() is apparently Andrew> returning infinity or zero _without setting errno_ for values Andrew> out of range for float: input of

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

On 2019-01-18 00:31, Tom Lane wrote: =?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes: And now also the NetBSD machine failed on pgbenchCheck. Indeed, as expected. Ok. should I leave it as it is for now? Please. I'll push a fix for the broken test case in a bit --- I just wanted to

Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)

On Thu, Jan 17, 2019 at 3:20 PM Tom Lane wrote: > Alvaro Herrera writes: > > There is a symmetry to these that led me to have the same kind of > > dependency from the index partition to the other two. > > It's symmetric as long as you suppose that the above are the only > requirements. However,

Re: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead

You introduced new macros IsHeapRelation and IsViewRelation, but I don't want to introduce such API. Such things have been heavily contested and I don't to have one more thing to worry about for this patch, so please just put the relkind directly in the code. On 2019-Jan-07, Nikolay Shaplov

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

=?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes: > And now also the NetBSD machine failed on pgbenchCheck. Indeed, as expected. > should I leave it as it is for now? Please. I'll push a fix for the broken test case in a bit --- I just wanted to confirm that somebody else's machines agreed that it's

Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)

Alvaro Herrera writes: > On 2019-Jan-17, Tom Lane wrote: >> Hm. Still, I can't believe that it's appropriate for a partitioned index >> to have exactly the same kind of dependency on the master index as it >> does on the associated table. > So there are three necessary features: > * The

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

=?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes: >> But it looks like in NetBSD the options are called: Sorry about that, I copied-and-pasted from the openbsd machine I was looking at without remembering that netbsd is just a shade different. > but the OpenBSD machine went further and now fails on: >

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

On 2019-01-18 00:00, Mikael Kjellström wrote: I just started another run on sidewinder (NetBSD 7), let's see how that goes. but the OpenBSD machine went further and now fails on: pgbenchCheck instead. Is that the failure you expected to get? And now also the NetBSD machine failed on

Re: Libpq support to connect to standby server as priority

> On Wed, 16 Jan 2019 at 01:02, Tatsuo Ishii wrote: > >> > From: Tatsuo Ishii [mailto:is...@sraoss.co.jp] >> >> But pg_is_in_recovery() returns true even for a promoting standby. So >> >> you have to wait and retry to send pg_is_in_recovery() until it >> >> finishes the promotion to find out it

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

On 2019-01-17 23:54, Mikael Kjellström wrote: But it looks like in NetBSD the options are called: netbsd7-pgbf# sysctl -a | grep semmn kern.ipc.semmni = 10 kern.ipc.semmns = 60 kern.ipc.semmnu = 30 so I will try and set that in /etc/sysctl.conf and reboot and see what happens. That

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

On 2019-01-17 23:37, Mikael Kjellström wrote: On 2019-01-17 23:23, Tom Lane wrote: Yeah, you might've been able to get by with OpenBSD/NetBSD's default semaphore settings before, but they really only let one postmaster run at a time; and the TAP tests want to start more than one. For me it

Re: problems with foreign keys on partitioned tables

On 2019-Jan-09, Amit Langote wrote: > 1. Foreign keys of partitions stop working correctly after being detached > from the parent table > This happens because the action triggers defined on the PK relation (pk) > refers to p as the referencing relation. On detaching p1 from p, p1's > data is no

Re: Protect syscache from bloating with negative cache entries

On 18/01/2019 08:48, Bruce Momjian wrote: On Thu, Jan 17, 2019 at 11:33:35AM -0500, Robert Haas wrote: The flaw in your thinking, as it seems to me, is that in your concern for "the likelihood that cache flushes will simply remove entries we'll soon have to rebuild," you're apparently unwilling

Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)

On 2019-Jan-17, Tom Lane wrote: > Alvaro Herrera writes: > > On 2019-Jan-17, Tom Lane wrote: > >> DEPENDENCY_INTERNAL_AUTO, however, broke this completely, as the code > >> has no hesitation about making multiple entries of that kind. After > >> rather cursorily looking at that code, I'm

Re: Feature: temporary materialized views

On 1/11/19 8:47 PM, Mitar wrote: Thanks for doing the review! I did some functional testing today and everything seems to work as expected other than that the tab completion for psql seems to be missing. Andreas

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

On 2019-01-17 23:23, Tom Lane wrote: Yeah, you might've been able to get by with OpenBSD/NetBSD's default semaphore settings before, but they really only let one postmaster run at a time; and the TAP tests want to start more than one. For me it seems to work to append this to

Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)

Alvaro Herrera writes: > On 2019-Jan-17, Tom Lane wrote: >> DEPENDENCY_INTERNAL_AUTO, however, broke this completely, as the code >> has no hesitation about making multiple entries of that kind. After >> rather cursorily looking at that code, I'm leaning to the position >> that

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

=?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes: >> Let's see if it works better this time. > Hmmm, nope: > 2019-01-17 23:09:20.343 CET [9129] FATAL: could not create semaphores: > No space left on device Yeah, you might've been able to get by with OpenBSD/NetBSD's default semaphore settings

Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)

On 2019-Jan-17, Tom Lane wrote: > DEPENDENCY_INTERNAL_AUTO, however, broke this completely, as the code > has no hesitation about making multiple entries of that kind. After > rather cursorily looking at that code, I'm leaning to the position > that DEPENDENCY_INTERNAL_AUTO is broken-by-design

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

On 2019-01-17 22:47, Mikael Kjellström wrote: On 2019-01-17 22:42, Tom Lane wrote: =?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes: It says: configure: error: Additional Perl modules are required to run TAP tests so how do I find out with Perl modules that are required? If you look into the

Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)

I wrote: > I propose that we handle this case by adding a new DEPFLAG_IS_SUBOBJECT > flag to the column object's flags, denoting that we know the whole table > will be dropped later. The only effect of this flag is to suppress > reporting of the column object in reportDependentObjects. Here's a

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

On 2019-01-17 22:42, Tom Lane wrote: =?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes: It says: configure: error: Additional Perl modules are required to run TAP tests so how do I find out with Perl modules that are required? If you look into the configure log it should say just above that, but

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

=?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes: > It says: > configure: error: Additional Perl modules are required to run TAP tests > so how do I find out with Perl modules that are required? If you look into the configure log it should say just above that, but I'm betting you just need p5-IPC-Run.

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

On 2019-01-17 22:19, Mikael Kjellström wrote: On 2019-01-17 22:16, Tom Lane wrote: For what it's worth I've enabled tap-tests for my OpenBSD 5.9 (curculio) and NetBSD 7 (sidewinder) animals now. Oh, thanks!  I'm guessing they'll fail their next runs, but I'll wait to see confirmation of

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

On 2019-01-17 22:16, Tom Lane wrote: For what it's worth I've enabled tap-tests for my OpenBSD 5.9 (curculio) and NetBSD 7 (sidewinder) animals now. Oh, thanks! I'm guessing they'll fail their next runs, but I'll wait to see confirmation of that before I do anything about the test bug.

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

=?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes: > On 2019-01-17 06:04, Tom Lane wrote: >> Although we've got a few NetBSD and OpenBSD buildfarm critters, >> none of them are doing --enable-tap-tests. If they were, we'd >> have noticed the pgbench regression tests falling over: > For what it's worth

Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

On 2019-01-17 06:04, Tom Lane wrote: Although we've got a few NetBSD and OpenBSD buildfarm critters, none of them are doing --enable-tap-tests. If they were, we'd have noticed the pgbench regression tests falling over: For what it's worth I've enabled tap-tests for my OpenBSD 5.9 (curculio)

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

tible_clause_internal(), > so maybe it's worth an Assert(IsA(var, Var)) along with a comment to > mention anything else could not have been allowed. Maybe. > 10. Does examine_equality_clause need 'root' as an argument? Probably not. I guess it's a residue some older version. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services 0001-multivariate-MCV-lists-20190117.patch.gz Description: application/gzip 0002-multivariate-histograms-20190117.patch.gz Description: application/gzip

Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)

Peter Geoghegan writes: > On Tue, Dec 18, 2018 at 2:26 PM Tom Lane wrote: >> Hm, that definitely leads me to feel that we've got bug(s) in >> dependency.c. I'll take a look sometime soon. > Thanks! > I'm greatly relieved that I probably won't have to become an expert on > dependency.c after

Re: Protect syscache from bloating with negative cache entries

On Thu, Jan 17, 2019 at 11:33:35AM -0500, Robert Haas wrote: > The flaw in your thinking, as it seems to me, is that in your concern > for "the likelihood that cache flushes will simply remove entries > we'll soon have to rebuild," you're apparently unwilling to consider > the possibility of

Re: Feature: temporary materialized views

Andreas Karlsson writes: > On 1/17/19 4:57 PM, Tom Lane wrote: >> What is the stumbling block to just leaving that alone? > I think the issue Mitar ran into is that the temporary materialized view > is created in the rStartup callback of the receiver which happens after >

Re: Proposal for Signal Detection Refactoring

On Thu, Jan 17, 2019 at 7:08 PM Andres Freund wrote: > Hi, > > On 2018-10-09 16:04:35 +0200, Peter Eisentraut wrote: > > More generally, I'd like this material to be code comments. It's the > > kind of stuff that gets outdated before long if it's kept separate. > > I'm not sure I buy this here

Re: ArchiveEntry optional arguments refactoring

Hi, On 2019-01-17 09:29:04 -0800, Andres Freund wrote: > On 2019-01-17 10:23:39 -0500, Tom Lane wrote: > > I don't buy the argument that this would move the goalposts in terms > > of how much work it is to add a new argument. You'd still end up > > touching every call site. > > Why? A lot of

Re: ArchiveEntry optional arguments refactoring

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2019-01-17 10:23:39 -0500, Tom Lane wrote: > > Alvaro Herrera writes: > > > On 2019-Jan-16, Dmitry Dolgov wrote: > > >> ArchiveEntry((ArchiveArgs){.tablespace = 3, > > >> .dumpFn = somefunc, > > >> ...}); > > > > > Is there real savings

Re: Proposal for Signal Detection Refactoring

Hi, On 2018-10-09 16:04:35 +0200, Peter Eisentraut wrote: > More generally, I'd like this material to be code comments. It's the > kind of stuff that gets outdated before long if it's kept separate. I'm not sure I buy this here - we don't have (but perhaps should?) a convenient location for an

Re: Feature: temporary materialized views

On 1/17/19 4:57 PM, Tom Lane wrote: Andreas Karlsson writes: On 1/11/19 8:47 PM, Mitar wrote: Is it really ok to just remove SECURITY_RESTRICTED_OPERATION from ExecCreateTableAs()? The comment there said that this is not really necessary for security: "This is not necessary for security,

Re: WIP: Avoid creation of the free space map for small tables

On Wed, Jan 16, 2019 at 10:35 PM Amit Kapila wrote: > Yes, I think it would be good if you can explain the concept of > local-map with the help of this example. > Then let's not add a reference to the version number in this case. I Okay, done in v14. I kept your spelling of the new macro. One

Re: Proposal for Signal Detection Refactoring

Hi, On 2019-01-17 10:50:56 +0100, Chris Travers wrote: > diff --git a/src/backend/utils/init/globals.c > b/src/backend/utils/init/globals.c > index c6939779b9..5ed715589e 100644 > --- a/src/backend/utils/init/globals.c > +++ b/src/backend/utils/init/globals.c > @@ -27,12 +27,35 @@ > >

Re: ArchiveEntry optional arguments refactoring

On 2019-01-17 10:23:39 -0500, Tom Lane wrote: > Alvaro Herrera writes: > > On 2019-Jan-16, Dmitry Dolgov wrote: > >> ArchiveEntry((ArchiveArgs){.tablespace = 3, > >> .dumpFn = somefunc, > >> ...}); > > > Is there real savings to be had by doing this? What would be the > > arguments to each

Re: Protect syscache from bloating with negative cache entries

On Sun, Jan 13, 2019 at 11:41 AM Tom Lane wrote: > Putting a limit on the size of the syscaches doesn't accomplish anything > except to add cycles if your cache working set is below the limit, or > make performance fall off a cliff if it's above the limit. If you're running on a Turing machine,

Re: Feature: temporary materialized views

Andreas Karlsson writes: > On 1/11/19 8:47 PM, Mitar wrote: >>> Is it really ok to just remove SECURITY_RESTRICTED_OPERATION from >>> ExecCreateTableAs()? >> The comment there said that this is not really necessary for security: >> "This is not necessary for security, but this keeps the behavior

Re: Proving IS NOT NULL inference for ScalarArrayOpExpr's

On Wed, Jan 16, 2019 at 8:49 AM James Coleman wrote: > > On Tue, Jan 15, 2019 at 11:37 PM Tom Lane wrote: > > Well, as I said upthread, it seems like we need to think a bit more > > carefully about what it is that clause_is_strict_for is testing --- > > and if that ends up finding that some

Re: Early WIP/PoC for inlining CTEs

Andreas Karlsson writes: > On 1/11/19 8:10 PM, Robert Haas wrote: >> WITH cte_name [[NOT] MATERIALIZED] AS (query) main_query... > Hm, when would one want "NOT MATERIALIZED"? I am not sure I see the > usefulness of forcing inlining other than if we by default do not inline > when a CTE is

Re: Feature: temporary materialized views

On 1/11/19 8:47 PM, Mitar wrote: In create_ctas_internal() why do you copy the relation even when you do not modify it? I was modelling this after code in view.c [1]. I can move copy into the "if". Makes sense. Is it really ok to just remove SECURITY_RESTRICTED_OPERATION from

Re: Early WIP/PoC for inlining CTEs

On 1/11/19 8:10 PM, Robert Haas wrote: WITH cte_name [[NOT] MATERIALIZED] AS (query) main_query... Hm, when would one want "NOT MATERIALIZED"? I am not sure I see the usefulness of forcing inlining other than if we by default do not inline when a CTE is referenced multiple times. Do you

Re: ArchiveEntry optional arguments refactoring

Alvaro Herrera writes: > On 2019-Jan-16, Dmitry Dolgov wrote: >> ArchiveEntry((ArchiveArgs){.tablespace = 3, >> .dumpFn = somefunc, >> ...}); > Is there real savings to be had by doing this? What would be the > arguments to each function? Off-hand, I'm not liking this idea too > much. I'm not

Re: Acceptable/Best formatting of callbacks (for pluggable storage)

On 2019-Jan-11, Andres Freund wrote: > Just as an example of why I think this isn't great: Hmm, to me, the first example is much better because of *vertical* space -- I can have the whole API in one screenful. In the other example, the same number of functions take many more lines. The fact

Re: ArchiveEntry optional arguments refactoring

On 2019-Jan-16, Dmitry Dolgov wrote: > Proposed idea is to refactor out all/optional arguments into a separate data > structure, so that adding/removing a new argument wouldn't change that much of > unrelated code. Then for every invocation of ArchiveEntry this structure needs > to be prepared

Re: [PROPOSAL] Shared Ispell dictionaries

I attached files of new version of the patch, I applied your tweaks. > XXX All dictionaries, but only when there's invalid dictionary? I've made a little optimization. I introduced hashvalue into TSDictionaryCacheEntry. Now released only DSM of altered or dropped dictionaries. > > /* XXX

Re: Libpq support to connect to standby server as priority

On Thu, 17 Jan 2019 at 05:59, Laurenz Albe wrote: > Tsunakawa, Takayuki wrote: > > From: Tom Lane [mailto:t...@sss.pgh.pa.us] > > > The problem here of course is that whoever invented > target_session_attrs > > > was unconcerned with following that precedent, so what we have is > > >

Re: Libpq support to connect to standby server as priority

On Wed, 16 Jan 2019 at 01:02, Tatsuo Ishii wrote: > > From: Tatsuo Ishii [mailto:is...@sraoss.co.jp] > >> But pg_is_in_recovery() returns true even for a promoting standby. So > >> you have to wait and retry to send pg_is_in_recovery() until it > >> finishes the promotion to find out it is now a

Re: Libpq support to connect to standby server as priority

On Tue, 15 Jan 2019 at 23:21, Tsunakawa, Takayuki < tsunakawa.ta...@jp.fujitsu.com> wrote: > From: Dave Cramer [mailto:p...@fastcrypt.com] > > The original desire should have been the ability to connect to a > > primary or a standby. So, I think we should go back to the original > thinking

Re: pg_dump multi VALUES INSERT

On Fri, Jan 4, 2019 at 3:08 PM David Rowley wrote: > On Mon, 31 Dec 2018 at 18:58, Surafel Temesgen > wrote: > > On Fri, Dec 28, 2018 at 6:46 PM Fabien COELHO > wrote: > >> > At first i also try to do it like that but it seems the function will > >> > became long and more complex to me > >> >

  1   2   >