Re: [HACKERS] POC: Cache data in GetSnapshotData()

Cache the SnapshotData for reuse: === In one of our perf analysis using perf tool it showed GetSnapshotData takes a very high percentage of CPU cycles on readonly workload when there is very high number of concurrent connections >= 64. Machine : cthulhu 8 node machine.

Re: [HACKERS] Adding hook in BufferSync for backup purposes

Hi hackers! > 8 авг. 2017 г., в 11:27, Tom Lane написал(а): > > My point is not to claim that we mustn't put a hook there. It's that what > such a hook could safely do is tightly constrained, and you've not offered > clear evidence that there's something useful to be done

Re: [HACKERS] Proposal: Improve bitmap costing for lossy pages

On Wed, Aug 23, 2017 at 9:45 AM, Dilip Kumar wrote: >> >> ... >> if (tbm->nentries <= tbm->maxentries / 2) >> { >> /* >> * We have made enough room. >> ... >> I think we could try higher fill factor, say, 0.9.

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On Sat, Aug 26, 2017 at 8:00 AM, Robert Haas wrote: > What happens if you say VACUUM partitioned_table (a), some_partition (b)? Using v9, if you do that: =# CREATE TABLE parent (id int) PARTITION BY RANGE (id); CREATE TABLE =# CREATE TABLE child_1_10001 partition of parent

Re: [HACKERS] NoMovementScanDirection in heapgettup() and heapgettup_pagemode()

On Mon, Aug 28, 2017 at 5:50 PM, Tom Lane wrote: > I think that's probably dead code given that ExecutorRun short-circuits > everything for NoMovementScanDirection. There is some use of > NoMovementScanDirection for indexscans, to denote an unordered index, > but likely that

Re: [HACKERS] show "aggressive" or not in autovacuum logs

On Mon, Aug 28, 2017 at 2:26 AM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > https://www.postgresql.org/docs/devel/static/runtime-config-client.html > > > > ​V​ > ACUUM performs an aggressive scan > ​Maybe this should gets its own thread/patch but I'll tack this on here since

Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90

On Mon, Aug 28, 2017 at 10:17 PM, Tom Lane wrote: > In the meantime, I think what we should do is commit the bug fix more or > less as I have it, and then work on Amit's concern about losing parallel > efficiency by separating the resetting of shared parallel-scan state > into

Re: [HACKERS] hash partitioning based on v10Beta2

On Mon, Aug 28, 2017 at 10:44 PM, yangjie wrote: > When the number of partitions and the data are more, adding new partitions, > there will be some efficiency problems. > I don't know how the solution you're talking about is how to implement a > hash partition? I am having

Re: [HACKERS] Re: [COMMITTERS] pgsql: pg_rewind: Fix some problems when copying files >2GB.

Michael Paquier writes: > I don't like breaking the abstraction of pg_log() with the existing > flags with some kind of pg_debug() layer. The set of APIs present now > in pg_rewind for logging is nice to have, and I think that those debug > messages should be

Re: [HACKERS] Re: [COMMITTERS] pgsql: pg_rewind: Fix some problems when copying files >2GB.

On Mon, Aug 28, 2017 at 11:24 PM, Robert Haas wrote: > On Mon, Aug 28, 2017 at 10:16 AM, Alvaro Herrera > wrote: >>> I am fine with however you want to handle it, but it seems odd to me >>> that we don't have a way of embedding INT64_FORMAT in a

Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90

Robert Haas writes: > On Mon, Aug 28, 2017 at 6:35 PM, Tom Lane wrote: >> Maybe parallel_aware should have more than two values, depending >> on whether the result of the node is context-dependent or not. > It seems likely the whole concept of

Re: [HACKERS] Protect syscache from bloating with negative cache entries

On Mon, Aug 28, 2017 at 5:24 AM, Kyotaro HORIGUCHI wrote: > This patch have had interferences from several commits after the > last submission. I amended this patch to follow them (up to > f97c55c), removed an unnecessary branch and edited some comments. I think

[HACKERS] Improving overflow checks when adding tuple to PGresult Re: [GENERAL] Retrieving query results

On Mon, Aug 28, 2017 at 3:05 PM, Michael Paquier wrote: > Attached are two patches: > 1) 0001 refactors the code around pqAddTuple to be able to handle > error messages and assign them in PQsetvalue particularly. > 2) 0002 adds sanity checks in pqAddTuple for overflows,

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

On Mon, Aug 28, 2017 at 4:59 PM, Fabien COELHO wrote: > > Hello Masahiko-san, > > Patch applies cleanly, compiles, works for me. Thank you for reviewing! > >>> At least: "Required to invoke" -> "Require to invoke". >> >> >> Fixed. > > > I meant the added one about -I, not

Re: [HACKERS] Custom allocators in libpq

On 29 August 2017 at 05:15, Tom Lane wrote: > Peter Eisentraut writes: > > On 8/28/17 15:11, Tom Lane wrote: > >> ... but it seems like you're giving up a lot of the possible uses if > >> you don't make it apply uniformly. I admit I'm not

Re: [HACKERS] show "aggressive" or not in autovacuum logs

On Mon, Aug 28, 2017 at 5:26 AM, Kyotaro HORIGUCHI wrote: > Currently the message shows the '%d skipped-frozen' message but > it is insufficient to verify the true effect. This is a patch to > show mode as 'aggressive' or 'normal' in the closing message of >

Re: [HACKERS] Write operations in parallel mode

On Mon, Aug 28, 2017 at 12:23 PM, Antonin Houska wrote: > Now that dynamic shared memory hash table has been committed > (8c0d7bafad36434cb08ac2c78e69ae72c194ca20) I wonder if it's still a big deal > to remove restrictions like this in (e.g. heap_update()): > > /* >

Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90

On Mon, Aug 28, 2017 at 6:35 PM, Tom Lane wrote: > but probably we should think of a more arm's-length way to do it. > Maybe parallel_aware should have more than two values, depending > on whether the result of the node is context-dependent or not. My original intent for the

Re: [HACKERS] Challenges preventing us moving to 64 bit transaction id (XID)?

On Thu, Jul 6, 2017 at 07:29:07AM -0700, Jim Finnerty wrote: > re: "The problem is if you want to delete from such a page. Then you need to > update the tuple's xmax and stick the new xid epoch somewhere." I am coming to this very late, but wouldn't such a row be marked using our

Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90

Robert Haas writes: > On Mon, Aug 28, 2017 at 3:00 PM, Tom Lane wrote: >> Count the "that"s (you're failing to notice the next line). > OK, true. But "Academic literature" -> "The academic literature" is > just second-guessing, I think. No, it was

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On Sat, Aug 26, 2017 at 8:00 AM, Robert Haas wrote: > On Thu, Aug 24, 2017 at 12:59 AM, Michael Paquier > wrote: >> Robert, Amit and other folks working on extending the existing >> partitioning facility would be in better position to answer

Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90

On Mon, Aug 28, 2017 at 3:00 PM, Tom Lane wrote: >> That sentence isn't wrong as written. > > Count the "that"s (you're failing to notice the next line). OK, true. But "Academic literature" -> "The academic literature" is just second-guessing, I think. >> I don't really

Re: [HACKERS] Custom allocators in libpq

Peter Eisentraut writes: > On 8/28/17 15:11, Tom Lane wrote: >> ... but it seems like you're giving up a lot of the possible uses if >> you don't make it apply uniformly. I admit I'm not sure how we'd handle >> the initial creation of a connection object with a

Re: [HACKERS] Custom allocators in libpq

On 8/28/17 15:11, Tom Lane wrote: > ... but it seems like you're giving up a lot of the possible uses if > you don't make it apply uniformly. I admit I'm not sure how we'd handle > the initial creation of a connection object with a custom malloc. The > obvious solution of requiring the functions

Re: [HACKERS] Custom allocators in libpq

On Mon, Aug 28, 2017 at 03:11:26PM -0400, Tom Lane wrote: > Aaron Patterson writes: > > I would like to be able to configure libpq with custom malloc functions. > > I can see the potential value of this ... > > > This patch doesn't replace all malloc calls to the

Re: [HACKERS] expanding inheritance in partition bound order

On Mon, Aug 28, 2017 at 6:38 AM, Amit Langote wrote: > I am worried about the open relcache reference in PartitionDispatch when > we start using it in the planner. Whereas there is a ExecEndModifyTable() > as a suitable place to close that reference, there doesn't

Re: [HACKERS] Custom allocators in libpq

Aaron Patterson writes: > I would like to be able to configure libpq with custom malloc functions. I can see the potential value of this ... > This patch doesn't replace all malloc calls to the configured ones, just > the mallocs related to creating result objects

Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90

Robert Haas writes: > On Mon, Aug 28, 2017 at 10:47 AM, Tom Lane wrote: > - fuller description. Academic literature on parallel query suggests that > + fuller description. The academic literature on parallel query suggests > That sentence isn't wrong

Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90

On Mon, Aug 28, 2017 at 10:47 AM, Tom Lane wrote: > That seems like an unacceptably fragile assumption. Even if it happens to > be true today, we would need to fix it sooner or later. (And I kinda > suspect it's possible to break it today, anyway. Treating PARAM_EXEC >

[HACKERS] Custom allocators in libpq

Hello! I would like to be able to configure libpq with custom malloc functions. The reason is that we have a Ruby wrapper that exposes libpq in Ruby. The problem is that Ruby's GC doesn't know how much memory has been allocated by libpq, so no pressure is applied to the GC when it should be.

[HACKERS] Write operations in parallel mode

Now that dynamic shared memory hash table has been committed (8c0d7bafad36434cb08ac2c78e69ae72c194ca20) I wonder if it's still a big deal to remove restrictions like this in (e.g. heap_update()): /* * Forbid this during a parallel operation, lest it allocate a combocid.

Re: [HACKERS] auto_explain : log queries with wrong estimation

On 08/24/2017 03:08 PM, Maksim Milyutin wrote: [...] > > AFAICS you want to introduce two additional per-node variables: >  - auto_explain_log_estimate_ratio that denotes minimum ratio (>= 1) between > real value and planned one. I would add 'min' prefix before 'ratio'. >  -

Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90

Amit Kapila writes: > On Mon, Aug 28, 2017 at 6:34 PM, Tom Lane wrote: >> If what you're complaining about is that I put back the "if >> (outerPlan->chgParam == NULL)" test to allow postponement of the >> recursive ExecReScan call, I'm afraid that

Re: [HACKERS] 1 test fails in make installcheck-world - database "regress_ecpg_user2" does not exist

> Thanks for reporting it! > My pleasure! So the initial issue didn't happen the 2nd time. So if misc_sanity was the only test failing then I guess my tests are working fine other than that. Sweet! When I get a break from work I'll review some patches! Best, Ryan

Re: [HACKERS] hash partitioning based on v10Beta2

On Sat, Aug 26, 2017 at 12:40 AM, yang...@highgo.com wrote: > A partition table can be create as bellow: > > CREATE TABLE h1 PARTITION OF h; > CREATE TABLE h2 PARTITION OF h; > CREATE TABLE h3 PARTITION OF h; This syntax is very problematic for reasons that have been

[HACKERS] Re: [COMMITTERS] pgsql: pg_rewind: Fix some problems when copying files >2GB.

On Mon, Aug 28, 2017 at 10:16 AM, Alvaro Herrera wrote: >> I am fine with however you want to handle it, but it seems odd to me >> that we don't have a way of embedding INT64_FORMAT in a translatable >> string. Surely that's going to be a problem in some case, sometime,

[HACKERS] Re: [COMMITTERS] pgsql: pg_rewind: Fix some problems when copying files >2GB.

Robert Haas wrote: > On Mon, Aug 28, 2017 at 9:05 AM, Alvaro Herrera > wrote: > > Robert Haas wrote: > >> pg_rewind: Fix some problems when copying files >2GB. > > > > I just noticed that this broke pg_rewind translation, because of the > > INT64_FORMAT marker in the

[HACKERS] Re: [COMMITTERS] pgsql: pg_rewind: Fix some problems when copying files >2GB.

On Mon, Aug 28, 2017 at 9:05 AM, Alvaro Herrera wrote: > Robert Haas wrote: >> pg_rewind: Fix some problems when copying files >2GB. > > I just noticed that this broke pg_rewind translation, because of the > INT64_FORMAT marker in the translatable string. The message

Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90

On Mon, Aug 28, 2017 at 6:34 PM, Tom Lane wrote: > Amit Kapila writes: >> On Mon, Aug 28, 2017 at 6:01 PM, Tom Lane wrote: >>> Um, what's different about that than before? > >> Earlier, we perform the rescan of all the nodes

Re: [HACKERS] 1 test fails in make installcheck-world - database "regress_ecpg_user2" does not exist

Ryan Murphy writes: > I did notice that the test seems to create a ROLE called regress_ecpg_user2: Right. > Could that implicitly create a database too? I know that I somehow have a > database named after my username / postgres role "murftown". Maybe you've got some

Re: [HACKERS] 1 test fails in make installcheck-world - database "regress_ecpg_user2" does not exist

> No, you're reading it backwards: the error is expected, but it's not > appearing in your results. I can duplicate this if I manually create > database "regress_ecpg_user2" before running ecpg's installcheck, > so I guess that's what you did. I can find no evidence that any > part of the PG

Re: [HACKERS] hash partitioning based on v10Beta2

On Sat, Aug 26, 2017 at 10:10 AM, yang...@highgo.com wrote: > Hi all, > > Now we have had the range / list partition, but hash partitioning is not > implemented yet. > Attached is a POC patch based on the v10Beta2 to add the > hash partitioning feature. > Although we will

Re: [HACKERS] [POC] hash partitioning

Hello Looking at your hash partitioning syntax, I implemented a hash partition in a more concise way, with no need to determine the number of sub-tables, and dynamically add partitions. Description The hash partition's implement is on the basis of the original range / list partition,and

[HACKERS] Re: [COMMITTERS] pgsql: pg_rewind: Fix some problems when copying files >2GB.

Robert Haas wrote: > pg_rewind: Fix some problems when copying files >2GB. I just noticed that this broke pg_rewind translation, because of the INT64_FORMAT marker in the translatable string. The message catalog now has this: msgid "received chunk for file \"%s\", offset " for this source

Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90

Amit Kapila writes: > On Mon, Aug 28, 2017 at 6:01 PM, Tom Lane wrote: >> Um, what's different about that than before? > Earlier, we perform the rescan of all the nodes before ExecProcNode, > so workers will always start (restart) after the scan

Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90

On Mon, Aug 28, 2017 at 6:01 PM, Tom Lane wrote: > Amit Kapila writes: >> With this change, it is quite possible that during rescans workers >> will not do any work. > > Um, what's different about that than before? > Earlier, we perform the rescan of

Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90

Amit Kapila writes: > With this change, it is quite possible that during rescans workers > will not do any work. Um, what's different about that than before? regards, tom lane -- Sent via pgsql-hackers mailing list

Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90

On Mon, Aug 28, 2017 at 1:59 AM, Tom Lane wrote: > I wrote: >> I think that the correct fix probably involves marking each parallel scan >> plan node as dependent on a pseudo executor parameter, which the parent >> Gather or GatherMerge node would flag as being changed on each

Re: [HACKERS] NoMovementScanDirection in heapgettup() and heapgettup_pagemode()

Mithun Cy writes: > I was trying to study NoMovementScanDirection part of heapgettup() and > heapgettup_pagemode(). If I am right there is no test in test suit to > hit this code. I did run make check-world could not hit it. Also, > coverage report in >

Re: [HACKERS] standby server crashes hard on out-of-disk-space in HEAD

On Tue, Jun 13, 2017 at 4:21 AM, Andres Freund wrote: > On 2017-06-12 15:12:23 -0400, Robert Haas wrote: >> Commit 4b4b680c3d6d8485155d4d4bf0a92d3a874b7a65 (Make backend local >> tracking of buffer pins memory efficient., vintage 2014) seems like a >> likely culprit here, but

Re: [HACKERS] Make pg_regress print a connstring with sockdir

On 28 August 2017 at 19:45, Tom Lane wrote: > Craig Ringer writes: > > It's a pain having to find the postmaster command line to get the port > > pg_regress started a server on. We print the port in the pg_regress > output, > > why not the socket

Re: [HACKERS] Make pg_regress print a connstring with sockdir

Craig Ringer writes: > It's a pain having to find the postmaster command line to get the port > pg_regress started a server on. We print the port in the pg_regress output, > why not the socket directory / host? I'm not following the point here. The test postmaster isn't

Re: [HACKERS] 1 test fails in make installcheck-world - database "regress_ecpg_user2" does not exist

Ryan Murphy writes: > And when I look at that diffs file, this is what I see: > - [NO_PID]: ECPGconnect: could not open database: FATAL: database > "regress_ecpg_user2" does not exist > Why would this database not be getting created? No, you're reading it backwards: the

Re: [HACKERS] psql --batch

I don't doubt about a sense of this configuration - but this specific combination depends on usage - so I don't think so using special option is good idea. Although I agree with you that detailed settings are definitely debatable, I'd say that at least it would be a more reasonable starting

Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?

On Mon, Aug 28, 2017 at 8:02 PM, Kyotaro HORIGUCHI wrote: > The first patch (0001-) fixes this problem, preventing the > problematic state of WAL segments by retarding restart LSN of a > physical replication slot in a certain condition. FWIW, I have this patch

Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?

Hello, This problem still occurs on the master. I rebased this to the current master. At Mon, 3 Apr 2017 08:38:47 +0900, Michael Paquier wrote in > On Mon, Apr 3, 2017 at 7:19 AM, Venkata B Nagothi

Re: [HACKERS] expanding inheritance in partition bound order

On 2017/08/26 3:28, Robert Haas wrote: > On Mon, Aug 21, 2017 at 2:10 AM, Amit Langote > wrote: >> [ new patches ] > > I am failing to understand the point of separating PartitionDispatch > into PartitionDispatch and PartitionTableInfo. That seems like an >

Re: [HACKERS] Make pg_regress print a connstring with sockdir

Craig Ringer wrote: > On 28 August 2017 at 15:19, Michael Paquier > wrote: > > > On Mon, Aug 28, 2017 at 4:07 PM, Craig Ringer > > wrote: > > > == starting postmaster== > > > running with PID 30235;

Re: [HACKERS] Restricting maximum keep segments by repslots

Hello, I'll add this to CF2017-09. At Mon, 06 Mar 2017 18:20:06 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20170306.182006.172683338.horiguchi.kyot...@lab.ntt.co.jp> > Thank you for the comment. > > At Fri, 3 Mar 2017 14:47:20 -0500, Peter

Re: [HACKERS] psql --batch

2017-08-28 11:05 GMT+02:00 Craig Ringer : > On 28 August 2017 at 16:23, Fabien COELHO wrote: > >> >> This doesn't really address the original issue though, that it's far from >>> obvious how to easily and correctly script psql. >>> >> >> That is

Re: [HACKERS] Race between SELECT and ALTER TABLE NO INHERIT

Hello, I'll add this to CF2017-09. At Tue, 27 Jun 2017 16:27:18 +0900, Amit Langote wrote in <75fe42df-b1d8-89ff-596d-d9da0749e...@lab.ntt.co.jp> > On 2017/06/26 18:44, Kyotaro HORIGUCHI wrote: > > At Mon, 26 Jun 2017 18:16:42 +0900, Amit Langote wrote: > >> >

Re: [HACKERS] show "aggressive" or not in autovacuum logs

Hello, Currently the message shows the '%d skipped-frozen' message but it is insufficient to verify the true effect. This is a patch to show mode as 'aggressive' or 'normal' in the closing message of vacuum. %d frozen-skipped when 'aggressive mode' shows the true effect of ALL_FROZEN. I will add

Re: [HACKERS] Protect syscache from bloating with negative cache entries

Thank you for your attention. At Mon, 14 Aug 2017 17:33:48 -0400, Peter Eisentraut wrote in <09fa011f-4536-b05d-0625-11f3625d8...@2ndquadrant.com> > On 1/24/17 02:58, Kyotaro HORIGUCHI wrote: > >> BTW, if you set a slightly larger > >> context size on the

Re: [HACKERS] WIP: Separate log file for extension

Craig Ringer wrote: > On 25 August 2017 at 15:12, Antonin Houska wrote: > > How will this play with syslog? csvlog? etc? There's nothing special about csvlog: the LogStream structure has a "destination" field, so if particular extension wants this kind

Re: [HACKERS] psql --batch

On 28 August 2017 at 16:23, Fabien COELHO wrote: > > This doesn't really address the original issue though, that it's far from >> obvious how to easily and correctly script psql. >> > > That is another interesting argument. I understood that the issue was > having to type

[HACKERS] 1 test fails in make installcheck-world - database "regress_ecpg_user2" does not exist

Hello Postgres Hackers, I want to become more helpful to the project, reviewing more patches and starting to write more of my own - and one of the first steps is to get all the tests passing so I can confidently review patches. It almost worked... I typed "make check" and all the tests passed.

Re: [HACKERS] [POC] hash partitioning

Hi young, On Mon, 28 Aug 2017 15:33:46 +0800 "yang...@highgo.com" wrote: > Hello > > Looking at your hash partitioning syntax, I implemented a hash partition in a > more concise way, with no need to determine the number of sub-tables, and > dynamically add partitions. I

Re: [HACKERS] psql --batch

This doesn't really address the original issue though, that it's far from obvious how to easily and correctly script psql. That is another interesting argument. I understood that the issue was having to type these options, but now it is also to remember which one are relevant and wanted,

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

Hello Masahiko-san, Patch applies cleanly, compiles, works for me. At least: "Required to invoke" -> "Require to invoke". Fixed. I meant the added one about -I, not the pre-existing one about -i. About the code: is_no_vacuum should be a bool? We can change it but I think there is no

Re: [HACKERS] psql --batch

On 28 August 2017 at 15:34, Pavel Stehule wrote: > > > 2017-08-28 9:33 GMT+02:00 Fabien COELHO : > >> >> ISTM that the real pain is the "-v ON_ERRORS_STOP=1" which I occasionally encountered as well, the other one letter ones are not too bad.

Re: [HACKERS] Make pg_regress print a connstring with sockdir

On 28 August 2017 at 15:19, Michael Paquier wrote: > On Mon, Aug 28, 2017 at 4:07 PM, Craig Ringer > wrote: > > == starting postmaster== > > running with PID 30235; connect with: > > psql

Re: [HACKERS] psql --batch

2017-08-28 9:33 GMT+02:00 Fabien COELHO : > > ISTM that the real pain is the "-v ON_ERRORS_STOP=1" which I occasionally >>> encountered as well, the other one letter ones are not too bad. Maybe it >>> would be enough to have a shortcut for this one, say "-B"? >>> >> >> I

Re: [HACKERS] psql --batch

ISTM that the real pain is the "-v ON_ERRORS_STOP=1" which I occasionally encountered as well, the other one letter ones are not too bad. Maybe it would be enough to have a shortcut for this one, say "-B"? I agree with last sentence. I don't think so -qAtX are expected always, but "-v

Re: [HACKERS] psql --batch

2017-08-28 8:56 GMT+02:00 Fabien COELHO : > > I find myself regurgitating the incantation >> >> psql -qAtX -v ON_ERRORS_STOP=1 >> >> quite a bit. It's not ... super friendly. >> >> It strikes me that we could possibly benefit from a 'psql --batch' option. >> >> Thoughts? >> >

Re: [HACKERS] Make pg_regress print a connstring with sockdir

On Mon, Aug 28, 2017 at 4:07 PM, Craig Ringer wrote: > == starting postmaster== > running with PID 30235; connect with: > psql "host='/tmp/pg_regress-j74yFE' port=50848 dbname='regression'" > == creating database

Re: [HACKERS] Make pg_regress print a connstring with sockdir

== starting postmaster== running with PID 30235; connect with: psql "host='/tmp/pg_regress-j74yFE' port=50848 dbname='regression'" == creating database "regression" == On 28 August 2017 at 14:08, Michael Paquier

Re: [HACKERS] psql --batch

On 28 August 2017 at 14:56, Fabien COELHO wrote: > > I find myself regurgitating the incantation >> >> psql -qAtX -v ON_ERRORS_STOP=1 >> >> quite a bit. It's not ... super friendly. >> >> It strikes me that we could possibly benefit from a 'psql --batch' option. >> >>

Re: [HACKERS] Re: Poor cost estimate with interaction between table correlation and partial indexes

Michael Malis wrote: > Hmm... It seems the command I used for obtaining a patch I got from > here https://wiki.postgresql.org/wiki/Working_with_Git truncated part > of the patch. I've attached the file generated from git diff > --patience master improve-partial-index-correlation-calculation >

Re: [HACKERS] psql --batch

I find myself regurgitating the incantation psql -qAtX -v ON_ERRORS_STOP=1 quite a bit. It's not ... super friendly. It strikes me that we could possibly benefit from a 'psql --batch' option. Thoughts? The link between -qAtX and "batch" is not that fully obvious, especially the unaligned

[HACKERS] NoMovementScanDirection in heapgettup() and heapgettup_pagemode()

Hi all, I was trying to study NoMovementScanDirection part of heapgettup() and heapgettup_pagemode(). If I am right there is no test in test suit to hit this code. I did run make check-world could not hit it. Also, coverage report in

Re: [HACKERS] Make pg_regress print a connstring with sockdir

On Mon, Aug 28, 2017 at 2:28 PM, Craig Ringer wrote: > It's a pain having to find the postmaster command line to get the port > pg_regress started a server on. We print the port in the pg_regress output, > why not the socket directory / host? > > How about > running on