list partition constraint shape

Hi. I recently posted to the list about a couple of problems I saw when using array type column as the partition key. One of them was that the internal partition constraint expression that we generate for list partitions is of a form that the backend would reject if the partition key column is an

Re: [HACKERS] replace GrantObjectType with ObjectType

On Wed, Dec 13, 2017 at 1:46 AM, Peter Eisentraut wrote: > OK, here is a bigger patch set that addresses these issues. I have > added OBJECT_RELATION to reflect the difference between TABLE and > RELATION. I have also renamed NAMESPACE to SCHEMA. And then I got rid > of AclObjectKind as well, b

Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

On 2017-12-13 16:02:45 +0900, Masahiko Sawada wrote: > When we add extra blocks on a relation do we access to the disk? I > guess we just call lseek and write and don't access to the disk. If so > the performance degradation regression might not be much. Usually changes in the file size require th

server crash with CallStmt

HI, Consider the below test: postgres@110311=#call sum(2+2); server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. Call stack: (gdb) bt #0 0

Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

On Wed, Dec 13, 2017 at 12:42 AM, Robert Haas wrote: > On Mon, Dec 11, 2017 at 4:10 PM, Masahiko Sawada > wrote: >> Thank you for updating the patch. Here is two minor comments. >> >> + * we acquire the same relation extension lock repeatedly. nLocks is 0 is >> the >> + * number of times we've

Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" in child table must be marked NOT NULL

2017-12-13 9:10 GMT+07:00 Michael Paquier : > > It is not the first time that this topic shows up. See for example > this thread from myself's version of last year: > https://www.postgresql.org/message-id/CAB7nPqTPXgX9HiyhhtAgpW7jbA1is > kmcsoqxpeeb_kyxyy1...@mail.gmail.com > Or this one: > http:/

Re: Using ProcSignal to get memory context stats from a running backend

On 13 December 2017 at 12:10, Michael Paquier wrote: > On Mon, Dec 11, 2017 at 10:07 PM, Craig Ringer > wrote: > > On 12 December 2017 at 12:43, Andres Freund wrote: > >> On 2017-12-12 11:57:41 +0800, Craig Ringer wrote: > >> But that'd have > >> the disadvanatage that it possibly would take a

Top-N sorts verses parallelism

Hi hackers, The start-up cost of bounded (top-N) sorts is sensitive at the small end of N, and the comparison_cost * tuples * LOG2(2.0 * output_tuples) curve doesn't seem to correspond to reality. Here's a contrived example that comes from a benchmark: create table foo as select generate_s

Re: [HACKERS] parallel.c oblivion of worker-startup failures

On Wed, Dec 13, 2017 at 12:31 AM, Robert Haas wrote: > On Mon, Dec 11, 2017 at 10:41 PM, Amit Kapila wrote: >> In particular, if the worker crashed (say somebody forcefully killed >> the worker), then I think it will lead to a restart of the server. So >> not sure, adding anything about that in

Re: Boolean partitions syntax

On 2017/12/12 15:39, Amit Langote wrote: > On 2017/12/12 15:35, Amit Langote wrote: >> Works for me, updated patch attached. > > Oops, attached the old one with the last email. > > Updated one really attached this time. Added to CF: https://commitfest.postgresql.org/16/1410/ Thanks, Amit

Re: Parallel Index Scan vs BTP_DELETED and BTP_HALF_DEAD

On Wed, Dec 13, 2017 at 10:33 AM, Kuntal Ghosh wrote: > On Tue, Dec 12, 2017 at 5:20 PM, Amit Kapila wrote: >> On Tue, Dec 12, 2017 at 4:00 PM, Kuntal Ghosh >> wrote: >>> On Mon, Dec 11, 2017 at 2:26 PM, Thomas Munro >>> wrote: On Mon, Dec 11, 2017 at 8:14 PM, Amit Kapila wrote: >>>

Re: Parallel Index Scan vs BTP_DELETED and BTP_HALF_DEAD

On Tue, Dec 12, 2017 at 5:20 PM, Amit Kapila wrote: > On Tue, Dec 12, 2017 at 4:00 PM, Kuntal Ghosh > wrote: >> On Mon, Dec 11, 2017 at 2:26 PM, Thomas Munro >> wrote: >>> On Mon, Dec 11, 2017 at 8:14 PM, Amit Kapila >>> wrote: >>> Thanks for looking into it. I will see if we can write s

