Re: SIGPIPE in TAP tests

On Mon, Dec 11, 2017 at 4:32 PM, Noah Misch wrote: > On Mon, Dec 11, 2017 at 04:19:52PM +0900, Michael Paquier wrote: >> On Sun, Dec 10, 2017 at 6:02 AM, Noah Misch wrote: > >> If SIGPIPE is ignored then test output just stops after generating the >> FATAL message. Oops. > > You mean "If SIGPIPE

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

On Thu, Dec 7, 2017 at 5:11 AM, David Rowley wrote: > > While rebasing this today I also noticed that we won't properly detect > unique joins in add_paths_to_joinrel() as we're still testing for > uniqueness against the partitioned parent rather than the only child. > This is likely not a huge pro

Re: Jsonb transform for pl/python

On Sat, 9 Dec 2017 16:57:05 -0500 Peter Eisentraut wrote: > On 12/6/17 06:40, Anthony Bykov wrote: > > Hello, > > fixed the issues: > > 1. Rising errors when invalid object being transformed. > > 2. We don't rise the exception when transforming range(3) only in > > python 2. In third one it is an

Re: Incorrect debug info printed in generate_partition_wise_join_paths

Yes, that's the correct fix. We should be printing debug information about the child and not the parent. Sorry for that bug and thanks for fixing it. On Fri, Dec 8, 2017 at 3:22 PM, Etsuro Fujita wrote: > generate_partition_wise_join_paths prints debug info, if > OPTIMIZER_DEBUG, using debug_prin

Re: Out of date comment in cached_plan_cost

On Mon, Dec 11, 2017 at 3:02 AM, David Rowley wrote: > On 9 December 2017 at 06:05, Robert Haas wrote: >> On Thu, Dec 7, 2017 at 3:14 AM, David Rowley >> wrote: >>> The attached is my attempt at putting this right. >> >> I don't feel entirely right about the way this seems to treat >> inheritanc

Re: Added PostgreSQL internals learning materials in Developer FAQ

On 11 December 2017 at 14:50, Amit Kapila wrote: > On Mon, Dec 11, 2017 at 8:43 AM, Tsunakawa, Takayuki > wrote: > > Hello, > > > > FYI > > I collected Web resources to learn PostgreSQL internals in the Developer > FAQ page. I did this because I need to provide self-education materials > for ne

Re: [HACKERS] WAL logging problem in 9.4.3?

At Tue, 28 Nov 2017 10:36:39 +0900, Michael Paquier wrote in > On Thu, Sep 14, 2017 at 3:34 PM, Kyotaro HORIGUCHI > wrote: > > At Wed, 13 Sep 2017 17:42:39 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI > > wrote in > > <20170913.174239.25978735.horiguchi.kyot...@lab.ntt.co.jp> > >> filterdi

Re: Parallel Index Scan vs BTP_DELETED and BTP_HALF_DEAD

On Mon, Dec 11, 2017 at 8:14 PM, Amit Kapila wrote: > On Mon, Dec 11, 2017 at 8:21 AM, Thomas Munro > wrote: >> ... and then it called _bt_parallel_seize() itself, in violation of >> the rule (by my reading of the code) that you must call >> _bt_parallel_release() (via _bt_readpage()) or _bt_para

Learned Index

I came across this paper making a case for indices that use machine learning to optimise search. https://arxiv.org/pdf/1712.01208.pdf The gist seems to be to use a linear regression model or feed a tensor flow model when a more complicated distribution is needed for the data and allow SIMD instru

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

On 11 December 2017 at 21:18, Ashutosh Bapat wrote: > On Thu, Dec 7, 2017 at 5:11 AM, David Rowley > wrote: >> While rebasing this today I also noticed that we won't properly detect >> unique joins in add_paths_to_joinrel() as we're still testing for >> uniqueness against the partitioned parent r

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

On Mon, Dec 11, 2017 at 2:42 PM, David Rowley wrote: > On 11 December 2017 at 21:18, Ashutosh Bapat > wrote: >> On Thu, Dec 7, 2017 at 5:11 AM, David Rowley >> wrote: >>> While rebasing this today I also noticed that we won't properly detect >>> unique joins in add_paths_to_joinrel() as we're st

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

