[HACKERS] new gcc 7.0.1 warnings

Hi I am checking new Fedora 26, where new gcc compiler is used. float.c: In function ‘float4out’: float.c:382:41: warning: ‘%.*g’ directive output may be truncated writing between 1 and 310 bytes into a region of size 65 [-Wformat-truncation=] snprintf(ascii, MAXFLOATWIDTH + 1, "%.*g",

Re: [HACKERS] Parallel Index-only scan

On Fri, Feb 17, 2017 at 10:35 AM, Rafia Sabih wrote: > > > On Thu, Feb 16, 2017 at 9:25 PM, Amit Kapila > wrote: >> >> >> 4. >> ExecReScanIndexOnlyScan(IndexOnlyScanState *node) >> { >> .. >> + /* >> + * if we are here to just update the

Re: [HACKERS] "SQL sentence"?

On 2/17/17 10:46 PM, Alvaro Herrera wrote: Jim Nasby wrote: On 2/17/17 10:19 PM, Alvaro Herrera wrote: (FWIW, I'm wondering because I was just looking to see why there's no details for things like altering a column in a table.) Do you mean you want to have access to the details of the alter

Re: [HACKERS] "SQL sentence"?

Jim Nasby wrote: > On 2/17/17 10:19 PM, Alvaro Herrera wrote: > > > (FWIW, I'm wondering because I was just looking to see why there's no > > > details for things like altering a column in a table.) > > Do you mean you want to have access to the details of the alter table > > operations being

Re: [HACKERS] pg_get_object_address() doesn't support composites

On 2/17/17 9:53 PM, Alvaro Herrera wrote: Another way to think about this problem is an approach Peter E suggested not long ago, which was to change the objname/objargs representation more completely. Hrm, I didn't see that. What was the idea? BTW, I do find it odd (and might eventually find

Re: [HACKERS] "SQL sentence"?

On 2/17/17 10:19 PM, Alvaro Herrera wrote: (FWIW, I'm wondering because I was just looking to see why there's no details for things like altering a column in a table.) Do you mean you want to have access to the details of the alter table operations being executed? There's no structured data

Re: [HACKERS] "SQL sentence"?

Jim Nasby wrote: > I'm confused by this: > > "pg_event_trigger_ddl_commands returns one row for each base command > executed; some commands that are a single SQL sentence may return more than > one row." > > What is a "SQL sentence"? I meant "a single SQL command". The word "sentence" probably

Re: [HACKERS] Official adoption of PGXN

On 2/14/17 2:39 PM, Andres Freund wrote: One part of this would need to be having a designated committee of the Postgres community pick a set of "blessed" extensions for packagers to package. Right now, contrib serves that purpose (badly). One of the reasons we haven't dealt with the extension

[HACKERS] "SQL sentence"?

I'm confused by this: "pg_event_trigger_ddl_commands returns one row for each base command executed; some commands that are a single SQL sentence may return more than one row." What is a "SQL sentence"? (FWIW, I'm wondering because I was just looking to see why there's no details for

Re: [HACKERS] pg_get_object_address() doesn't support composites

Jim Nasby wrote: > See below. ISTM that pg_get_object_address should support everything > pg_identify_object_as_address can output, no? > > I'm guessing the answer here is to have pg_identify_object_as_address > complain if you ask it for something that's not mapable. Yes, I think we should just

[HACKERS] pg_get_object_address() doesn't support composites

See below. ISTM that pg_get_object_address should support everything pg_identify_object_as_address can output, no? I'm guessing the answer here is to have pg_identify_object_as_address complain if you ask it for something that's not mapable. ~@decina.local/5621# CREATE TYPE comp AS (a int,

Re: [HACKERS] Instability in select_parallel regression test

On Fri, Feb 17, 2017 at 9:15 PM, Tom Lane wrote: > Amit Kapila writes: >> On Fri, Feb 17, 2017 at 11:22 AM, Tom Lane wrote: >>> In short, it looks to me like ExecShutdownGatherWorkers doesn't actually >>> wait for parallel workers

Re: [HACKERS] [PATCH] Add pg_disable_checksums() and supporting infrastructure

On Feb 17, 2017, at 10:31 AM, Magnus Hagander wrote: > > On Thu, Feb 16, 2017 at 9:58 PM, David Christensen wrote: > Extracted from a larger patch, this patch provides the basic infrastructure > for turning data > checksums off in a cluster. This also

Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting for checkpoint

On Fri, Feb 17, 2017 at 4:22 PM, Tomas Vondra wrote: > What about adding a paragraph into pg_basebackup docs, explaining that > with 'fast' it does immediate checkpoint, while with 'spread' it'll wait > for a spread checkpoint. > I agree that a better, and

Re: [HACKERS] Official adoption of PGXN

On 2/14/17 15:19, Josh Berkus wrote: > You have to admit that it seems really strange in the eyes of a new user > that ISN is packaged with PostgreSQL, whereas better-written and more > popular extensions (like plv8, pg_partman or pgq) are not. I don't know. Seems pretty standard coming from a

Re: [HACKERS] patch: optimize information_schema.constraint_column_usage

On 2/2/17 08:27, Alexey Bashtanov wrote: > The view information_schema.constraint_column_usage becomes slow when > the number of columns and constraints raise to substantial values. > This is because of a join condition that allows only join filter to > enforce. The patch is to optimize it.

Re: [HACKERS] pg_recvlogical.c doesn't build with --disable-integer-datetimes

Mark Dilger writes: >> On Feb 17, 2017, at 3:37 PM, Peter Eisentraut >> wrote: >> If your compiler isn't warning about anything with that, then there is >> something wrong with it. > $ gcc --version > Configured with:

Re: [HACKERS] [PATCH] Teach Catalog.pm how many attributes there should be per DATA() line

On 2/15/17 10:40, David Christensen wrote: > Throws a build error if we encounter a different number of fields in a > DATA() line than we expect for the catalog in question. > > Previously, it was possible to silently ignore any mismatches at build > time which could result in symbol undefined

Re: [HACKERS] pg_basebackup -R

On 2/15/17 10:52, Robert Haas wrote: > Let's wait and see if anybody else has an opinion. I imagine that, as > further libpq parameters are added, eventually this is going to get > long and annoying enough that we want to do something about it. But > we might not have reached that point just

Re: [HACKERS] pg_recvlogical.c doesn't build with --disable-integer-datetimes

> On Feb 17, 2017, at 3:37 PM, Peter Eisentraut > wrote: > > On 2/17/17 16:13, Mark Dilger wrote: >> + PGAC_PROG_CC_CFLAGS_OPT([-Wc++-compat]) > > If your compiler isn't warning about anything with that, then there is > something wrong with it. $ gcc

Re: [HACKERS] 2 doc typos

On 2/16/17 09:38, Thom Brown wrote: > Please find attached a patch to fix 2 typos. > > 1) s/mypubclication/mypublication/ > > 2) Removed trailing comma from last column definition in example. committed, thanks -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] pg_recvlogical.c doesn't build with --disable-integer-datetimes

On 2/17/17 16:13, Mark Dilger wrote: > + PGAC_PROG_CC_CFLAGS_OPT([-Wc++-compat]) If your compiler isn't warning about anything with that, then there is something wrong with it. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA,

Re: [HACKERS] pg_recvlogical.c doesn't build with --disable-integer-datetimes

I wrote: > Right now I'd rather focus on getting to where we can have -Werror on in > the buildfarm at all. longfin says we've got work to do on that, at least > in the back branches. It may be that we can't expect near-EOL branches to > always compile perfectly cleanly on newer compilers. I

[HACKERS] logical replication access control patches

Here is a patch set to refine various access control settings in logical replication. Currently, you need to be replication or superuser for most things, and the goal of these patches is to allow ordinary users equipped with explicit privileges to do most things. (Btw., current documentation is

Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting for checkpoint

On 02/17/2017 08:17 PM, Jim Nasby wrote: > On 2/14/17 5:18 PM, Robert Haas wrote: >> On Tue, Feb 14, 2017 at 4:06 PM, Alvaro Herrera >> wrote: >>> I'd rather have a --quiet mode instead. If you're running it by hand, >>> you're likely to omit the switch, whereas when

Re: [HACKERS] SUBSCRIPTIONS and pg_upgrade

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 2/17/17 09:33, Stephen Frost wrote: > >> One reason is that pg_subscription is only readable by a superuser, so > >> we can't even dump them unless we're superuser. > > Sure, but that's true of roles and other things.. On a

Re: [HACKERS] SUBSCRIPTIONS and pg_upgrade

On 2/17/17 09:33, Stephen Frost wrote: >> One reason is that pg_subscription is only readable by a superuser, so >> we can't even dump them unless we're superuser. > Sure, but that's true of roles and other things.. On a system with RLS, > likely only the database superuser can actually read

Re: [HACKERS] pg_recvlogical.c doesn't build with --disable-integer-datetimes

Mark Dilger writes: > if test "$GCC" = yes -a "$ICC" = no; then >CFLAGS="-Wall -Wmissing-prototypes -Wpointer-arith" > + PGAC_PROG_CC_CFLAGS_OPT([-Wempty-body]) > + PGAC_PROG_CC_CFLAGS_OPT([-Wignored-qualifiers]) > +

Re: [HACKERS] pg_recvlogical.c doesn't build with --disable-integer-datetimes

On February 17, 2017 1:13:10 PM PST, Mark Dilger wrote: >How about we add (some of) these extra warnings, plus -Werror, >in a section that is only active for platforms/compilers where we >know there aren't spurious warnings? That would make detecting >unintentionally

Re: [HACKERS] pg_recvlogical.c doesn't build with --disable-integer-datetimes

> On Feb 17, 2017, at 12:21 PM, Tom Lane wrote: > > Thomas Munro writes: >> On Sat, Feb 18, 2017 at 9:04 AM, Tom Lane wrote: >>> [ pokes around... ] Ah, that's called COPT, and it's entirely >>> undocumented :-(.

Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting for checkpoint

On 2/14/17 5:18 PM, Robert Haas wrote: On Tue, Feb 14, 2017 at 4:06 PM, Alvaro Herrera wrote: I'd rather have a --quiet mode instead. If you're running it by hand, you're likely to omit the switch, whereas when writing the cron job you're going to notice lack of

Re: [HACKERS] pg_recvlogical.c doesn't build with --disable-integer-datetimes

Thomas Munro writes: > On Sat, Feb 18, 2017 at 9:04 AM, Tom Lane wrote: >> [ pokes around... ] Ah, that's called COPT, and it's entirely >> undocumented :-(. Probably ought to fix that. > One way to set that up is like this: > $ cat

Re: [HACKERS] pg_recvlogical.c doesn't build with --disable-integer-datetimes

On Sat, Feb 18, 2017 at 9:04 AM, Tom Lane wrote: > Andres Freund writes: >> On February 17, 2017 11:40:57 AM PST, Tom Lane wrote: >>> AFAICS, if you want to build with -Werror, you have to configure >>> without that and then inject it

Re: [HACKERS] pg_recvlogical.c doesn't build with --disable-integer-datetimes

Andres Freund writes: > On February 17, 2017 11:40:57 AM PST, Tom Lane wrote: >> AFAICS, if you want to build with -Werror, you have to configure >> without that and then inject it afterwards. I wonder how people who >> use -Werror are handling that. Is

Re: [HACKERS] pg_recvlogical.c doesn't build with --disable-integer-datetimes

> On Feb 17, 2017, at 11:40 AM, Tom Lane wrote: > > I wrote: >> Yeah. I have longfin which is running Apple's clang, and is on a machine >> that doesn't have much to do otherwise. I propose to turn on -Werror in >> its configuration, and to configure a second critter on

Re: [HACKERS] pg_recvlogical.c doesn't build with --disable-integer-datetimes

On February 17, 2017 11:40:57 AM PST, Tom Lane wrote: >I wrote: >> Yeah. I have longfin which is running Apple's clang, and is on a >machine >> that doesn't have much to do otherwise. I propose to turn on -Werror >in >> its configuration, and to configure a second critter

Re: [HACKERS] pg_recvlogical.c doesn't build with --disable-integer-datetimes

I wrote: > Yeah. I have longfin which is running Apple's clang, and is on a machine > that doesn't have much to do otherwise. I propose to turn on -Werror in > its configuration, and to configure a second critter on the same hardware > that runs with -Werror as well as

Re: [HACKERS] Does having a NULL column automatically exclude the table from the tupleDesc cache?

On 2/15/17 1:37 PM, Ryan Murphy wrote: attcacheoff can only be set positive for fields preceding any varlena (typlen<0, but including the first such) or nullable values. I don't know how much faster it is with the cache; you can measure it if your curiosity is strong enough --

Re: [HACKERS] Reporting xmin from VACUUMs

On 2/15/17 12:05 PM, Alvaro Herrera wrote: Jim Nasby wrote: ISTR previous discussion of allowing more stats files; if that happened I think having stats that were dedicated to (auto)vacuum would be very useful. That's clearly a lot more work though. What? There's a bunch of information

Re: [HACKERS] possibility to specify template database for pg_regress

On 2/14/17 2:49 PM, Pavel Stehule wrote: > Tom's use case might be more easily served by specifying a > template database. I don't think Pavel ever posted his use case. Wait, that's precisely what Pavel asked? I would to use regress test environment in my current case. 99% code in

Re: [HACKERS] pg_recvlogical.c doesn't build with --disable-integer-datetimes

Alvaro Herrera writes: > Tom Lane wrote: >> My own compilers don't generate errors either, only warnings. Maybe >> we could catch this sort of thing mechanically with a critter configured >> with -Werror as well as --disable-integer-datetimes, but I'm a tad >> hesitant

[HACKERS] Keeping pg_recvlogical's "feTimestamp" separate from TimestampTz

Thomas Munro pointed out that commit 7c030783a broke things on --disable-integer-datetimes builds, because somebody cleverly used TimestampTz to declare timestamp variables, no doubt not having read the comment (which doesn't even appear in the same file :-() that * ... The replication protocol

Re: [HACKERS] pg_recvlogical.c doesn't build with --disable-integer-datetimes

Tom Lane wrote: > My own compilers don't generate errors either, only warnings. Maybe > we could catch this sort of thing mechanically with a critter configured > with -Werror as well as --disable-integer-datetimes, but I'm a tad > hesitant to have a buildfarm machine configured with -Werror.

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On Fri, Feb 17, 2017 at 9:31 AM, Tom Lane wrote: > This seems like it'd be quite a different tool than amcheck, though. > Also, it would only find broken-HOT-chain corruption, which might be > a rare enough issue to not deserve a single-purpose tool. FWIW, my ambition for

Re: [HACKERS] [PATCH] Add pg_disable_checksums() and supporting infrastructure

> On Feb 17, 2017, at 10:31 AM, Magnus Hagander wrote: > > Per the point made by somebody else (I think Simon?) on the other thread, I > think it also needs WAL support. Otherwise you turn it off on the master, but > it remains on on a replica which will cause failures

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

I wrote: > However, you might be able to find it without so much random I/O. > I'm envisioning a seqscan over the table, in which you simply look for > HOT chains in which the indexed columns aren't all the same. When you > find one, you'd have to do a pretty expensive index lookup to confirm >

Re: [HACKERS] removing tsearch2

On Feb 17, 2017, at 12:54 AM, Magnus Hagander wrote: > If we could somehow integrate PGXN with both the RPM build process, the DEB > build process and a Windows build process (whether driven by PGXN or just > "fed enough data" by PGXN is a different question), I think that

Re: [HACKERS] CREATE SUBSCRIPTION uninterruptable

On 17 February 2017 at 14:14, Peter Eisentraut wrote: > On 2/16/17 09:44, Thom Brown wrote: >> I've noticed that when creating a subscription, it can't be >> interrupted. One must wait until it times out, which takes just over >> 2 minutes. I'm guessing ALTER

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

Peter Geoghegan writes: > The difference with a test that could detect this variety of > corruption is that that would need to visit the heap, which tends to > be much larger than any one index, or even all indexes. That would > probably need to be random I/O, too. It might be

Re: [HACKERS] pg_recvlogical.c doesn't build with --disable-integer-datetimes

I wrote: > Thomas Munro writes: >> Since commit 7c030783a5bd07cadffc2a1018bc33119a4c7505 it seems that $SUBJECT. > Hmm ... I thought we had at least one buildfarm member still testing > --disable-integer-datetimes. Evidently somebody needs to close that > gap.

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On Fri, Feb 17, 2017 at 8:23 AM, Keith Fiske wrote: > It's not the load I'm worried about, it's the locks that are required at > some point during the rebuild. Doing an index rebuild here and there isn't a > big deal, but trying to do it for an entire heavily loaded,

Re: [HACKERS] [COMMITTERS] pgsql: Add new function dsa_allocate0.

Robert Haas writes: > I'm thinking we should change this to look more like the > MemoryContextAlloc interface. Let's have DSA_ALLOC_HUGE, > DSA_ALLOC_NO_OOM, and DSA_ALLOC_ZERO, just like the corresponding > MCXT_* flags, and a function dsa_allocate_extended() that takes a

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

Keith Fiske wrote: > I can understandable if it's simply not possible, but if it is, I think in > any cases of data corruption, having some means to check for it to be sure > you're in the clear would be useful. Maybe it is possible. I just didn't try, since it didn't seem very useful. --

Re: [HACKERS] [PATCH] Add pg_disable_checksums() and supporting infrastructure

On Thu, Feb 16, 2017 at 9:58 PM, David Christensen wrote: > Extracted from a larger patch, this patch provides the basic > infrastructure for turning data > checksums off in a cluster. This also sets up the necessary pg_control > fields to support the > necessary multiple

Re: [HACKERS] Parallel Append implementation

On 16 February 2017 at 20:37, Robert Haas wrote: > I'm not sure that it's going to be useful to make this logic very > complicated. I think the most important thing is to give 1 worker to > each plan before we give a second worker to any plan. In general I > think it's

Re: [HACKERS] Parallel Append implementation

Ashutosh Bapat wrote: > Do we have any performance measurements where we see that Goal B > performs better than Goal A, in such a situation? Do we have any > performance measurement comparing these two approaches in other > situations. If implementation for Goal B

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On Fri, Feb 17, 2017 at 11:12 AM, Alvaro Herrera wrote: > Keith Fiske wrote: > > > Was just curious if anyone was able to come up with any sort of method to > > test whether an index was corrupted by this bug, other than just waiting > > for bad query results? We've

Re: [HACKERS] Help text for pg_basebackup -R

Stephen Frost writes: > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: >> Magnus Hagander wrote: >>> I'm guessing if we backpatch something like that, it would cause issues for >>> translations, right? So we should make it head only? >> We've had the argument a number of

Re: [HACKERS] pg_recvlogical.c doesn't build with --disable-integer-datetimes

Thomas Munro writes: > Since commit 7c030783a5bd07cadffc2a1018bc33119a4c7505 it seems that $SUBJECT. Hmm ... I thought we had at least one buildfarm member still testing --disable-integer-datetimes. Evidently somebody needs to close that gap. > Maybe the attached

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

Keith Fiske wrote: > Was just curious if anyone was able to come up with any sort of method to > test whether an index was corrupted by this bug, other than just waiting > for bad query results? We've used concurrent index rebuilding quite > extensively over the years to remove bloat from busy

Re: [HACKERS] Sum aggregate calculation for single precsion real

Robert Haas writes: > On Fri, Feb 17, 2017 at 6:51 AM, Greg Stark wrote: >> Moreover, it wouldn't be hard to make sum(float4) use a float8 as an >> accumulator and then cast to float4 for the final state. That would be >> 100% compatible with the existing

Re: [HACKERS] Instability in select_parallel regression test

Amit Kapila writes: > On Fri, Feb 17, 2017 at 11:22 AM, Tom Lane wrote: >> In short, it looks to me like ExecShutdownGatherWorkers doesn't actually >> wait for parallel workers to finish (as its comment suggests is >> necessary), so that on

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On Mon, Feb 6, 2017 at 10:17 PM, Amit Kapila wrote: > On Mon, Feb 6, 2017 at 10:28 PM, Tom Lane wrote: > > Amit Kapila writes: > >> Hmm. Consider that the first time relcahe invalidation occurs while > >> computing

Re: [HACKERS] pg_recvlogical.c doesn't build with --disable-integer-datetimes

Thomas Munro wrote: > Hi, > > Since commit 7c030783a5bd07cadffc2a1018bc33119a4c7505 it seems that $SUBJECT. Added it to open items list. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via

Re: [HACKERS] Logical Replication and Character encoding

On 2/15/17 17:55, Petr Jelinek wrote: > I am not quite convinced that this should be handled by logical decoding > itself. It's quite possible to have output plugins that will handle this > correctly for their use-cases (by doing similar conversion you did in > the original patch) so they should

Re: [HACKERS] Help text for pg_basebackup -R

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Magnus Hagander wrote: > > On Wednesday, February 15, 2017, Alvaro Herrera > > wrote: > > > > > Magnus Hagander wrote: > > > > > > > printf(_(" -R, --write-recovery-conf\n" > > > > - "

[HACKERS] Question about memory contexts in ReindexMultipleTables()

Hi, When working on REINDEX CONCURRENTLY I noticed that the new memory context created in the ReindexMultipleTables() seems pointless. The purpose claimed in the code for introducing the ReindexMultipleTables context is to make sure the list we build with relation IDs survive the commit,

Re: [HACKERS] Provide list of subscriptions and publications in psql's completion

* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 2/13/17 12:07, Fujii Masao wrote: > > Anyway IMO that we can expose all the > > columns except the sensitive information (i.e., subconninfo field) > > in pg_subscription to even non-superusers. > > You mean with column privileges?

Re: [HACKERS] SUBSCRIPTIONS and pg_upgrade

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 2/16/17 21:04, Stephen Frost wrote: > > I'm not entirely sure about the reasoning behind requiring a flag to > > include subscriptions in pg_dump output, > > One reason is that pg_subscription is only readable by a

Re: [HACKERS] Provide list of subscriptions and publications in psql's completion

On 2/13/17 12:07, Fujii Masao wrote: > Anyway IMO that we can expose all the > columns except the sensitive information (i.e., subconninfo field) > in pg_subscription to even non-superusers. You mean with column privileges? We could probably do that. I don't know if we have done that before on

Re: [HACKERS] CREATE SUBSCRIPTION uninterruptable

On 2/16/17 09:44, Thom Brown wrote: > I've noticed that when creating a subscription, it can't be > interrupted. One must wait until it times out, which takes just over > 2 minutes. I'm guessing ALTER SUBSCRIPTION would have the same > problem. > > Shouldn't we have an interrupt for this? I

Re: [HACKERS] SUBSCRIPTIONS and pg_upgrade

On 2/16/17 21:04, Stephen Frost wrote: > I'm not entirely sure about the reasoning behind requiring a flag to > include subscriptions in pg_dump output, One reason is that pg_subscription is only readable by a superuser, so we can't even dump them unless we're superuser. Also, restoring a

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On Fri, Feb 17, 2017 at 10:43 PM, Andreas Karlsson wrote: > Thinking about this makes me wonder about why you decided to use a > transaction per index in many of the steps rather than a transaction per > step. Most steps should be quick. The only steps I think the makes sense

Re: [HACKERS] SCRAM authentication, take three

On Wed, Feb 15, 2017 at 9:27 PM, Michael Paquier wrote: > On Wed, Feb 15, 2017 at 7:58 PM, Heikki Linnakangas wrote: >> On 02/09/2017 09:33 AM, Michael Paquier wrote: >>> Now regarding the shape of the implementation for SCRAM, we need one >>> thing: a

[HACKERS] [POC] A better way to expand hash indexes.

Hi all, As of now, we expand the hash index by doubling the number of bucket blocks. But unfortunately, those blocks will not be used immediately. So I thought if we can differ bucket block allocation by some factor, hash index size can grow much efficiently. I have written a POC patch which does

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On 02/17/2017 01:53 PM, Andreas Karlsson wrote: I am actually thinking about going the opposite direction (by reducing the number of times we call WaitForLockers), because it is not just about consuming transaction IDs, we also do not want to wait too many times for transactions to commit. I am

Re: [HACKERS] Help text for pg_basebackup -R

Magnus Hagander wrote: > On Wednesday, February 15, 2017, Alvaro Herrera > wrote: > > > Magnus Hagander wrote: > > > > > printf(_(" -R, --write-recovery-conf\n" > > > - " write recovery.conf > > after backup\n")); > >

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

Amit, * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote: > In certain cases, pg_dump's dumpTableSchema() emits a separate ALTER TABLE > command for those schema elements of a table that could not be included > directly in the CREATE TABLE command for the table. Any chance we could start

Re: [HACKERS] Sum aggregate calculation for single precsion real

On Fri, Feb 17, 2017 at 6:51 AM, Greg Stark wrote: > On 15 February 2017 at 12:52, Robert Haas wrote: >> Personally, I find it somewhere in the middle: I think the way it >> works now is reasonable, and I think what he wants would have been >> reasonable as

Re: [HACKERS] [COMMITTERS] pgsql: Add new function dsa_allocate0.

On Thu, Feb 16, 2017 at 10:09 PM, Michael Paquier wrote: > On Fri, Feb 17, 2017 at 12:03 PM, Thomas Munro > wrote: >> On Fri, Feb 17, 2017 at 11:34 AM, Thomas Munro >> wrote: >>> On Fri, Feb 17, 2017 at

Re: [HACKERS] Gather Merge

On Fri, Feb 17, 2017 at 4:47 PM, Amit Kapila wrote: > On Fri, Feb 17, 2017 at 3:59 PM, Thomas Munro > wrote: > > On Thu, Feb 2, 2017 at 2:32 AM, Rushabh Lathia > wrote: > >> Please find attached latest patch. > >

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On 02/14/2017 04:56 AM, Michael Paquier wrote: On Tue, Feb 14, 2017 at 11:32 AM, Andreas Karlsson wrote: On 02/13/2017 06:31 AM, Michael Paquier wrote: Er, something like that as well, no? DETAIL: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s. REINDEX (VERBOSE)

Re: [HACKERS] Instability in select_parallel regression test

On Fri, Feb 17, 2017 at 11:22 AM, Tom Lane wrote: > Buildfarm members gaur, pademelon, and gharial have all recently shown > failures like this: > > *** > /home/bfarm/bf-data/HEAD/pgsql.build/src/test/regress/expected/select_parallel.out > Thu Feb 16 20:35:14 2017 > --- >

Re: [HACKERS] Gather Merge

On Fri, Feb 17, 2017 at 3:59 PM, Thomas Munro wrote: > On Thu, Feb 2, 2017 at 2:32 AM, Rushabh Lathia > wrote: > > Please find attached latest patch. > > The latest patch still applies (with some fuzz), builds and the > regression tests

Re: [HACKERS] Sum aggregate calculation for single precsion real

On 15 February 2017 at 12:52, Robert Haas wrote: > Personally, I find it somewhere in the middle: I think the way it > works now is reasonable, and I think what he wants would have been > reasonable as well. However, I find it hard to believe it would be > worth changing

Re: [HACKERS] Gather Merge

On Fri, Feb 17, 2017 at 3:59 PM, Thomas Munro wrote: > On Thu, Feb 2, 2017 at 2:32 AM, Rushabh Lathia > wrote: >> Please find attached latest patch. > > The latest patch still applies (with some fuzz), builds and the > regression tests

Re: [HACKERS] Gather Merge

On Thu, Feb 2, 2017 at 2:32 AM, Rushabh Lathia wrote: > Please find attached latest patch. The latest patch still applies (with some fuzz), builds and the regression tests pass. I see that Robert made a number of changes and posted a v6 along with some numbers which he

Re: [HACKERS] Should we cacheline align PGXACT?

On Fri, Feb 17, 2017 at 12:44 PM, Ashutosh Sharma wrote: > >> On Thu, Feb 16, 2017 at 5:07 AM, Alexander Korotkov > >> wrote: > >> > On Wed, Feb 15, 2017 at 8:49 PM, Alvaro Herrera > >> > > >> > wrote: > >> >>

Re: [HACKERS] Should we cacheline align PGXACT?

Hi, >> On Thu, Feb 16, 2017 at 5:07 AM, Alexander Korotkov >> wrote: >> > On Wed, Feb 15, 2017 at 8:49 PM, Alvaro Herrera >> > >> > wrote: >> >> Alexander Korotkov wrote: >> >> >> >> > Difference between master, pgxact-align-2 and

Re: [HACKERS] Parallel Append implementation

On 16 February 2017 at 20:37, Robert Haas wrote: > On Thu, Feb 16, 2017 at 1:34 AM, Amit Khandekar > wrote: >>> What I was thinking about is something like this: >>> >>> 1. First, take the maximum parallel_workers value from among all the >>>

Re: [HACKERS] Should we cacheline align PGXACT?

On Thu, Feb 16, 2017 at 4:58 PM, Robert Haas wrote: > On Thu, Feb 16, 2017 at 5:07 AM, Alexander Korotkov > wrote: > > On Wed, Feb 15, 2017 at 8:49 PM, Alvaro Herrera < > alvhe...@2ndquadrant.com> > > wrote: > >> Alexander Korotkov wrote: > >> >

Re: [HACKERS] Help text for pg_basebackup -R

On Wednesday, February 15, 2017, Alvaro Herrera wrote: > Magnus Hagander wrote: > > > printf(_(" -R, --write-recovery-conf\n" > > - " write recovery.conf > after backup\n")); > > + "

Re: [HACKERS] removing tsearch2

On Tuesday, February 14, 2017, David E. Wheeler wrote: > On Feb 14, 2017, at 9:37 AM, Magnus Hagander > wrote: > > > It's a failing in one of the two at least. It either needs to be easier > to build the things on windows, or pgxn would

[HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

In certain cases, pg_dump's dumpTableSchema() emits a separate ALTER TABLE command for those schema elements of a table that could not be included directly in the CREATE TABLE command for the table. For example: create table p (a int, b int) partition by range (a); create table p1 partition of p