Re: [HACKERS] SERIALIZABLE with parallel query

On Wed, Dec 13, 2017 at 2:09 PM, Haribabu Kommi wrote: > Thanks for explaining the problem in generating an isolation test to > test the serialize parallel query. > > Committer can decide whether existing test is fine to part of the test suite > or remove it, other than that everything is fine. so

Re: Add %r substitution for psql prompts to show recovery status

>> Yeah. I think we need some from help backend for this. For example, a >> parameter status message can be used here. If PostgreSQL moves to the >> recovery state or vice versa, PostgreSQL sends the parameter status >> message to frontend. >> > > If we would use parameter status messages, then c

Re: Using ProcSignal to get memory context stats from a running backend

On Mon, Dec 11, 2017 at 10:07 PM, Craig Ringer wrote: > On 12 December 2017 at 12:43, Andres Freund wrote: >> On 2017-12-12 11:57:41 +0800, Craig Ringer wrote: >> But that'd have >> the disadvanatage that it possibly would take a while till the >> MemoryContextStats() is executed. Not sure if tha

Re: pg_ctl on windows can't open postmaster.pid: Permission denied

On Wed, Dec 13, 2017 at 4:24 PM, Andres Freund wrote: > Hi, > > Buildfarm animal thrips just failed with a curious error: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=thrips&dt=2017-12-13%2002%3A27%3A27 > > == shutting down postmaster == > pg_ctl:

Re: plpgsql test layout

On Wed, Dec 13, 2017 at 6:36 AM, Tom Lane wrote: > Peter Eisentraut writes: >> On 12/11/17 19:29, Michael Paquier wrote: >>> If I read vcregress.pl correctly, it seems to me that you need to do >>> more with MSVC (see plcheck). The tests would kick if sql/ and >>> expected/ are found, and the tes

Re: Parallel Index Scan vs BTP_DELETED and BTP_HALF_DEAD

On Wed, Dec 13, 2017 at 4:20 PM, Thomas Munro wrote: > On Wed, Dec 13, 2017 at 3:41 PM, Amit Kapila wrote: >> Good. I hope that the patch I have posted above is able to resolve >> this problem. I am asking as you haven't explicitly mentioned that. > > I can confirm that your patch fixes the pro

pg_ctl on windows can't open postmaster.pid: Permission denied

Hi, Buildfarm animal thrips just failed with a curious error: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=thrips&dt=2017-12-13%2002%3A27%3A27 == shutting down postmaster == pg_ctl: could not open PID file "C:/buildfarm/buildenv/HEAD/pgsql.build/s

Re: Parallel Index Scan vs BTP_DELETED and BTP_HALF_DEAD

On Wed, Dec 13, 2017 at 3:41 PM, Amit Kapila wrote: > Good. I hope that the patch I have posted above is able to resolve > this problem. I am asking as you haven't explicitly mentioned that. I can confirm that your patch fixes the problem for forward scans. That is, I can see it reaching the BT

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Wed, Nov 29, 2017 at 4:25 PM, Michael Paquier wrote: > On Wed, Nov 8, 2017 at 8:50 AM, Haribabu Kommi > wrote: > > Ok. Removed the documentation changes that it cannot be used for normal > > scenarios, and also added a Note section explaining the problem of using > > the dump with pg_restore

Re: Parallel Index Scan vs BTP_DELETED and BTP_HALF_DEAD

On Wed, Dec 13, 2017 at 7:02 AM, Thomas Munro wrote: > Hi, > > Here's a reproducer which enabled me to reach this stuck state: > > pid | wait_event |query > ---+---+---

Re: Incorrect debug info printed in generate_partition_wise_join_paths

(2017/12/13 0:56), Robert Haas wrote: Committed. Thanks! Best regards, Etsuro Fujita

Re: explain analyze output with parallel workers - question about meaning of information for explain.depesz.com

On Wed, Dec 13, 2017 at 3:26 AM, Robert Haas wrote: > On Sat, Dec 9, 2017 at 5:30 AM, Amit Kapila wrote: >> On Sat, Dec 9, 2017 at 1:24 AM, Robert Haas wrote: >>> On Fri, Dec 8, 2017 at 5:11 AM, Amit Kapila wrote: > Okay, I have adjusted the patch accordingly. I have also added a > reg

Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" in child table must be marked NOT NULL

