Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On Thu, Jan 17, 2019 at 02:11:01PM +0900, Michael Paquier wrote: > Okay, I have begun digging into the patch, and extracted for now two > things which can be refactored first, giving a total of three patches: > - 0001, which creates WaitForOlderSnapshots to snapmgr.c. I think > that this can be

Re: Tid scan improvements

On Sat, 19 Jan 2019 at 05:35, Tom Lane wrote: > Edmund Horner writes: > > My patch uses the same path type and executor for all extractable > tidquals. > > > This worked pretty well, but I am finding it difficult to reimplement it > in > > the new tidpath.c code. > > I didn't like that approach

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On 19/01/2019 02:33, Michael Paquier wrote: > On Fri, Jan 18, 2019 at 07:58:06PM +0100, Vik Fearing wrote: >> My vote is to have homogeneous syntax for all of this, and so put it in >> parentheses, but we should also allow CREATE INDEX and DROP INDEX to use >> parentheses for it, too. > > That

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

On 2019-Jan-18, Peter Geoghegan wrote: > On Fri, Jan 18, 2019 at 3:34 PM Tom Lane wrote: > > * There is still instability in which object you get told to drop > > when attempting to drop an index partition or trigger, as a consequence > > of there being two possible DEPENDENCY_INTERNAL_AUTO

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

On Fri, Jan 18, 2019 at 09:50:40AM -0500, Stephen Frost wrote: > It'd probably be good to give folks an opportunity to voice their > opinion regarding their use-case for the file existing as it does and > being documented as it is. At first blush, to me anyway, it seems like > maybe this was a

Re: Prepare Transaction support for ON COMMIT DROP temporary tables

On Fri, Jan 18, 2019 at 10:39:46AM -0500, Robert Haas wrote: > Huh. Well, in that case, I'm not sure I understand we really need to > do beyond removing the error checks for the case where all tables are > on-commit-drop. I have not looked at the patch in details, but we should really be careful

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On Fri, Jan 18, 2019 at 07:58:06PM +0100, Vik Fearing wrote: > My vote is to have homogeneous syntax for all of this, and so put it in > parentheses, but we should also allow CREATE INDEX and DROP INDEX to use > parentheses for it, too. That would be a new thing as these variants don't exist yet,

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

On Fri, Jan 18, 2019 at 03:30:16PM -0500, Robert Haas wrote: > It seems like, as currently implemented, the function is > parallel-unsafe, because any inserts, updates, or deletes are > currently parallel-unsafe, including insertions into catalogs. But I > am a bit confused why a function that is

House style for DocBook documentation?

Hi, Is there, somewhere, a written-up "house style" for what DocBook 4.2 elements to use for which types of content in the manual? In func.sgml I'm seeing what looks like a variety of examples, and I'm not sure which ones to try to follow. Thanks, -Chap

Re: pgsql: Restrict the use of temporary namespace in two-phase transaction

On Sat, Jan 19, 2019 at 09:08:27AM +0900, Michael Paquier wrote: > On Fri, Jan 18, 2019 at 03:34:30PM -0500, Tom Lane wrote: >> Seems hard to avoid. We could conceivably make it return "pg_temp" >> for the temp schema instead of the schema's actual name, but it's >> not very hard to think of ways

Re: Protect syscache from bloating with negative cache entries

Hi, On 2019-01-18 19:57:03 -0500, Robert Haas wrote: > On Fri, Jan 18, 2019 at 4:23 PM and...@anarazel.de wrote: > > My proposal for this was to attach a 'generation' to cache entries. Upon > > access cache entries are marked to be of the current > > generation. Whenever existing memory isn't

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

On Fri, Jan 18, 2019 at 4:24 PM Tom Lane wrote: > > I thought that your ALTER OBJECT DEPENDS ON EXTENSION example made the > > case for fixing that directly inarguable. I'm slightly surprised that > > you're not fully convinced of this already. Have I missed some > > subtlety? > > It's clear that