On 11 December 2017 at 22:23, Ashutosh Bapat wrote: > I think this didn't work with inheritance before partition-wise join > as well for the same reason. Yeah, I was just demonstrating a reason that the plans are not identical from querying a partitioned table when partition pruning eliminates al

Re: Out of date comment in cached_plan_cost

On 11 December 2017 at 21:39, Ashutosh Bapat wrote: > I don't see much difference in the old and new wording. The word > "generally" confuses more than clarifying the cases when the planning > cost curves do not change with the number of relations i.e. > partitions. I added that to remove the fal

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

On Mon, Dec 11, 2017 at 3:16 PM, David Rowley wrote: > > Sometime in the future, I'd like to see some sort of UniqueKeys List > in RelOptInfo which is initially populated by using looking at the > unique indexes during build_simple_rel(). The idea is that these > UniqueKeys would get propagated in

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Tue, Nov 28, 2017 at 12:31 PM, Ashutosh Bapat wrote: > On Tue, Nov 28, 2017 at 3:04 AM, Masahiko Sawada > wrote: >> On Fri, Nov 24, 2017 at 10:28 PM, Antonin Houska wrote: >>> Masahiko Sawada wrote: >>> On Mon, Oct 30, 2017 at 5:48 PM, Ashutosh Bapat wrote: > On Thu, Oct 26,

After dropping the rule - Not able to insert / server crash (one time ONLY)

Hi, While testing something , I found that even after rule has dropped  not able to insert data  and in an another scenario , there is a Crash/ Please refer this scenario's - 1) Rows not inserted after dropping the RULE postgres=# create table e(n int); CREATE TABLE postgres=# create rule e1

Re: After dropping the rule - Not able to insert / server crash (one time ONLY)

On Mon, Dec 11, 2017 at 3:54 PM, tushar wrote: > Hi, > > While testing something , I found that even after rule has dropped not > able to insert data and in an another scenario , there is a Crash/ > > Please refer this scenario's - > > 1) Rows not inserted after dropping the RULE > > postgres=#

Re: [HACKERS] asynchronous execution

Hello, At Fri, 20 Oct 2017 17:37:07 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20171020.173707.12913619.horiguchi.kyot...@lab.ntt.co.jp> > The attached PoC patch theoretically has no impact on the normal > code paths and just brings gain in async cases. The parallel append just c

Re: [HACKERS] More stats about skipped vacuums