On Wed, Dec 13, 2017 at 10:41 AM, Amit Langote wrote: > On 2017/12/13 9:22, Ali Akbar wrote: >> For me, it's better to prevent that from happening. So, attempts to >> DROP NOT NULL on the child must be rejected. The attached patch does >> that. >> >> Unfortunately, pg_class has no "has_parent" att

Re: Rethinking MemoryContext creation

I wrote: > Andres Freund writes: >> On 2017-12-12 14:50:37 -0500, Robert Haas wrote: >>> Another idea I have is that perhaps we could arrange to reuse contexts >>> instead of destroying them and recreating them. >> I'm a bit doubtful that's going to help, maintaining that list isn't >> going to b

Re: proposal: alternative psql commands quit and exit

On Tue, Dec 12, 2017 at 6:26 PM, Craig Ringer wrote: > >> There is also stackexchange question with 51000 views that asks how to >> start the postgresql client. Should we rename psql to mysql to help >> new users too? >> > > Frankly, that's a legit question and I don't think it's one we should be

Re: PATCH: Exclude unlogged tables from base backups

Andres, * Andres Freund (and...@anarazel.de) wrote: > On 2017-12-12 18:04:44 -0500, David Steele wrote: > > If the forks are written out of order (i.e. main before init), which is > > definitely possible, then I think worst case is some files will be backed up > > that don't need to be. The main

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Wed, Dec 13, 2017 at 12:03 AM, Robert Haas wrote: > On Mon, Dec 11, 2017 at 5:20 AM, Masahiko Sawada > wrote: >>> The question I have is how would we deal with a foreign server that is >>> not available for longer duration due to crash, longer network outage >>> etc. Example is the foreign se

[PATCH] Possible NULL deref in str_time

I noticed that the output of pg_localtime() in str_time() is not checked and can sometimes return NULL. It's pretty unlikely to occur, I guess if the time() function was acting funny. For example if I define this: time_t fake_time(void *blah) { return 0x0110; } and then call fa

Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" in child table must be marked NOT NULL

Hi. On 2017/12/13 9:22, Ali Akbar wrote: > For me, it's better to prevent that from happening. So, attempts to > DROP NOT NULL on the child must be rejected. The attached patch does > that. > > Unfortunately, pg_class has no "has_parent" attribute, so in this > patch, it hits pg_inherits everytim

Re: proposal: alternative psql commands quit and exit

On 12 December 2017 at 23:28, Avinash Kumar wrote: > It takes a few hours to learn PostgreSQL and 1 second to remember, how to > quit from psql. > Surprised to see the depth of discussion on this. > > It takes sometime for a person to explore or know about PostgreSQL and > install it. > Likewise,

Re: Parallel Index Scan vs BTP_DELETED and BTP_HALF_DEAD

Hi, Here's a reproducer which enabled me to reach this stuck state: pid | wait_event |query ---+---+- 64617 | | select pid, wait_event, query from p

Re: proposal: alternative psql commands quit and exit

On 12 December 2017 at 23:02, Geoff Winkless wrote: > I wouldn't exactly say -1 but it's a "meh" from me. > > On 8 December 2017 at 13:57, Daniel Vérité" > wrote: > > "How to exit from PostgreSQL command line utility: psql" > > > > now at 430k views and 1368 upvotes. > > There is also stackexcha

Re: [HACKERS] SERIALIZABLE with parallel query

On Fri, Dec 8, 2017 at 11:33 AM, Thomas Munro wrote: > On Thu, Nov 30, 2017 at 2:44 PM, Thomas Munro > wrote: > > On Thu, Nov 30, 2017 at 2:32 PM, Michael Paquier > > wrote: > >> Could this question be answered? The patch still applies so I am > >> moving it to next CF. > > Rebased, 'cause it b

Re: [HACKERS] Custom compression methods

On Tue, Dec 12, 2017 at 5:07 PM, Tomas Vondra wrote: >> I definitely think there's a place for compression built right into >> the data type. I'm still happy about commit >> 145343534c153d1e6c3cff1fa1855787684d9a38 -- although really, more >> needs to be done there. But that type of improvement

Re: Leftover reference to replacement selection 1 run case