Re: Protect syscache from bloating with negative cache entries

On Fri, Jan 18, 2019 at 4:23 PM and...@anarazel.de wrote: > My proposal for this was to attach a 'generation' to cache entries. Upon > access cache entries are marked to be of the current > generation. Whenever existing memory isn't sufficient for further cache > entries and, on a less frequent

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

Peter Geoghegan writes: > On Fri, Jan 18, 2019 at 3:34 PM Tom Lane wrote: >> Attached is a draft patch to sort objects before the recursion step >> in findDependentObjects. I found that sorting by descending OID is >> really the right thing; if we sort by increasing OID then we get a >> whole

Re: pgsql: Restrict the use of temporary namespace in two-phase transaction

On Fri, Jan 18, 2019 at 03:34:30PM -0500, Tom Lane wrote: > Seems hard to avoid. We could conceivably make it return "pg_temp" > for the temp schema instead of the schema's actual name, but it's > not very hard to think of ways whereby that would make use of the > result fail in contexts where it

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

On Fri, Jan 18, 2019 at 3:34 PM Tom Lane wrote: > I think the tiebreaker idea is just a hack, because it'd only be stable > to the extent that the added tiebreaker values are stable, and they > wouldn't be very much so if the counter state is only kept per-backend. > > Attached is a draft patch

Re: pgsql: Remove references to Majordomo

On Fri, Jan 18, 2019 at 10:02:47AM -0500, Tom Lane wrote: > Magnus Hagander writes: >> You are right, we definitely should. I'll go ahead and fix that. I can't >> quite make up my mind on if it's a good idea to backpatch that though -- >> it's certainly safe enough to do, but it might cause

Re: jsonpath

On Sat, Jan 19, 2019 at 1:32 AM Tomas Vondra wrote: > On 1/18/19 6:58 PM, Alexander Korotkov wrote: > > So, it looks like we can just remove then. But I think we're very > > likely can commit jsonpath patch to PostgreSQL 12, but I'm not sure > > about other patches. So, having those functions

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

Peter Geoghegan writes: > On Thu, Jan 17, 2019 at 4:40 PM Tom Lane wrote: >> We're going to stick all these items into an ObjectAddress array anyway, >> so at worst it'd be 2X growth, most likely a lot less since we'd only >> be sorting one level of dependency at a time. > It sounds like we

Re: Delay locking partitions during INSERT and UPDATE

On 11/22/18, David Rowley wrote: > If required, such operations could LOCK TABLE the top partitioned > table to block the DML operation. There's already a risk of similar > deadlocks from such operations done on multiple separate tables when > the order they're done is not the same as the order

Re: jsonpath

On 1/18/19 6:58 PM, Alexander Korotkov wrote: > Nikita, thank you! > > I noticed another thing. 3-arguments version of functions > jsonpath_exists(), jsonpath_predicate(), jsonpath_query(), > jsonpath_query_wrapped() are: > > 1) Not documented > 2) Not used in operator definitions > 3) Not used

Re: What to name the current heap after pluggable storage / what to rename?

Hi, On 2019-01-16 08:20:37 -0800, Andres Freund wrote: > On January 16, 2019 8:08:09 AM PST, Robert Haas wrote: > >On Tue, Jan 15, 2019 at 10:23 PM Haribabu Kommi > > wrote: > >> access/relation.[c|h] name is fine. Or how about access/rel.[c|h], > >> because nodes/relation.h is related to

Re: problems with foreign keys on partitioned tables

On 2019-Jan-18, Amit Langote wrote: > OK, I agree. I have updated the patch to make things work that way. Thanks, this is better. There were a few other things I didn't like, so I updated it. Mostly, two things: 1. I didn't like a seqscan on pg_trigger, so I turned that into an indexed scan

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

Maybe on OpenBSD pg should switch srandom to srandom_deterministic? Dunno. I'm fairly annoyed by their idea that they're smarter than POSIX. However, for most of our uses of srandom, this behavior isn't awful; it's only pgbench that has an expectation that the platform random() can be made