At Mon, 27 Nov 2017 13:51:22 -0500, Robert Haas wrote in > On Mon, Nov 27, 2017 at 1:49 AM, Kyotaro HORIGUCHI > wrote: > > Hmmm. Okay, we must make stats collector more effeicient if we > > want to have additional counters with smaller significance in the > > table stats. Currently sizeof(PgSta

Re: Mention ordered datums in PartitionBoundInfoData comment

On Fri, Dec 8, 2017 at 12:25 AM, Robert Haas wrote: > On Tue, Dec 5, 2017 at 1:03 AM, Ashutosh Bapat > wrote: >> Sorry. Thanks for pointing it out. fixed in the attached patch. > > + * The datums in datums array are arranged in the increasing order defined by > > Suggest: in increasing order as d

Re: [HACKERS] Custom compression methods

On Fri, 8 Dec 2017 15:12:42 -0500 Robert Haas wrote: > > Maybe a better idea is ALTER COLUMN SET COMPRESSION x1, x2, x3 ... > meaning that x1 is the default for new tuples but x2, x3, etc. are > still allowed if present. If you issue a command that only adds > things to the list, no table rewri

Re: proposal: alternative psql commands quit and exit

On Sat, Dec 9, 2017 at 12:59 PM, David Fetter wrote: > > On Fri, Dec 08, 2017 at 02:12:06PM -0500, Robert Haas wrote: > > On Fri, Dec 8, 2017 at 10:28 AM, Szymon Lipiński wrote: > > > Well, if I have a new program I usually read some documentation. It really > > > helps people to exit vim as well

Re: proposal: alternative psql commands quit and exit

Hello. On Mon, Dec 11, 2017 at 11:14 AM, Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: > > And what about create some way to create aliases for meta-commands in > psql? Something like: > > \alias quit \q > \alias exit \q > > We also can create a special config variable to enable/disab

Re: Rethinking MemoryContext creation

I wrote: > While fooling around with a different problem, I got annoyed at how slow > MemoryContext creation and deletion is. Looking at this some more, there's another micro-optimization we could make, which is to try to get rid of the strlen+strcpy operations needed for the context name. (And y

Re: proposal: alternative psql commands quit and exit

On Mon, Dec 11, 2017 at 11:14:29AM -0200, Fabrízio de Royes Mello wrote: > And what about create some way to create aliases for meta-commands in psql? At first blush, this sounds interesting, but on further reflection, it seems more like a MASSIVE foot gun on the useability/getting help side, and

Re: Rethinking MemoryContext creation

On 12/11/2017 05:27 PM, Tom Lane wrote: > I wrote: >> While fooling around with a different problem, I got annoyed at how slow >> MemoryContext creation and deletion is. > > Looking at this some more, there's another micro-optimization we could > make, which is to try to get rid of the strlen+st

Re: Rethinking MemoryContext creation

Tomas Vondra writes: > On 12/11/2017 05:27 PM, Tom Lane wrote: >> However, unless we want to run around and touch all the ~ 150 calls >> with constant arguments, we'd have to set things up so that the default >> behavior for AllocSetContextCreate is to not copy. This risks breaking >> callers in

Re: Rethinking MemoryContext creation

On Mon, Dec 11, 2017 at 11:59 AM, Tom Lane wrote: > Tomas Vondra writes: >> On 12/11/2017 05:27 PM, Tom Lane wrote: >>> However, unless we want to run around and touch all the ~ 150 calls >>> with constant arguments, we'd have to set things up so that the default >>> behavior for AllocSetContextC

Re: Rethinking MemoryContext creation

On 11 December 2017 at 16:27, Tom Lane wrote: > For a *very* large majority of the callers of AllocSetContextCreate, > the context name is a simple C string constant, so we could just store > the pointer to it and save the space and cycles required to copy it. Why have the string at all in that

Re: [HACKERS] Custom compression methods

On Mon, Dec 11, 2017 at 7:55 AM, Ildus Kurbangaliev wrote: > On Fri, 8 Dec 2017 15:12:42 -0500 > Robert Haas wrote: >> Maybe a better idea is ALTER COLUMN SET COMPRESSION x1, x2, x3 ... >> meaning that x1 is the default for new tuples but x2, x3, etc. are >> still allowed if present. If you issu

Re: Rethinking MemoryContext creation

Robert Haas writes: > On Mon, Dec 11, 2017 at 11:59 AM, Tom Lane wrote: >> Tomas Vondra writes: >>> On 12/11/2017 05:27 PM, Tom Lane wrote: However, unless we want to run around and touch all the ~ 150 calls with constant arguments, we'd have to set things up so that the default b

Re: Rethinking MemoryContext creation

On 12/11/2017 06:22 PM, Robert Haas wrote: > On Mon, Dec 11, 2017 at 11:59 AM, Tom Lane wrote: >> Tomas Vondra writes: >>> On 12/11/2017 05:27 PM, Tom Lane wrote: However, unless we want to run around and touch all the ~ 150 calls with constant arguments, we'd have to set things up so t

Re: Rethinking MemoryContext creation

Simon Riggs writes: > On 11 December 2017 at 16:27, Tom Lane wrote: >> For a *very* large majority of the callers of AllocSetContextCreate, >> the context name is a simple C string constant, so we could just store >> the pointer to it and save the space and cycles required to copy it. > Why have

Re: Rethinking MemoryContext creation

Robert Haas writes: > On Mon, Dec 11, 2017 at 11:59 AM, Tom Lane wrote: >> Tomas Vondra writes: >>> On 12/11/2017 05:27 PM, Tom Lane wrote: However, unless we want to run around and touch all the ~ 150 calls with constant arguments, we'd have to set things up so that the default

Re: Inconsistency in plpgsql's error context reports

On Sun, Dec 10, 2017 at 11:55 AM, Tom Lane wrote: > There seem to be two ways we could look at this. One is that the > new test case just needs to be rejiggered to avoid unstable output > ("\set VERBOSITY terse" would be the easiest way). But there is > also room to argue that it's bad that plpg

Re: [HACKERS] Custom compression methods

On Mon, Dec 11, 2017 at 8:25 PM, Robert Haas wrote: > On Mon, Dec 11, 2017 at 7:55 AM, Ildus Kurbangaliev > wrote: > > On Fri, 8 Dec 2017 15:12:42 -0500 > > Robert Haas wrote: > >> Maybe a better idea is ALTER COLUMN SET COMPRESSION x1, x2, x3 ... > >> meaning that x1 is the default for new tup

Re: Rethinking MemoryContext creation

On Mon, Dec 11, 2017 at 12:36 PM, Tom Lane wrote: > [ thinks... ] If we wanted to go that way, one thing we could do to > help extension authors (and ourselves) is to define the proposed > AllocSetContextCreate macro to include > > StaticAssertExpr(__builtin_constant_p(name)) > > on compi

Re: Inconsistency in plpgsql's error context reports

Robert Haas writes: > On Sun, Dec 10, 2017 at 11:55 AM, Tom Lane wrote: >> There seem to be two ways we could look at this. One is that the >> new test case just needs to be rejiggered to avoid unstable output >> ("\set VERBOSITY terse" would be the easiest way). But there is >> also room to ar

Re: [HACKERS] Custom compression methods

On Mon, Dec 11, 2017 at 12:41 PM, Alexander Korotkov wrote: > Thus, in your example if user would like to further change awesome > compression for evenbetter compression, she should write. > > SET COMPRESSION evenbetter PRESERVE pglz, awesome; -- full list of previous > compression methods Right.

Re: Mention ordered datums in PartitionBoundInfoData comment

On Mon, Dec 11, 2017 at 7:28 AM, Ashutosh Bapat wrote: > PFA updated patch. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Testing Extension Upgrade Paths

Hello - I understand how to setup a regression suite for a postgres extension, but what I'm not clear on from the docs is if there is a pattern that exists for testing not only the latest version of an extension, but also an upgraded previous version. For example, I am developing version 1.1, and

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

On Sun, Dec 10, 2017 at 11:07 PM, Amit Kapila wrote: > Okay, see the attached and let me know if that suffices the need? + * Check for unexpected worker death. This will ensure that if + * the postmaster failed to start the worker, then we don't wait + * for i

Re: Rethinking MemoryContext creation

On 12/10/2017 04:42 PM, Tom Lane wrote: > Peter Geoghegan writes: >> On Sat, Dec 9, 2017 at 5:53 PM, Tom Lane wrote: >>> Overall I'm seeing about a 5% improvement in a "pgbench -S" scenario, >>> although that number is a bit shaky since the run-to-run variation >>> is a few percent anyway. > >>

Re: [HACKERS] Custom compression methods

On Mon, Dec 11, 2017 at 8:46 PM, Robert Haas wrote: > On Mon, Dec 11, 2017 at 12:41 PM, Alexander Korotkov > wrote: > > Thus, in your example if user would like to further change awesome > > compression for evenbetter compression, she should write. > > > > SET COMPRESSION evenbetter PRESERVE pgl

Re: Rethinking MemoryContext creation

Tomas Vondra writes: > On 12/10/2017 04:42 PM, Tom Lane wrote: >> Peter Geoghegan writes: >>> On Sat, Dec 9, 2017 at 5:53 PM, Tom Lane wrote: Overall I'm seeing about a 5% improvement in a "pgbench -S" scenario, although that number is a bit shaky since the run-to-run variation is

Re: Rethinking MemoryContext creation

On 2017-12-11 13:09:42 -0500, Tom Lane wrote: > Tomas Vondra writes: > > On 12/10/2017 04:42 PM, Tom Lane wrote: > >> Peter Geoghegan writes: > >>> On Sat, Dec 9, 2017 at 5:53 PM, Tom Lane wrote: > Overall I'm seeing about a 5% improvement in a "pgbench -S" scenario, > although that nu

Re: Rethinking MemoryContext creation

Robert Haas writes: > On Mon, Dec 11, 2017 at 12:36 PM, Tom Lane wrote: >> [ thinks... ] If we wanted to go that way, one thing we could do to >> help extension authors (and ourselves) is to define the proposed >> AllocSetContextCreate macro to include >> >> StaticAssertExpr(__builtin_cons

Re: [HACKERS] Custom compression methods

Hi, I see there's an ongoing discussion about the syntax and ALTER TABLE behavior when changing a compression method for a column. So the patch seems to be on the way to be ready in the January CF, I guess. But let me play the devil's advocate for a while and question the usefulness of this appro

Re: plpgsql test layout

On 12/7/17 15:21, Pavel Stehule wrote: > 2017-12-07 20:08 GMT+01:00 Peter Eisentraut > >: > > On 11/14/17 11:51, Pavel Stehule wrote: > >     One option would be to create a new test setup under > src/pl/pgsql(/src) > >     and move some of th

Re: [HACKERS] Transaction control in procedures

On 12/7/17 18:47, Andrew Dunstan wrote: > Referring to anonymous blocks might be a bit mystifying for some > readers, unless we note that they are invoked via DO. Added parenthetical comments. > I think this sentence should probably be worded a bit differently: > > (And of course, BEGIN and

Re: plpgsql test layout

Peter Eisentraut writes: > On 12/7/17 15:21, Pavel Stehule wrote: >> 2017-12-07 20:08 GMT+01:00 Peter Eisentraut >> > >: >>> Here is a first attempt. >> looks ok > Any other thoughts on this? If not, I'd like to commit it, give the > buildfarm a run at i

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

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/940037656494317568): "Jeff Dean and co at GOOG just released a paper showing how machine-learned indexes can

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

On Sun, Dec 10, 2017 at 11:51 PM, Masahiko Sawada wrote: > Attached updated version patch. Please review it. I went over this today; please find attached an updated version which I propose to commit. Changes: - Various formatting fixes, including running pgindent. - Various comment updates. -

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

Hi, On 2017-12-11 15:15:50 -0500, Robert Haas wrote: > +* Relation extension locks. Only one process can extend a relation at > +a time; we use a specialized lock manager for this purpose, which is > +much simpler than the regular lock manager. It is similar to the > +lightweight lock mechanism,

Re: Fwd: [BUGS] pg_trgm word_similarity inconsistencies or bug

On Fri, Dec 8, 2017 at 2:50 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Thu, Dec 7, 2017 at 8:59 PM, Robert Haas wrote: > >> On Tue, Nov 7, 2017 at 7:51 AM, Jan Przemysław Wójcik >> wrote: >> > I'm afraid that creating a function that implements quite different >> > algorithm

Re: Inconsistency in plpgsql's error context reports

I wrote: > Robert Haas writes: >> On Sun, Dec 10, 2017 at 11:55 AM, Tom Lane wrote: >>> There seem to be two ways we could look at this. One is that the >>> new test case just needs to be rejiggered to avoid unstable output >>> ("\set VERBOSITY terse" would be the easiest way). But there is >>>

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

On Mon, Dec 11, 2017 at 3:25 PM, Andres Freund wrote: > For me "very short periods of time" and journaled metadatachanging > filesystem operations don't quite mesh. Language lawyering aside, this > seems quite likely to bite us down the road. > > It's imo perfectly fine to say that there's only a

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

On Tue, Dec 12, 2017 at 5:15 AM, Robert Haas wrote: > On Sun, Dec 10, 2017 at 11:51 PM, Masahiko Sawada > wrote: >> Attached updated version patch. Please review it. > > I went over this today; please find attached an updated version which > I propose to commit. > > Changes: > > - Various format

Re: proposal: alternative psql commands quit and exit

On 12/9/17 19:28, Tom Lane wrote: > Peter Eisentraut writes: >> On 12/8/17 10:19, Tom Lane wrote: >>> Meh. I never thought that the "help" business was particularly well >>> thought out, and this proposal isn't better. > >> The perhaps the fix is to revert the "help" thing? > > No, my problem w

Re: Jsonb transform for pl/python

On 12/11/17 03:22, Anthony Bykov wrote: >> Why not make this part of the plpythonu extension? It doesn't have to >> be a separate contrib module. >> > Hello, > I thought about that, but the problem is that there will be no > possibilities to create custom transform if we create this extension by >

Re: proposal: alternative psql commands quit and exit

Peter Eisentraut writes: > On 12/9/17 19:28, Tom Lane wrote: >> No, my problem with it is that there are lots of contexts where typing >> "help" won't produce anything. Robert's proposal downthread would >> go a long way towards fixing that. > No opinion on that, but if the problem is that peopl

Re: [HACKERS] static assertions in C++

On 11/29/17 10:03, Tom Lane wrote: > Right now, we have the property that every build enforces static > assertions, albeit with variable quality of the error messages. > I strongly disagree that it's okay to throw that property away. > I do think that we could put an #error here instead, and wait t

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

On 2017-12-11 15:55:42 -0500, Robert Haas wrote: > On Mon, Dec 11, 2017 at 3:25 PM, Andres Freund wrote: > > For me "very short periods of time" and journaled metadatachanging > > filesystem operations don't quite mesh. Language lawyering aside, this > > seems quite likely to bite us down the roa

Re: proposal: alternative psql commands quit and exit

On 12/11/2017 04:16 PM, Tom Lane wrote: > Peter Eisentraut writes: >> No opinion on that, but if the problem is that people don't know how to >> quit psql, then we should just put that information back into the >> welcome message and be done with it. > > I don't think people read the welcome mess

Re: Jsonb transform for pl/python

Peter Eisentraut writes: > On 12/11/17 03:22, Anthony Bykov wrote: >>> Why not make this part of the plpythonu extension? It doesn't have to >>> be a separate contrib module. >> I thought about that, but the problem is that there will be no >> possibilities to create custom transform if we creat

Re: REPLICA IDENTITY FULL

On 12/4/17 22:15, Noah Misch wrote: > While reviewing this patch, I noticed a couple of nearby defects: > > - RelationFindReplTupleSeq() says "Note that this stops on the first matching > tuple.", but that's not the case. It visits every row in the table, and it > uses the last match. The cl

Re: [HACKERS] static assertions in C++

Peter Eisentraut writes: > On 11/29/17 10:03, Tom Lane wrote: >> Right now, we have the property that every build enforces static >> assertions, albeit with variable quality of the error messages. >> I strongly disagree that it's okay to throw that property away. >> I do think that we could put an

Re: [HACKERS] static assertions in C++

On 12/11/17 16:45, Tom Lane wrote: >> I guess the question is whether we would rather be able to have users >> continue to use older C++ compilers, or be super picky about static >> assertions. > > Uh, what is this "continue to use" bit? We've never supported > building the backend with C++ compi

Re: [HACKERS] static assertions in C++

Peter Eisentraut writes: > On 12/11/17 16:45, Tom Lane wrote: >> (BTW, why is it that we can't fall back on the negative-width-bitfield >> trick for old g++?) > The complaint is > error: types may not be defined in 'sizeof' expressions Hmm, well, surely there's more than one way to do that; the

money type's overflow handling is woefully incomplete

Hi, The money type has overflow handling in its input function: Datum cash_in(PG_FUNCTION_ARGS) ... Cashnewvalue = (value * 10) - (*s - '0'); if (newvalue / 10 != value) ereport(ERROR,

Re: Testing Extension Upgrade Paths

On Tue, Dec 12, 2017 at 2:55 AM, Jeremy Finzel wrote: > I understand how to setup a regression suite for a postgres extension, but > what I'm not clear on from the docs is if there is a pattern that exists for > testing not only the latest version of an extension, but also an upgraded > previous v

RE: Added PostgreSQL internals learning materials in Developer FAQ

From: Craig Ringer [mailto:cr...@2ndquadrant.com] > While we're talking wiki changes, some folks may be interested in the recent > stuff I added to the profiling with perf page > https://wiki.postgresql.org/wiki/Profiling_with_perf on using > postgres's predefined tracepoints, injecting userspace

Re: plpgsql test layout

On Tue, Dec 12, 2017 at 5:11 AM, Tom Lane wrote: > Peter Eisentraut writes: >> On 12/7/17 15:21, Pavel Stehule wrote: >>> 2017-12-07 20:08 GMT+01:00 Peter Eisentraut >>> >> >: Here is a first attempt. > >>> looks ok > >> Any other thoughts on this? I

Re: User defined data types in Logical Replication

On Sun, Dec 10, 2017 at 12:33 AM, Dang Minh Huong wrote: > On 2017/12/08 13:18, Huong Dangminh wrote: > >> Hi Sawada-san, >> >>> On Thu, Dec 7, 2017 at 11:07 AM, Masahiko Sawada >>> wrote: On Thu, Dec 7, 2017 at 12:23 AM, Dang Minh Huong >>> >>> wrote: > > Hi Sawada-san, >

Boolean partitions syntax

Hi. Horiguchi-san pointed out [1] on a nearby thread that the partitioning syntax (the FOR VALUES clause) doesn't accept true and false as valid partition bound datums, which seems to me like an oversight. Attached a patch to fix that. create table bools (a bool) partition by list (a); Before p

Re: Testing Extension Upgrade Paths

On 12 December 2017 at 07:25, Michael Paquier wrote: > On Tue, Dec 12, 2017 at 2:55 AM, Jeremy Finzel wrote: > > I understand how to setup a regression suite for a postgres extension, > but > > what I'm not clear on from the docs is if there is a pattern that exists > for > > testing not only th

Re: Incorrect debug info printed in generate_partition_wise_join_paths

(2017/12/11 17:24), Ashutosh Bapat wrote: Yes, that's the correct fix. We should be printing debug information about the child and not the parent. Thanks for reviewing! Best regards, Etsuro Fujita

Re: proposal: alternative psql commands quit and exit

On 12 December 2017 at 05:38, Chapman Flack wrote: > On 12/11/2017 04:16 PM, Tom Lane wrote: > > Peter Eisentraut writes: > >> No opinion on that, but if the problem is that people don't know how to > >> quit psql, then we should just put that information back into the > >> welcome message and b

Re: proposal: alternative psql commands quit and exit

On 12 December 2017 at 05:16, Tom Lane wrote: > Peter Eisentraut writes: > > On 12/9/17 19:28, Tom Lane wrote: > >> No, my problem with it is that there are lots of contexts where typing > >> "help" won't produce anything. Robert's proposal downthread would > >> go a long way towards fixing tha

That mode-700 check on DATADIR again

I have, more or less, this classic question: https://www.postgresql.org/message-id/4667C403.1070807%40t3go.de But I have it for a newer reason, where again it seems as if a better answer than "don't do that" might be worth having. 1. Suppose you are running PG in a VM (named pgvm just for exposi

Re: That mode-700 check on DATADIR again

Greetings Chapman, * Chapman Flack (c...@anastigmatix.net) wrote: > I have, more or less, this classic question: > > https://www.postgresql.org/message-id/4667C403.1070807%40t3go.de [...] > So, it seems there's at least one use case where some kind of > no_really_the_datadir_permissions_are_fin

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

On Mon, Dec 11, 2017 at 11:27 PM, Robert Haas wrote: > On Sun, Dec 10, 2017 at 11:07 PM, Amit Kapila wrote: >> Okay, see the attached and let me know if that suffices the need? > > + * Check for unexpected worker death. This will ensure that if > + * the postmaster failed

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

On Tue, Dec 12, 2017 at 9:00 AM, Amit Kapila wrote: > On Mon, Dec 11, 2017 at 11:27 PM, Robert Haas wrote: >> On Sun, Dec 10, 2017 at 11:07 PM, Amit Kapila >> wrote: >>> Okay, see the attached and let me know if that suffices the need? >> >> + * Check for unexpected worker death. T

Re: BUG #14941: Vacuum crashes

On Mon, Dec 11, 2017 at 2:13 PM, Michael Paquier wrote: > On Wed, Dec 6, 2017 at 1:52 AM, Bossart, Nathan wrote: >> 0001_fix_unparenthesized_vacuum_grammar_v1.patch >> >> One VacuumStmt grammar rule allows users to specify the VACOPT_ANALYZE >> option by including an AnalyzeStmt at the end of the

Using ProcSignal to get memory context stats from a running backend

Hi all TL;DR: Lets add a ProcSignalReason that makes a backend call MemoryContextStats when it sees it and a C func that users can use to set it on a proc. Sane? I fairly frequently want to get a memory context dump from a running backend. It's trivial to do on a debug-enabled build (or one with

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

From: Craig Ringer [mailto:cr...@2ndquadrant.com] > TL;DR: Lets add a ProcSignalReason that makes a backend call > MemoryContextStats when it sees it and a C func that users can use to set > it on a proc. Sane? > So how about borrowing a ProcSignalReason entry for "dump a memory context > summary

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

Hi, On 2017-12-12 11:57:41 +0800, Craig Ringer wrote: > TL;DR: Lets add a ProcSignalReason that makes a backend > call MemoryContextStats when it sees it and a C func that users can use to > set it on a proc. Sane? It's not unproblematic. procsignal_sigusr1_handler() runs in a signal handler, so

Re: [HACKERS] postgres_fdw super user checks

On Thu, Oct 5, 2017 at 10:49 AM, Simon Riggs wrote: > On 4 October 2017 at 18:13, Jeff Janes wrote: > > > OK. And if you want the first one, you can wrap it in a view currently, > but > > if it were changed I don't know what you would do if you want the 2nd one > > (other than having every u

Re: [HACKERS] postgres_fdw super user checks

On Tue, Dec 5, 2017 at 8:35 AM, Robert Haas wrote: > On Mon, Dec 4, 2017 at 5:57 PM, Ashutosh Bapat > wrote: > > I think the real behaviour can be described as something like this: > > > > "Only superusers may connect to foreign servers without password > > authentication, so always specify the

Re: [HACKERS] postgres_fdw super user checks

On Thu, Oct 5, 2017 at 10:16 AM, Nico Williams wrote: > On Thu, Sep 14, 2017 at 04:08:08PM -0400, Robert Haas wrote: > > On Thu, Sep 14, 2017 at 2:33 PM, Jeff Janes > wrote: > > > I think that foreign tables ought to behave as views do, where they > run as > > > the owner rather than the invoker

Re: pg_dumpall -r -c try to drop user postgres

On Tue, Dec 5, 2017 at 9:03 AM, Pavel Stehule wrote: > On Sun, Dec 3, 2017 at 3:21 PM, Pavel Stehule >> wrote: >> > I am not sure if user postgres should be removed, so it is probably bug >> > >> > pg_dumpall -r -c | grep postgres >> > >> > DROP ROLE postgres; >> > CREATE ROLE postgres; >> >> >

pgbench's expression parsing & negative numbers

Hi, 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. It directly parses the integer input using: {digit}+{

Re: [HACKERS] A design for amcheck heapam verification

On Fri, Dec 8, 2017 at 4:37 AM, Peter Geoghegan wrote: > Here, we repeat the same test 3 times, varying only the seed value > used for each run. Thanks for the updated version! Looking at 0001, I have run a coverage test and can see all code paths covered, which is nice. It is also easier to chec

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

On 12 December 2017 at 12:25, Tsunakawa, Takayuki < tsunakawa.ta...@jp.fujitsu.com> wrote: > From: Craig Ringer [mailto:cr...@2ndquadrant.com] > > TL;DR: Lets add a ProcSignalReason that makes a backend call > > MemoryContextStats when it sees it and a C func that users can use to set > > it on a

Re: proposal: alternative psql commands quit and exit

Craig Ringer writes: > I doubt I've ever written just "exit" or "quit" without indentation. I > think if it requires them to be a bareword with no indentation, strictly > ^(exit|quit)\n when isatty, then that's probably a safe and helpful choice. FWIW, I think that the special behavior (whatever

Re: Boolean partitions syntax

On Tue, Dec 12, 2017 at 7:19 AM, Amit Langote wrote: > Hi. > > Horiguchi-san pointed out [1] on a nearby thread that the partitioning > syntax (the FOR VALUES clause) doesn't accept true and false as valid > partition bound datums, which seems to me like an oversight. Attached a > patch to fix t

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

Andres Freund writes: > On 2017-12-12 11:57:41 +0800, Craig Ringer wrote: >> TL;DR: Lets add a ProcSignalReason that makes a backend >> call MemoryContextStats when it sees it and a C func that users can use to >> set it on a proc. Sane? > It's not unproblematic. procsignal_sigusr1_handler() runs

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

On 12 December 2017 at 12:43, Andres Freund wrote: > Hi, > > On 2017-12-12 11:57:41 +0800, Craig Ringer wrote: > > TL;DR: Lets add a ProcSignalReason that makes a backend > > call MemoryContextStats when it sees it and a C func that users can use > to > > set it on a proc. Sane? > > It's not unpr

Re: pgbench's expression parsing & negative numbers

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. It directly parses the integer input using: {digit}+

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

On 12 December 2017 at 14:06, Tom Lane wrote: > > Another question is whether printing to stderr, bypassing proper > > logging!, is good enough for something like this. > > Yeah, this is an issue. MemoryContextStats is designed to print > to stderr in the (possibly vain) hope that it will work

  1   2   3   >