On Tue, Dec 12, 2017 at 6:44 PM, Peter Geoghegan wrote: > Yes, you have that right. Per dumptuples(), even the zero tuple run edge > case will still write a run marker, and will therefore still consume a tape. > We must have at least two initial runs to merge. (though dummy runs for non > final me

Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" in child table must be marked NOT NULL

> For me, it's better to prevent that from happening. So, attempts to > DROP NOT NULL on the child must be rejected. The attached patch does > that. I'm sorry. Accidentaly i "--color"-ed the patch format. Attached the correct patch. Best Regards, Ali Akbar diff --git a/src/backend/catalog/pg_inhe

Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" in child table must be marked NOT NULL

Just stumbled across the same issues while upgrading one of my cluster to Pg 10 with pg_upgrade. Finished the upgrade by fixing the old database(s) and re-running pg_upgrade. 2017-08-04 23:06 GMT+07:00 Michael Paquier : > > On Fri, Aug 4, 2017 at 5:50 PM, Tom Lane wrote: > > Michael Paquier writ

Re: proposal: alternative psql commands quit and exit

On Wed, Dec 13, 2017 at 5:42 AM, Robert Haas wrote: > On Tue, Dec 12, 2017 at 11:58 AM, Everaldo Canuto > wrote: >> Sorry to be so sarcastic on last comment but, I am a little frustrated, it >> is not like this patch is big and need a lots of review, it is already done >> and it takes 15 minutes

Re: money type's overflow handling is woefully incomplete

On Wed, Dec 13, 2017 at 8:30 AM, Andres Freund wrote: > On 2017-12-13 08:27:42 +0900, Michael Paquier wrote: >> >> (OTOH, I bet we could drop reltime/abstime without too many complaints. >> >> Y2038 is coming.) >> > >> > I'm actually about to send a patch doing so, that code is one mess WRT >> > o

Re: Leftover reference to replacement selection 1 run case

Yes, you have that right. Per dumptuples(), even the zero tuple run edge case will still write a run marker, and will therefore still consume a tape. We must have at least two initial runs to merge. (though dummy runs for non final merges are a slightly different matter.) -- Peter Geoghegan (Sent

Re: PATCH: Exclude unlogged tables from base backups

On 12/12/17 6:33 PM, Andres Freund wrote: On 2017-12-12 18:30:47 -0500, David Steele wrote: If we had a way to prevent relfilenode reuse across multiple checkpoints this'd be easier, although ALTER TABLE SET UNLOGGED still'd complicate. Or error the backup if there is wraparound? That seems

Re: PATCH: Exclude unlogged tables from base backups

Hi, On 2017-12-12 18:30:47 -0500, David Steele wrote: > > If we had a way to prevent relfilenode reuse across multiple checkpoints > > this'd be easier, although ALTER TABLE SET UNLOGGED still'd complicate. > > Or error the backup if there is wraparound? That seems entirely unacceptable to me. O

Re: PATCH: Exclude unlogged tables from base backups

On 12/12/17 6:21 PM, Andres Freund wrote: On 2017-12-12 18:18:09 -0500, David Steele wrote: On 12/12/17 6:07 PM, Andres Freund wrote: It's quite different - in the recovery case there's no other write activity going on. But on a normally running cluster the persistence of existing tables can g

Re: money type's overflow handling is woefully incomplete

On 2017-12-13 08:27:42 +0900, Michael Paquier wrote: > On Wed, Dec 13, 2017 at 6:50 AM, Andres Freund wrote: > > On 2017-12-12 16:47:17 -0500, Tom Lane wrote: > >> Really? We've got test cases that intentionally exercise overflow > >> in the money code? I think we could just drop such tests, unt

Re: money type's overflow handling is woefully incomplete

On Wed, Dec 13, 2017 at 6:50 AM, Andres Freund wrote: > On 2017-12-12 16:47:17 -0500, Tom Lane wrote: >> Really? We've got test cases that intentionally exercise overflow >> in the money code? I think we could just drop such tests, until >> such time as someone fixes the issue. > > Some parts at

Re: PATCH: Exclude unlogged tables from base backups

Hi Michael, On 12/12/17 6:08 PM, Michael Paquier wrote: If the forks are written out of order (i.e. main before init), which is definitely possible, then I think worst case is some files will be backed up that don't need to be. The main fork is unlikely to be very large at that point so it do

Re: PATCH: Exclude unlogged tables from base backups

On 2017-12-12 18:18:09 -0500, David Steele wrote: > On 12/12/17 6:07 PM, Andres Freund wrote: > > > > > > I don't see this as any different than what happens during recovery. The > > > unlogged forks are cleaned / re-inited before replay starts which is the > > > same thing we are doing here. > >

Re: Leftover reference to replacement selection 1 run case

On Fri, Dec 8, 2017 at 6:41 PM, Peter Geoghegan wrote: > While reviewing the parallel CREATE INDEX patch, I noticed that commit > 8b304b8b omitted to remove a comment that it made obsolete. > > Attached patch removes the comment. I had to think about this for a while. I could see that the commen

Re: PATCH: Exclude unlogged tables from base backups

On 12/12/17 6:07 PM, Andres Freund wrote: I don't see this as any different than what happens during recovery. The unlogged forks are cleaned / re-inited before replay starts which is the same thing we are doing here. It's quite different - in the recovery case there's no other write activity

Re: PATCH: Exclude unlogged tables from base backups

On Wed, Dec 13, 2017 at 8:04 AM, David Steele wrote: > On 12/12/17 5:52 PM, Andres Freund wrote: >> On 2017-12-12 17:49:54 -0500, David Steele wrote: >>> >>> Including unlogged relations in base backups takes up space and is >>> wasteful >>> since they are truncated during backup recovery. >>> >>>

Re: Learned Indexes in PostgreSQL?

2017-12-12 21:26 GMT+01:00 Robert Haas : > Here are links to the other two threads: > > http://postgr.es/m/CANNMO+J1KeTSx5q5SYuwHf1v-gPRLrOZw1s7qOpqWx=3umm...@mail.gmail.com > http://postgr.es/m/caaerrx8bhiw3rgaqpolqjhyhk7ghordtke5uc9dasv1w5fz...@mail.gmail.com Thanks, Robert. My fault not having

Re: PATCH: Exclude unlogged tables from base backups

Hi, On 2017-12-12 18:04:44 -0500, David Steele wrote: > On 12/12/17 5:52 PM, Andres Freund wrote: > > On 2017-12-12 17:49:54 -0500, David Steele wrote: > > > Including unlogged relations in base backups takes up space and is > > > wasteful > > > since they are truncated during backup recovery. >

Re: PATCH: Exclude unlogged tables from base backups

Hi Andres, On 12/12/17 5:52 PM, Andres Freund wrote: On 2017-12-12 17:49:54 -0500, David Steele wrote: Including unlogged relations in base backups takes up space and is wasteful since they are truncated during backup recovery. The attached patches exclude unlogged relations from base backups

Re: PATCH: Exclude unlogged tables from base backups

Hi, On 2017-12-12 17:49:54 -0500, David Steele wrote: > Including unlogged relations in base backups takes up space and is wasteful > since they are truncated during backup recovery. > > The attached patches exclude unlogged relations from base backups except for > the init fork, which is require

PATCH: Exclude unlogged tables from base backups

Including unlogged relations in base backups takes up space and is wasteful since they are truncated during backup recovery. The attached patches exclude unlogged relations from base backups except for the init fork, which is required to recreate the main fork during recovery. * exclude-unlo

Re: [HACKERS] Custom compression methods

On 12/12/2017 04:33 PM, Robert Haas wrote: > you want to upgrade your existing tables to use lz4 rather than pglz, > you can change the compression option for those columns to COMPRESS > lz4 PRESERVE pglz if you want to do it incrementally or just COMPRESS This is a thread I've only been followin

Re: [HACKERS] Custom compression methods

On 12/12/2017 10:33 PM, Robert Haas wrote: > On Mon, Dec 11, 2017 at 2:53 PM, Tomas Vondra > wrote: >> But let me play the devil's advocate for a while and question the >> usefulness of this approach to compression. Some of the questions were >> mentioned in the thread before, but I don't think

Re: proposal: alternative psql commands quit and exit

On 12/12/2017 03:39 PM, Robert Haas wrote: > On Tue, Dec 12, 2017 at 10:02 AM, Geoff Winkless >> Ctrl-D works almost everywhere. It takes 2 seconds... > > If it really took everyone 2 seconds, this question would not be as > common as it is. ... Some years ago, I took a job at a mostly-Unix sho

Re: explain analyze output with parallel workers - question about meaning of information for explain.depesz.com

On Sat, Dec 9, 2017 at 5:30 AM, Amit Kapila wrote: > On Sat, Dec 9, 2017 at 1:24 AM, Robert Haas wrote: >> On Fri, Dec 8, 2017 at 5:11 AM, Amit Kapila wrote: Okay, I have adjusted the patch accordingly. I have also added a regression test which should produce the same result across di

Re: money type's overflow handling is woefully incomplete

On 2017-12-12 16:47:17 -0500, Tom Lane wrote: > Really? We've got test cases that intentionally exercise overflow > in the money code? I think we could just drop such tests, until > such time as someone fixes the issue. Some parts at least (input & output), I think it's easy enough to fix those

Re: money type's overflow handling is woefully incomplete

Andres Freund writes: >> Robert Haas writes: >>> Long story short, I don't think anyone cares about this enough to >>> spend effort fixing it. I suspect the money data type has very few >>> users. > I'm unfortunately not so sure :(. There seem to be enough of them that we get pushback anytime

Re: plpgsql test layout

Peter Eisentraut writes: > On 12/11/17 19:29, Michael Paquier wrote: >> If I read vcregress.pl correctly, it seems to me that you need to do >> more with MSVC (see plcheck). The tests would kick if sql/ and >> expected/ are found, and the test list is fetched by looking at >> REGRESSION in the tes

Re: CUBE seems a bit confused about ORDER BY

On 12/12/2017 01:52 PM, Alexander Korotkov wrote: > On Tue, Dec 12, 2017 at 3:49 PM, Teodor Sigaev > wrote: > > Yes, the thing is that we change behavior of existing ~> > operator.  In general, this is not good idea because it could > affect exis

Re: [HACKERS] Custom compression methods

On Mon, Dec 11, 2017 at 2:53 PM, Tomas Vondra wrote: > But let me play the devil's advocate for a while and question the > usefulness of this approach to compression. Some of the questions were > mentioned in the thread before, but I don't think they got the attention > they deserve. Sure, thanks

Re: Rethinking MemoryContext creation

Andres Freund writes: > On 2017-12-12 14:50:37 -0500, Robert Haas wrote: >> It strikes me that a way to optimize these cases even more would be to >> postpone creating the context until it's actually needed. That might >> not always be a reasonable plan -- in particular, it occurs to me to >> thi

Re: Error generating coverage report

On 12/12/17 15:39, David Steele wrote: > $ make -C test/build/src/bin/pg_basebackup coverage-html > make: Entering directory `/home/vagrant/test/build/src/bin/pg_basebackup' > /usr/bin/lcov --gcov-tool /usr/bin/gcov -q --no-external -c -i -d . -d > /home/vagrant/src/src/bin/pg_basebackup -o lcov_b

Re: [HACKERS] Custom compression methods

On Mon, Dec 11, 2017 at 1:06 PM, Alexander Korotkov wrote: > OK, but NOTICE that presumably unexpected table rewrite takes place could be > still useful. I'm not going to complain too much about that, but I think that's mostly a failure of expectation rather than a real problem. If the documenta

Re: proposal: alternative psql commands quit and exit

On Tue, Dec 12, 2017 at 3:38 PM, Geoff Winkless wrote: > Well "close" yes, but I like "simpler", and I'm not sure I like the > idea of waiting for someone to flail at the quit command before giving > them a hint. I think a patch that adds a line to every prompt for everyone all the time and has t

Re: proposal: alternative psql commands quit and exit

On Tue, Dec 12, 2017 at 10:02 AM, Geoff Winkless wrote: > There is also stackexchange question with 51000 views that asks how to > start the postgresql client. Should we rename psql to mysql to help > new users too? That's not a serious question, and I don't know what your point is in suggesting

Re: proposal: alternative psql commands quit and exit

On Tue, Dec 12, 2017 at 11:58 AM, Everaldo Canuto wrote: > Sorry to be so sarcastic on last comment but, I am a little frustrated, it > is not like this patch is big and need a lots of review, it is already done > and it takes 15 minutes from me and it was the first time I look at Postgres > sourc

Re: Error generating coverage report

Hi Peter, On 12/12/17 3:20 PM, Peter Eisentraut wrote: make: Entering directory `/home/vagrant/test/build/src/bin/pg_basebackup' /usr/bin/lcov --gcov-tool /usr/bin/gcov -q --no-external -c -i -d . -d /postgres/src/bin/pg_basebackup -o lcov_base.info geninfo: ERROR: no .gcno files found in /post

Re: proposal: alternative psql commands quit and exit

On 12 December 2017 at 18:32, Chapman Flack wrote: > It seems to me that this is very close to the Robert Haas suggestion > already discussed upthread, except that suggestion only prints the > hint message when you might need it, which I'd find less intrusive. Well "close" yes, but I like "simple

Re: Learned Indexes in PostgreSQL?

On Tue, Dec 12, 2017 at 6:38 AM, Stefan Keller wrote: > This is an awesome paper about a new index called "Learned Index". > it's aka dense hash structure derived ("learned") from actual data. > Looks very promising for certain properties [*]. > > Anyone already working on this in Postgres? > How

Re: Backfill bgworker Extension?

On 12/12/17 13:03, Jeremy Finzel wrote: > To be clear, what I mean is batch updating a large set of data in small > pieces so as to avoid things like lock contention and replication lags.  > Sometimes these have a driving table that has the source data to update > in a destination table based on a

Re: Error generating coverage report

On 12/12/17 15:02, David Steele wrote: > I'm working on improving coverage and would like to generate some > reports (other than the text versions) to help me find uncovered code. > However, my source path and build path are not the same and I'm running > into problems. Vpath builds were one of th

Re: [HACKERS] pg_stat_wal_write statistics view

On Tue, Dec 12, 2017 at 4:18 AM, Haribabu Kommi wrote: > I ran the pgbench performance after removing stats collector usage and > moving > the stats into shared memory. I find it that this stats addition doesn't > have any > overhead while collecting the stats. I ran these tests on a small machine

Re: [HACKERS] Custom compression methods

On Tue, Dec 12, 2017 at 6:07 PM, Alexander Korotkov wrote: > Hi! > > Let me add my two cents too. > > On Tue, Dec 12, 2017 at 2:41 PM, Ildus Kurbangaliev > wrote: >> >> On Mon, 11 Dec 2017 20:53:29 +0100 Tomas Vondra >> wrote: >> > Replacing the algorithm used to compress all varlena values (in

Error generating coverage report

I'm working on improving coverage and would like to generate some reports (other than the text versions) to help me find uncovered code. However, my source path and build path are not the same and I'm running into problems. This works fine and produces gcov output: $ make -C test/build/src/bin/pg

Re: Rethinking MemoryContext creation

On 2017-12-12 14:50:37 -0500, Robert Haas wrote: > On Tue, Dec 12, 2017 at 2:30 PM, Tom Lane wrote: > > 379 CurTransactionContext was never used > > 24 CurTransactionContext was used > > 66978 ExprContext was never used > > 17364 ExprContext was used > > 11139 SPI Exec was never use

Re: Rethinking MemoryContext creation

On Tue, Dec 12, 2017 at 2:30 PM, Tom Lane wrote: > 379 CurTransactionContext was never used > 24 CurTransactionContext was used > 66978 ExprContext was never used > 17364 ExprContext was used > 11139 SPI Exec was never used >2421 SPI Exec was used > 38386 ginPlaceToPage tempor

Re: Rethinking MemoryContext creation

I wrote: > I've not done any benchmarking on this yet, just confirmed that it > compiles and passes check-world. So once I'd done some benchmarking, I was a bit disappointed: I could not measure any difference anymore in "pgbench -S", and poking into other scenarios found cases that were actually

Re: Using ProcSignal to get memory context stats from a running backend

On 2017-12-12 14:16:59 -0500, Robert Haas wrote: > On Tue, Dec 12, 2017 at 2:12 PM, Andres Freund wrote: > > I agree that it's more reliable - I hope there's no meaningful safety > > difference. I think you overestimate users a bit however - far from > > most of them are going to be able to extra

Re: Using ProcSignal to get memory context stats from a running backend

On Tue, Dec 12, 2017 at 2:12 PM, Andres Freund wrote: > I agree that it's more reliable - I hope there's no meaningful safety > difference. I think you overestimate users a bit however - far from > most of them are going to be able to extract a very long log entry from > a busy log file. There's

Re: ALTER TABLE ADD COLUMN fast default

On 12/06/2017 11:26 AM, Andrew Dunstan wrote: >> In general, you need to be thinking about this in terms of making sure >> that it's impossible to accidentally not update code that needs to be >> updated. Another example is that I noticed that some places the patch >> has s/CreateTupleDescCopy/C

Re: Using ProcSignal to get memory context stats from a running backend

On 2017-12-12 14:04:55 -0500, Robert Haas wrote: > On Tue, Dec 12, 2017 at 1:50 PM, Andres Freund wrote: > > I do wonder if the right thing here wouldn't be to put the result into a > > dsm segment, and then return that to the UDF on the requesting > > side. Logging to the server log and then have

Re: Using ProcSignal to get memory context stats from a running backend

On Tue, Dec 12, 2017 at 1:50 PM, Andres Freund wrote: > I do wonder if the right thing here wouldn't be to put the result into a > dsm segment, and then return that to the UDF on the requesting > side. Logging to the server log and then have the requestor dig that out > doesn't seem particularly u

Re: [HACKERS] parallel.c oblivion of worker-startup failures

On Mon, Dec 11, 2017 at 10:41 PM, Amit Kapila wrote: > In particular, if the worker crashed (say somebody forcefully killed > the worker), then I think it will lead to a restart of the server. So > not sure, adding anything about that in the comment will make much > sense. I think it's dangerous

Re: Using ProcSignal to get memory context stats from a running backend

On 2017-12-12 14:25:48 +0800, Craig Ringer wrote: > If we were willing to wrap variadic calls in a callback and rely on > vfprintf, we could: I don't think there's problems with relying on variadic calls, we do that in plenty places. > and let the ProcSignal based caller pass an elog wrapper ins

Re: pgbench's expression parsing & negative numbers

On 2017-12-12 07:21:21 +0100, Fabien COELHO wrote: > > Hello Andres, > > > working on overflow correctness in pg I noticed that pgbench isn't quite > > there. I assume it won't matter terribly often, but the way it parses > > integers makes it incorrect for, at least, the negativemost number. >

Re: proposal: alternative psql commands quit and exit

On 12/12/2017 12:00 PM, Geoff Winkless wrote: > I quite like this idea, although I would rather a line printed after > each command is run: something like > > mydbname=# select ; > -- > (1 row) > > \h for help, \q for quit, \expert to turn off this message > osprey=# It seems to me that this is

Re: money type's overflow handling is woefully incomplete

Hi, On 2017-12-12 11:01:04 -0500, Tom Lane wrote: > Robert Haas writes: > > Long story short, I don't think anyone cares about this enough to > > spend effort fixing it. I suspect the money data type has very few > > users. I'm unfortunately not so sure :(. > Somebody did contribute the effor

Backfill bgworker Extension?

One of our challenges we have is that our engineers have written frameworks to backfill data in several different DSLs, and every time they adopt a new language, they maybe need to write another one. To be clear, what I mean is batch updating a large set of data in small pieces so as to avoid thin

Re: Learned Index

On 12/12/2017 12:16 PM, Laurenz Albe wrote: I have read into the paper. This may be interesting or not, but the paper is very vague about its concepts and algorithms, so it's hard to tell. I'd say that the paper does not meet publication standards. For example, they say that their results were

Re: ML-based indexing ("The Case for Learned Index Structures", a paper from Google)

On 12/12/2017 04:33 PM, Oleg Bartunov wrote: On Mon, Dec 11, 2017 at 11:11 PM, Nikolay Samokhvalov wrote: Very interesting read: https://arxiv.org/abs/1712.01208 HN discussion: https://news.ycombinator.com/item?id=15894896 Some of the comments (from Twitter https://twitter.com/schrockn/status

Re: proposal: alternative psql commands quit and exit

On 12 December 2017 at 16:36, Arthur Nascimento wrote: > Nano keeps a cheatsheet of commands on the bottom; and it's regarded > as a fairly good editor for newcomers. Some shells have a right-hand > side status bar. I quite like this idea, although I would rather a line printed after each command

Re: proposal: alternative psql commands quit and exit

On Tue, Dec 12, 2017 at 2:39 PM, Everaldo Canuto wrote: > > As others have pointed out, there are _far_ more frustrating things >> (like the lack of SHOW CREATE [TABLE|etc]... support in the backend) >> for anyone coming from mysql that I would suggest should be addressed >> if you were serious a

Re: proposal: alternative psql commands quit and exit

On 12 December 2017 at 16:39, Everaldo Canuto wrote: > On Tue, Dec 12, 2017 at 1:02 PM, Geoff Winkless wrote: >> There is also stackexchange question with 51000 views that asks how to >> start the postgresql client. Should we rename psql to mysql to help >> new users too? > No, we shouldn't but

Re: proposal: alternative psql commands quit and exit

On Tue, Dec 12, 2017 at 1:02 PM, Geoff Winkless wrote: > > There is also stackexchange question with 51000 views that asks how to > start the postgresql client. Should we rename psql to mysql to help > new users too? > No, we shouldn't but it will help a lot is postgres client have names like "po

  1   2   >