Re: Alternative to \copy in psql modelled after \g

Tom Lane wrote: > I took a quick look at this patch. PFA an updated patch addressing your comments and Fabien's. I've also changed handleCopyOut() to return success if it could pump the data without writing it out locally for lack of an output stream. It seems to make more sense like

TestForOldSnapshot() seems to be in the wrong place

Hi, Currently TestForOldSnapshot() is defined as extern void TestForOldSnapshot_impl(Snapshot snapshot, Relation relation); ... /* * Check whether the given snapshot is too old to have safely read the given * page from the given table. If so, throw a "snapshot too old" error. * * This test

Re: Protect syscache from bloating with negative cache entries

Robert Haas writes: > On Thu, Jan 17, 2019 at 2:48 PM Bruce Momjian wrote: >> Unfortunately, because we have not found something we are happy with, we >> have done nothing. I agree LRU can be expensive. What if we do some >> kind of clock sweep and expiration like we do for shared buffers? I

Re: [PATCH] pgbench tap tests fail if the path contains a perl special character

> Pushed with that correction. Thanks a lot! -- Raúl Marín Rodríguez carto.com

Re: Protect syscache from bloating with negative cache entries

On Thu, Jan 17, 2019 at 2:48 PM Bruce Momjian wrote: > Well, I think everyone agrees there are workloads that cause undesired > cache bloat. What we have not found is a solution that doesn't cause > code complexity or undesired overhead, or one that >1% of users will > know how to use. > >

Re: Early WIP/PoC for inlining CTEs

On Fri, Jan 18, 2019 at 3:42 PM Andres Freund wrote: > On 2019-01-18 15:34:46 -0500, Robert Haas wrote: > > On Thu, Jan 17, 2019 at 10:48 AM Andreas Karlsson wrote: > > > On 1/11/19 8:10 PM, Robert Haas wrote: > > > > WITH cte_name [[NOT] MATERIALIZED] AS (query) main_query... > > > > > > Hm,

Re: Early WIP/PoC for inlining CTEs

On 2019-01-18 15:34:46 -0500, Robert Haas wrote: > On Thu, Jan 17, 2019 at 10:48 AM Andreas Karlsson wrote: > > 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 > >

Re: pgsql: Restrict the use of temporary namespace in two-phase transaction

Robert Haas writes: > On Thu, Jan 17, 2019 at 8:08 PM Tom Lane wrote: >>> Anyway, it seems to me that this is pointing out to another issue: >>> current_schema() can trigger a namespace creation, hence shouldn't we >>> mark it as PARALLEL UNSAFE and make sure that we never run into this >>>

Re: Early WIP/PoC for inlining CTEs

On Thu, Jan 17, 2019 at 10:48 AM Andreas Karlsson wrote: > 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

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

On Thu, Jan 17, 2019 at 9:46 PM Michael Paquier wrote: > 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: >

Re: [PATCH] pgbench tap tests fail if the path contains a perl special character

I wrote: > So the patch as given should work. ... well, modulo the use of "@foo" where you should've used "$foo". I don't know enough Perl to understand why that seemed to work, but I do know it's not the right thing here. Pushed with that correction. regards, tom lane

Re: Using Btree to Provide Sorting on Suffix Keys with LIMIT

On Thu, Jan 10, 2019 at 6:52 PM Peter Geoghegan wrote: > > On Sat, Dec 29, 2018 at 6:50 PM David Rowley > wrote: > > > Areas of extension: (given index `(a, b, c)`) include `a = 1 and b in > > > (...) order by c` and `a in (...) and b = 1 order by c` (and further > > > similar derivations with

Re: New vacuum option to do only freezing

On Thu, Jan 17, 2019 at 1:57 AM Masahiko Sawada wrote: > The reason why I processed the tuples that became dead after the first > heap pass is that I was not sure the reason why we ignore such tuples > in the second heap pass despite of there already have been the code > doing so which has been

Re: pgsql: Restrict the use of temporary namespace in two-phase transaction

On Thu, Jan 17, 2019 at 8:08 PM Tom Lane wrote: > > Anyway, it seems to me that this is pointing out to another issue: > > current_schema() can trigger a namespace creation, hence shouldn't we > > mark it as PARALLEL UNSAFE and make sure that we never run into this > > problem? > > That seems a

Re: [PATCH] pgbench tap tests fail if the path contains a perl special character

Alvaro Herrera writes: >>> This does not look right to me: glob has a different set of special >>> characters than regexes, no? > Perhaps you can do >@quoted = map { quotemeta($_) } @logs; Actually, playing with it here, it seems that quotemeta() quotes anything that's a special character

Re: Feature: temporary materialized views

Hi! On Fri, Jan 18, 2019 at 7:18 AM Andreas Karlsson wrote: > These rules are usually pretty easy to add. Just take a look in > src/bin/psql/tab-complete.c to see how it is usually done. Thanks. I have added the auto-complete and attached a new patch. > I might take a stab at refactoring this

Re: [PATCH] pgbench tap tests fail if the path contains a perl special character

On 2019-Jan-18, Raúl Marín Rodríguez wrote: > Hi, > > > Fun. But is that really the only place that fails? > > Yes, other than this it builds flawlessly. > > > This does not look right to me: glob has a different set of special > > characters than regexes, no? > > The issue itself manifests

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On 16/01/2019 18:59, Alvaro Herrera wrote: > On 2019-Jan-16, Michael Paquier wrote: > >> Regarding the grammar, we tend for the last couple of years to avoid >> complicating the main grammar and move on to parenthesized grammars >> (see VACUUM, ANALYZE, EXPLAIN, etc). So in the same vein I think

More OpenBSD portability fun: getopt() fails on --option

Continuing the project of getting check-world to pass on OpenBSD 6.4, I find that the bin/scripts/ tests fall over: t/090_reindexdb.pl (Wstat: 7424 Tests: 10 Failed: 2) Failed tests: 9-10 Non-zero exit status: 29 Parse errors: Bad plan. You planned 23 tests but ran 10.

Re: jsonpath

Nikita, thank you! I noticed another thing. 3-arguments version of functions jsonpath_exists(), jsonpath_predicate(), jsonpath_query(), jsonpath_query_wrapped() are: 1) Not documented 2) Not used in operator definitions 3) Not used in subsequent patches So, it looks like we can just remove

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

Fabien COELHO writes: >> all is explained here: >> https://man.openbsd.org/srandom >> Or at least most is explained there. > Yep. They try to be more serious than other systems about PRNG, which is > not bad in itself. > Maybe on OpenBSD pg should switch srandom to srandom_deterministic?

Re: [PATCH] pgbench tap tests fail if the path contains a perl special character

Hi, > Fun. But is that really the only place that fails? Yes, other than this it builds flawlessly. > This does not look right to me: glob has a different set of special > characters than regexes, no? The issue itself manifests in the grep call, not in glob, but I tried using `quotemeta` only

Re: [PATCH] pgbench tap tests fail if the path contains a perl special character

=?UTF-8?B?UmHDumwgTWFyw61uIFJvZHLDrWd1ZXo=?= writes: > As mentioned in the subject, if the $PATH where you are building postgres > contains a perl's special character [1], for example a `+`, pgbench's tap > tests will fail. Fun. But is that really the only place that fails? > I'm attaching a

[PATCH] pgbench tap tests fail if the path contains a perl special character

Hi, As mentioned in the subject, if the $PATH where you are building postgres contains a perl's special character [1], for example a `+`, pgbench's tap tests will fail. The outputs looks something like this (full at [2]): ``` # Failed test 'file name format' # at t/001_pgbench_with_server.pl

Re: Tid scan improvements

Edmund Horner writes: > My patch uses the same path type and executor for all extractable tidquals. > This worked pretty well, but I am finding it difficult to reimplement it in > the new tidpath.c code. I didn't like that approach to begin with, and would suggest that you go over to using a

Re: Prepare Transaction support for ON COMMIT DROP temporary tables

On Fri, Jan 18, 2019 at 4:50 AM Vik Fearing wrote: > Isn't that what happens already? PrepareTransaction() calls > PreCommit_on_commit_actions() from what I can tell. Huh. Well, in that case, I'm not sure I understand we really need to do beyond removing the error checks for the case where all

Re: Feature: temporary materialized views

On 1/18/19 2:53 AM, Mitar wrote:> 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. :-) These

Re: pgsql: Remove references to Majordomo

Magnus Hagander writes: > On Fri, Jan 18, 2019 at 1:26 AM Michael Paquier wrote: >> Wouldn't it be better to also switch the references to pgsql-bugs in >> all the C code for the different --help outputs? > You are right, we definitely should. I'll go ahead and fix that. I can't > quite make up

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

Greetings, * Haribabu Kommi (kommi.harib...@gmail.com) wrote: > On Thu, Jan 17, 2019 at 5:49 AM Stephen Frost wrote: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > > Now, if the expectation is that current_logfiles is just an internal > > > working file that users shouldn't access directly, then

Re: pg_dump multi VALUES INSERT

On Tue, Dec 25, 2018 at 4:47 AM Fabien COELHO wrote: > ISTM that command-line switches with optional arguments should be avoided: > This feature is seldom used (hmmm... 2 existing instances), because it > interferes with argument processing if such switches are used as the last > one. Excellent

Re: pg_dump multi VALUES INSERT

On Fri, Jan 18, 2019 at 5:02 AM Surafel Temesgen wrote: > On Fri, Jan 18, 2019 at 2:29 PM David Rowley > wrote: >> >> On Fri, 18 Jan 2019 at 19:29, Surafel Temesgen wrote: >> > this happen because i don't disallow the usage of --inserts and >> > --rows-per-insert >> > option together.it

Re: monitoring CREATE INDEX [CONCURRENTLY]

Hi Alvaro, The WIP patch needs a rebase. Please see few in-line comments. On Fri, Dec 21, 2018 at 3:30 AM Alvaro Herrera wrote: > Monitoring progress of CREATE INDEX [CONCURRENTLY] is sure to be welcome, > so here's a proposal. > > There are three distinct interesting cases. One is straight

Re: Log a sample of transactions

On 1/18/19 9:03 AM, Peter Eisentraut wrote: But if you have trouble with a specific transaction, how will a setting help that randomly logs transactions, not necessarily the one you are concerned about? Yes, it assumes your application performs same type of transaction. Maybe the use case is

Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0

(2019/01/16 14:45), Etsuro Fujita wrote: (2019/01/15 11:42), Amit Langote wrote: On 2019/01/11 21:50, Etsuro Fujita wrote: (2019/01/10 10:41), Amit Langote wrote: That's a loaded meaning and abusing it to mean something else can be challenged, but we can live with that if properly documented.

Re: [HACKERS] Block level parallel vacuum

On Fri, Jan 18, 2019 at 10:38 AM Haribabu Kommi wrote: > > > 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. Thank you for reviewing the patch. > > +PARALLEL

Re: pg_dump multi VALUES INSERT

On Fri, Jan 18, 2019 at 2:29 PM David Rowley wrote: > On Fri, 18 Jan 2019 at 19:29, Surafel Temesgen > wrote: > > this happen because i don't disallow the usage of --inserts and > --rows-per-insert > > option together.it should be error out in those case.i correct it in > attached patch > > I

Re: Ryu floating point output patch

> "Andrew" == Andrew Gierth writes: Andrew> 4. Passes regression tests Well, almost. I missed a contrib module, and there's some issues with rounding and subnormal values on Windows that I need to track down. -- Andrew (irc:RhodiumToad)

Re: pg_dump multi VALUES INSERT

On Fri, 18 Jan 2019 at 19:29, Surafel Temesgen wrote: > this happen because i don't disallow the usage of --inserts and > --rows-per-insert > option together.it should be error out in those case.i correct it in attached > patch I don't think it should be an error. It's not like the two

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

I've attached an updated patch. The last one no longer applied due to the changes made in d723f5687 -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services v10-0001-Forgo-generating-single-subpath-Append-and-Merge.patch

Re: Delay locking partitions during INSERT and UPDATE

On Fri, 18 Jan 2019 at 19:08, sho kato wrote: > I confirmed that this patch improve performance by 10 times or more. Thanks for testing this out. > Also, I did make installcheck world, but test partition_prune failed. > However, this test case failed even before applying a patch, so this patch

Re: pgsql: Remove references to Majordomo

On Fri, Jan 18, 2019 at 1:26 AM Michael Paquier wrote: > 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

Re: Pluggable Storage - Andres's take

On Fri, 18 Jan 2019 at 10:13, Amit Khandekar wrote: > On Tue, 15 Jan 2019 at 17:58, Dmitry Dolgov <9erthali...@gmail.com> wrote: > > Also I guess another attached patch should address the psql part, namely > > displaying a table access method with \d+ and possibility to hide it with a > > psql

Re: proposal - plpgsql unique statement id

pá 18. 1. 2019 v 8:56 odesílatel Peter Eisentraut < peter.eisentr...@2ndquadrant.com> napsal: > 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

Re: Ryu floating point output patch

> "Donald" == Donald Dong writes: Donald> I attached my changes as a patch. BTW, doing that in a thread about a commitfest patch confuses the commitfest app and cfbot (both of which think it's a new version of the patch under discussion), so best avoided. -- Andrew (irc:RhodiumToad)

Re: Prepare Transaction support for ON COMMIT DROP temporary tables

On 16/01/2019 17:44, Robert Haas wrote: > On Mon, Jan 14, 2019 at 1:41 PM Dimitri Fontaine > wrote: >> One idea would be that if every temp table in the session belongs to the >> transaction, and their namespace too (we could check through pg_depend >> that the namespace doesn't contain anything

Re: using expression syntax for partition bounds

Thanks for the comments. On 2019/01/18 16:48, Peter Eisentraut wrote: >> How about the following note in the documentation: >> >> + Although volatile expressions such as >> + CURRENT_TIMESTAMP can be used >> + for this, be careful when using them, because >> + PostgreSQL will

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

BTW, if you're wondering why curculio is still failing the pgbench test, Hmmm, that is interesting! It shows that at least some TAP tests are useful. all is explained here: https://man.openbsd.org/srandom Or at least most is explained there. Yep. They try to be more serious than

Re: Protect syscache from bloating with negative cache entries

At Fri, 18 Jan 2019 16:39:29 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20190118.163929.229869562.horiguchi.kyot...@lab.ntt.co.jp> > Hello. > > At Fri, 18 Jan 2019 11:46:03 +1300, Gavin Flower > wrote in > <4e62e6b7-0ffb-54ae-3757-5583fcca3...@archidevsys.co.nz> > > On

Re: Libpq support to connect to standby server as priority

Tsunakawa, Takayuki 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, which is enough to know for the load balancing use case. > > As

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

I'd rather keep it by simply adding the "|unknown" alternative. 30 years of programming have taught me that testing limit & error cases is useful, although you never know when it will be proven so. Sorry, I don't buy this line of argument. Reasonable test design requires making

RE: libpq debug log

Hi, I have developed a new libpq trace logging aimed at checking which side (server or client) is causing the performance issue. The new libpq trace log can do the following things; - Setting whether to get log or not by using connection strings or environment variables. It means that

Re: Log a sample of transactions

On 15/01/2019 18:03, Adrien NAYRAT wrote: > The goal is not to find slow queries in a transaction, but troubleshoot > applicative issue when you have short queries. > > Sometimes you want to understand what happens in a transaction, either > you perfectly know your application, either you have