Re: [HACKERS] extend pgbench expressions with functions

I guess the question here is whether we want the part-c patch, which removes the historical \setrandom syntax. That's technically no longer needed since we now can use random() as a function directly inside \set commands, but we might want it anyway for backward compatibility. This patch is

Re: [HACKERS] Re: [COMMITTERS] pgsql: Sync tzload() and tzparse() APIs with IANA release tzcode2016c.

Christian Ullrich writes: > * Tom Lane wrote: >> Yeah. I've been staring at that for awhile, but it's not clear where >> the problem is. There are a bunch of other SET TIME ZONE commands in >> the regression tests, how is it that this trivial case fails on the >> Windows

[HACKERS] Re: [COMMITTERS] pgsql: Sync tzload() and tzparse() APIs with IANA release tzcode2016c.

On Tue, Mar 29, 2016 at 1:36 PM, Christian Ullrich wrote: > * Tom Lane wrote: > >> Michael Paquier writes: >>> >>> Buildfarm-not-being-happy-status: woodloose, mastodon, thrips, jacana. >>> >>>

Re: [HACKERS] [COMMITTERS] pgsql: pgbench: Support double constants and functions.

On Tue, Mar 29, 2016 at 1:56 PM, Tom Lane wrote: > Michael Paquier writes: >> On Tue, Mar 29, 2016 at 9:52 AM, Robert Haas wrote: >>> pgbench: Support double constants and functions. > >> Instead of INT64_MIN and INT64_MAX, I

Re: [HACKERS] [COMMITTERS] pgsql: pgbench: Support double constants and functions.

Michael Paquier writes: > On Tue, Mar 29, 2016 at 9:52 AM, Robert Haas wrote: >> pgbench: Support double constants and functions. > Instead of INT64_MIN and INT64_MAX, I think that it would be better to > use PG_INT64_MIN and PG_INT64_MAX.

Re: [HACKERS] Relation extension scalability

On Tue, Mar 29, 2016 at 3:21 AM, Petr Jelinek wrote: > On 28/03/16 14:46, Dilip Kumar wrote: > >> >> Conclusion: >> --- >> 1. I think v15 is solving the problem exist with v13 and performance >> is significantly high compared to base, and

[HACKERS] Re: [COMMITTERS] pgsql: Sync tzload() and tzparse() APIs with IANA release tzcode2016c.

* Tom Lane wrote: Michael Paquier writes: Buildfarm-not-being-happy-status: woodloose, mastodon, thrips, jacana. http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=woodlouse=2016-03-29%2000%3A42%3A08 The origin of the problem is that, which prevents all the

Re: [HACKERS] [COMMITTERS] pgsql: pgbench: Support double constants and functions.

On Tue, Mar 29, 2016 at 9:52 AM, Robert Haas wrote: > pgbench: Support double constants and functions. > > The new functions are pi(), random(), random_exponential(), > random_gaussian(), and sqrt(). I was worried that this would be > slower than before, but, if anything,

[HACKERS] psql stops completion for the only matching schema name.

Hello, I found that COMPLETE_SCHEMA_QUERY doesn't complete only-one-matching schema names. =# alter foreign table information_schema. pg_temp_1. pg_toast_temp_1. pg_catalog. pg_toast.public. =# alter foreign table i or =# alter foreign table pu This makes

Re: [HACKERS] raw output from copy

Hi >>> Anyway this is certainly not committable as-is, so I'm setting it back >>> to Waiting on Author. But the fact that both libpq and ecpg would need >>> updates makes me question whether we can safely pretend that this isn't >>> a protocol break. >>> >>> >>> >> >> >> In that case I humbly

Re: [HACKERS] raw output from copy

Hi 2016-03-29 0:26 GMT+02:00 Tom Lane : > Pavel Stehule writes: > > [ copy-raw-format-20160227-03.patch ] > > I looked at this patch. I'm having a hard time accepting that it has > a use-case large enough to justify it, and here's the reason: it's >

Re: [HACKERS] [COMMITTERS] pgsql: Sync tzload() and tzparse() APIs with IANA release tzcode2016c.

Michael Paquier writes: > Buildfarm-not-being-happy-status: woodloose, mastodon, thrips, jacana. > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=woodlouse=2016-03-29%2000%3A42%3A08 > The origin of the problem is that, which prevents all the subsequent > queries

Re: [HACKERS] raw output from copy

2016-03-29 5:12 GMT+02:00 Andrew Dunstan : > > > On 03/28/2016 06:26 PM, Tom Lane wrote: > >> Pavel Stehule writes: >> >>> [ copy-raw-format-20160227-03.patch ] >>> >> I looked at this patch. I'm having a hard time accepting that it has >> a

Re: [HACKERS] Using quicksort for every external sort run

On Thu, Mar 10, 2016 at 6:54 PM, Peter Geoghegan wrote: > I've used amcheck [2] to test this latest revision -- the tool ought > to not see any problems with any index created with the patch applied. > Reviewers might find it helpful to use amcheck, too. As 9.6 is > stabilized, I

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Tue, Mar 22, 2016 at 10:57 AM, Peter Geoghegan wrote: > That's right - I have a small number of feedback items to work > through. I also determined myself that there could be a very low > probability race condition when checking the key space across sibling > pages, and will

Re: [HACKERS] raw output from copy

On 03/28/2016 06:26 PM, Tom Lane wrote: Pavel Stehule writes: [ copy-raw-format-20160227-03.patch ] I looked at this patch. I'm having a hard time accepting that it has a use-case large enough to justify it, and here's the reason: it's a protocol break.

Re: [HACKERS] Reworks of CustomScan serialization/deserialization

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > Sent: Tuesday, March 29, 2016 10:54 AM > To: Kaigai Kouhei(海外 浩平) > Cc: Petr Jelinek; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Reworks of

Re: [HACKERS] Relation extension scalability

On Mon, Mar 28, 2016 at 8:46 AM, Dilip Kumar wrote: > Found one problem with V15, so sending the new version. > In V15 I am taking prev_blkno as targetBlock instead it should be the last > block of the relation at that time. Attaching new patch. BlockNumber

Re: [HACKERS] Relation extension scalability

On Sun, Mar 27, 2016 at 9:51 PM, Dilip Kumar wrote: > I think this is better option, Since we will search last two pages of FSM > tree, then no need to update the upper level of the FSM tree. Right ? Well, it's less important in that case, but I think it's still worth

Re: [HACKERS] Reworks of CustomScan serialization/deserialization

On Mon, Mar 28, 2016 at 9:36 PM, Kouhei Kaigai wrote: > I don't have a strong reason to keep these stuff in separate files. > Both stuffs covers similar features and amount of code are enough small. > So, the attached v4 just merged custom-node.[ch] stuff into extensible. >

Re: [HACKERS] Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat

On Thu, Mar 17, 2016 at 2:26 AM, Ashutosh Bapat wrote: > On Wed, Mar 16, 2016 at 10:22 PM, Tom Lane wrote: >> Robert Haas writes: >> > On Wed, Mar 16, 2016 at 4:10 AM, Ashutosh Bapat < >> >

Re: [HACKERS] Reworks of CustomScan serialization/deserialization

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > Sent: Friday, March 25, 2016 12:27 AM > To: Petr Jelinek > Cc: Kaigai Kouhei(海外 浩平); pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Reworks of

Re: [HACKERS] extend pgbench expressions with functions

* Michael Paquier (michael.paqu...@gmail.com) wrote: > On Tue, Mar 29, 2016 at 9:54 AM, Robert Haas wrote: > > On Sun, Mar 27, 2016 at 5:01 AM, Fabien COELHO wrote: > >> v40 is yet another rebase. > > > > Thanks. Committed after removing an

Re: [HACKERS] extend pgbench expressions with functions

On Tue, Mar 29, 2016 at 9:54 AM, Robert Haas wrote: > On Sun, Mar 27, 2016 at 5:01 AM, Fabien COELHO wrote: >> v40 is yet another rebase. > > Thanks. Committed after removing an unnecessary parameter from the > coerceToXXX() functions. > > I guess the

Re: [HACKERS] VS 2015 support in src/tools/msvc

On Tue, Mar 29, 2016 at 10:06 AM, Robert Haas wrote: > On Sun, Mar 27, 2016 at 10:35 PM, Michael Paquier > wrote: >> On Fri, Mar 25, 2016 at 9:48 PM, Andrew Dunstan wrote: >>> OK, sounds good. >> >> Just a side-note. Andres

[HACKERS] Re: [COMMITTERS] pgsql: Sync tzload() and tzparse() APIs with IANA release tzcode2016c.

On Tue, Mar 29, 2016 at 6:19 AM, Tom Lane wrote: > Sync tzload() and tzparse() APIs with IANA release tzcode2016c. > > This brings us a bit closer to matching upstream, but since it affects > files outside src/timezone/, we might choose not to back-patch it. > Hence keep it

Re: [HACKERS] VS 2015 support in src/tools/msvc

On Sun, Mar 27, 2016 at 10:35 PM, Michael Paquier wrote: > On Fri, Mar 25, 2016 at 9:48 PM, Andrew Dunstan wrote: >> OK, sounds good. > > Just a side-note. Andres has pushed the fix for the GinIs* macros as > af4472bc, making patch 0003 from the

Re: [HACKERS] Typo in comment

On Sat, Mar 26, 2016 at 4:21 PM, Thomas Munro wrote: > Here are a couple of patches to fix a typo in a comment in latch.c: > > - * The memory barrier has be to be placed here to ensure that any flag > + * The memory barrier has to be placed here to ensure that any

Re: [HACKERS] extend pgbench expressions with functions

On Sun, Mar 27, 2016 at 5:01 AM, Fabien COELHO wrote: > v40 is yet another rebase. Thanks. Committed after removing an unnecessary parameter from the coerceToXXX() functions. I guess the question here is whether we want the part-c patch, which removes the historical

Re: [HACKERS] WIP: Upper planner pathification

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kouhei Kaigai > Sent: Saturday, March 19, 2016 8:57 AM > To: Tom Lane > Cc: Robert Haas; Petr Jelinek; David Rowley; pgsql-hackers@postgresql.org > Subject: Re:

Re: [HACKERS] Some messages of pg_rewind --debug not getting translated

On Tue, Mar 29, 2016 at 2:45 AM, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Wed, Mar 23, 2016 at 12:24 AM, Alvaro Herrera >> wrote: >> > Seems reasonable. For the last hunk in your patch, though, I would add >> > a /* translator: */

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

Craig Ringer wrote: > I found a minor issue with the new psql method while writing tests for > failover slots. Patch attached. Thanks, pushed. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via

Re: [HACKERS] pthread portability

Michael McConville wrote: > The below diff fixes one problem: you can't compare pthread_t values > directly. Only the function pthread_equal(3) is defined. Direct > comparison usually works because most implementations define pthread_t > as an integer type. So is there a platform where this

[HACKERS] pthread portability

The below diff fixes one problem: you can't compare pthread_t values directly. Only the function pthread_equal(3) is defined. Direct comparison usually works because most implementations define pthread_t as an integer type. Relatedly, INVALID_THREAD is defined as (pthread_t)0. I don't think this

[HACKERS] help for old extension, first_last_agg bug in install with pg9.5

The C implementation is simple, the problem is with the makefile, https://github.com/wulczer/first_last_agg/issues/2 *some clues?* - - - make Makefile:25: /usr/lib/postgresql/9.5/lib/pgxs/src/makefiles/pgxs.mk: No such file or directory make: *** No rule to make target

Re: [HACKERS] raw output from copy

Pavel Stehule writes: > [ copy-raw-format-20160227-03.patch ] I looked at this patch. I'm having a hard time accepting that it has a use-case large enough to justify it, and here's the reason: it's a protocol break. Conveniently omitting to update protocol.sgml doesn't

Re: [HACKERS] BRIN is missing in multicolumn indexes documentation

Petr Jediný wrote: > Comments? This is my first patch to postgresql project, so comments > are very much welcomed. I think it's fine, so I pushed it. Thanks. I hope you already read this https://wiki.postgresql.org/wiki/So,_you_want_to_be_a_developer%3F -- Álvaro Herrera

Re: [HACKERS] Relation extension scalability

On 28/03/16 14:46, Dilip Kumar wrote: Conclusion: --- 1. I think v15 is solving the problem exist with v13 and performance is significantly high compared to base, and relation size is also stable, So IMHO V15 is winner over other solution, what other thinks ?

Re: [HACKERS] Dealing with collation and strcoll/strxfrm/etc

On Mon, Mar 28, 2016 at 12:36 PM, Stephen Frost wrote: > Having to figure out how each and every stdlib does versioning doesn't > sound fun, I certainly agree with you there, but it hardly seems > impossible. What we need, even if we look to move to ICU, is a place to >

[HACKERS] SQL access to access method details

While working on a tool to capture catalog/stats info and looking at cross version compatibility, I noticed that the pg_am changes removed SQL access to a bunch of AM info. [1] indicates that's part of the purpose of the patch; are we sure no tools are using this info? Unlike previous catalog

Re: [HACKERS] Dealing with collation and strcoll/strxfrm/etc

* Peter Geoghegan (p...@heroku.com) wrote: > On Mon, Mar 28, 2016 at 7:57 AM, Stephen Frost wrote: > > If we're going to talk about minimum requirements, I'd like to argue > > that we require whatever system we're using to have versioning (which > > glibc currently lacks, as I

Re: [HACKERS] Sequence Access Method WIP

On Thu, Mar 24, 2016 at 6:12 PM, Petr Jelinek wrote: > > Hi, > > I rebased this on top of the recently committed CREATE ACCESS METHOD. > Hi, I got the above error trying to apply to the current master: $ git apply /home/fabrizio/Downloads/0001-seqam-2016-03-24.patch

Re: [HACKERS] Dealing with collation and strcoll/strxfrm/etc

On Mon, Mar 28, 2016 at 7:57 AM, Stephen Frost wrote: > If we're going to talk about minimum requirements, I'd like to argue > that we require whatever system we're using to have versioning (which > glibc currently lacks, as I understand it...) to avoid the risk that > indexes

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

David Steele writes: > On 3/10/16 11:00 AM, Petr Jelinek wrote: >> The comment above errhidefromclient says "Only log levels below ERROR >> can be hidden from the client." but use of the errhidefromclient(true) >> actually does hide the error message from client, client just

Re: [HACKERS] Some messages of pg_rewind --debug not getting translated

Michael Paquier wrote: > On Wed, Mar 23, 2016 at 12:24 AM, Alvaro Herrera > wrote: > > Seems reasonable. For the last hunk in your patch, though, I would add > > a /* translator: */ comment explaining what each of the values is; > > otherwise it's just incomprehensible

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On Thu, Mar 24, 2016 at 7:12 PM, Peter Geoghegan wrote: > On Thu, Mar 24, 2016 at 7:17 AM, Robert Haas wrote: >> I really like this idea, and the performance results seem impressive, >> but I think we should push this out to 9.7. A btree patch that didn't

Re: [HACKERS] WIP: Access method extendability

Alexander Korotkov wrote: > On Thu, Mar 24, 2016 at 6:19 PM, Alvaro Herrera > wrote: > > > .. Oh crap. I just noticed I forgot to update a comment in pg_dump's > > getAccessMethods. And we're missing psql tab-complete support for the > > new commands. > > Attached

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Fri, Sep 11, 2015 at 8:01 PM, Amit Kapila wrote: > > On Thu, Sep 3, 2015 at 5:11 PM, Andres Freund wrote: > > > > Updated comments and the patch (increate_clog_bufs_v2.patch) > containing the same is attached. > Andres mentioned to me in off-list

Re: [HACKERS] BRIN is missing in multicolumn indexes documentation

Comments? This is my first patch to postgresql project, so comments are very much welcomed. PJ On Wed, Mar 23, 2016 at 8:40 PM, Petr Jediný wrote: >>> >>> Multicolumn BRIN is like GIN. Every column is indexed separately. >>> The order of the columns doesn't matter. >> >>

Re: [HACKERS] Parallel Queries and PostGIS

On Mon, Mar 28, 2016 at 9:45 AM, Stephen Frost wrote: > Paul, > > * Paul Ramsey (pram...@cleverelephant.ca) wrote: >> I spent some time over the weekend trying out the different modes of >> parallel query (seq scan, aggregate, join) in combination with PostGIS >> and have

Re: [HACKERS] Parallel Queries and PostGIS

Paul, * Paul Ramsey (pram...@cleverelephant.ca) wrote: > I spent some time over the weekend trying out the different modes of > parallel query (seq scan, aggregate, join) in combination with PostGIS > and have written up the results here: > >

[HACKERS] Parallel Queries and PostGIS

I spent some time over the weekend trying out the different modes of parallel query (seq scan, aggregate, join) in combination with PostGIS and have written up the results here: http://blog.cleverelephant.ca/2016/03/parallel-postgis.html The TL:DR; is basically * With some adjustments to

Re: [HACKERS] backup tools ought to ensure created backups are durable

On Mon, Mar 28, 2016 at 3:12 PM, Andres Freund wrote: > On 2016-03-28 11:35:57 +0200, Magnus Hagander wrote: > > On Mon, Mar 28, 2016 at 3:11 AM, Michael Paquier < > michael.paqu...@gmail.com> > > wrote: > > > > > On Mon, Mar 28, 2016 at 8:30 AM, Andres Freund

Re: [HACKERS] multivariate statistics v14

Tomas Vondra wrote: > I'm not sure about the prototypes though. It was a bit weird because > prototypes in the same header file were formatted very differently. Yeah, it is very odd. What happens is that the BSD indent binary does one thing (return type is in one line and function name in

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

Andres Freund wrote: > On 2016-03-28 15:46:43 +0300, Alexander Korotkov wrote: > > @@ -932,8 +936,13 @@ ReadBuffer_common(SMgrRelation smgr, cha > > > > if (isLocalBuf) > > { > > - /* Only need to adjust flags */ > > - bufHdr->flags |= BM_VALID; > > + /* >

Re: [HACKERS] Draft release notes for next week's releases

On Mon, Mar 28, 2016 at 10:24 AM, Tom Lane wrote: > I'm also not exactly convinced by your implicit assumption that ICU is > bug-free. Noah spent some time looking at ICU back when he was EnterpriseDB, and his conclusion was that ICU collations weren't stable across releases,

[HACKERS] Dealing with collation and strcoll/strxfrm/etc

All, Changed the thread name (we're no longer talking about release notes...). * Tom Lane (t...@sss.pgh.pa.us) wrote: > Oleg Bartunov writes: > > Should we start thinking about ICU ? > > Isn't it still true that ICU fails to meet our minimum requirements? > That would

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

25.03.2016 01:12, Peter Geoghegan: On Thu, Mar 24, 2016 at 7:17 AM, Robert Haas wrote: I really like this idea, and the performance results seem impressive, but I think we should push this out to 9.7. A btree patch that didn't have WAL support until two and a half weeks

Re: [HACKERS] Draft release notes for next week's releases

Oleg Bartunov writes: > Should we start thinking about ICU ? Isn't it still true that ICU fails to meet our minimum requirements? That would include (a) working with the full Unicode character range (not only UTF16) and (b) working with non-Unicode encodings. No doubt we

Re: [HACKERS] Combinations of pg_strdup/free in pg_dump code

Michael Paquier writes: > While reading some code of pg_dump, I noticed that the following > pattern is heavily present: > lanname = pg_strdup(stuff) > free(lanname); > When pg_strdup or any pg-related allocation routines are called, I > think that we

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2016-03-28 15:46:43 +0300, Alexander Korotkov wrote: > diff --git a/src/backend/storage/buffer/bufmnew file mode 100644 > index 6dd7c6e..fe6fb9c > --- a/src/backend/storage/buffer/bufmgr.c > +++ b/src/backend/storage/buffer/bufmgr.c > @@ -52,7 +52,6 @@ > #include "utils/resowner_private.h" >

Re: [HACKERS] WIP: Covering + unique indexes.

21.03.2016 19:53, Anastasia Lubennikova: 19.03.2016 08:00, Peter Geoghegan: On Fri, Mar 18, 2016 at 5:15 AM, David Steele wrote: It looks like this patch should be marked "needs review" and I have done so. Uh, no it shouldn't. I've posted an extensive review on the

[HACKERS] Combinations of pg_strdup/free in pg_dump code

Hi all, While reading some code of pg_dump, I noticed that the following pattern is heavily present: lanname = pg_strdup(stuff) free(lanname); One example is for example that: lanname = get_language_name(fout, transforminfo[i].trflang); if (typeInfo && lanname)

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Mon, Mar 28, 2016 at 10:08 PM, Thomas Munro wrote: > On Tue, Mar 29, 2016 at 1:56 AM, Thomas Munro > wrote: >> On Mon, Mar 28, 2016 at 8:54 PM, Michael Paquier >> wrote: >>> I have been also thinking a

Re: [HACKERS] pg_xlogdump fails to handle WAL file with multi-page XLP_FIRST_IS_CONTRECORD data

On 2016-03-28 13:21:41 +0530, Pavan Deolasee wrote: > On Wed, Mar 23, 2016 at 6:16 PM, Michael Paquier > wrote: > > > > > > > I'd just add dots at the end of the sentences in the comment blocks > > because that's project style, but I'm being picky, except that the > >

Re: [HACKERS] backup tools ought to ensure created backups are durable

On 2016-03-28 11:35:57 +0200, Magnus Hagander wrote: > On Mon, Mar 28, 2016 at 3:11 AM, Michael Paquier > wrote: > > > On Mon, Mar 28, 2016 at 8:30 AM, Andres Freund wrote: > > > As pointed out in > > > > >

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2016-03-28 11:48:46 +0530, Dilip Kumar wrote: > On Sun, Mar 27, 2016 at 5:48 PM, Andres Freund wrote: > > > > > What's sizeof(BufferDesc) after applying these patches? It should better > > be <= 64... > > > > It is 72. Ah yes, miscalculated the required alignment. Hm. So

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Tue, Mar 29, 2016 at 1:56 AM, Thomas Munro wrote: > On Mon, Mar 28, 2016 at 8:54 PM, Michael Paquier > wrote: >> I have been also thinking a lot about this patch, and the fact that >> the WAL receiver latch is being used within the

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Sun, Mar 27, 2016 at 4:31 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Sun, Mar 27, 2016 at 3:10 PM, Andres Freund wrote: > >> On 2016-03-27 12:38:25 +0300, Alexander Korotkov wrote: >> > On Sat, Mar 26, 2016 at 1:26 AM, Alexander Korotkov < >> >

Re: [HACKERS] Relation extension scalability

On Mon, Mar 28, 2016 at 3:02 PM, Dilip Kumar wrote: > 1. Relation Size : No change in size, its same as base and v13 > > 2. INSERT 1028 Byte 1000 tuple performance > --- > Client base v13 v15 > 1 117 124 122 > 2 111

Re: [HACKERS] Two division by 0 errors in optimizer/plan/planner.c and optimizer/path/costsize.c

On 2016-03-28 11:33, Aleksander Alekseev wrote: Hello, Piotr. Thanks for report. But I'm having some difficulties reproducing issues you described. Oh, if you want backtraces then either set a conditional breakpoint or add your own Assert like I did. Also it would be a good idea to

Re: [HACKERS] WIP: Access method extendability

Hi, Petr! On Thu, Mar 17, 2016 at 10:56 AM, Petr Jelinek wrote: > On 16/03/16 15:31, Teodor Sigaev wrote: > >> Good catch, thanks! Tests were added. >>> >> >> I don't see any objection, is consensus reached? I'm close to comiit >> that... >> >> > I did only cursory review

[HACKERS] Autovacuum to prevent wraparound tries to consume xid

Hackers, one our customer meet near xid wraparound situation. xid counter reached xidStopLimit value. So, no transactions could be executed in normal mode. But what I noticed is strange behaviour of autovacuum to prevent wraparound. It vacuums tables, updates pg_class and pg_database, but

Re: [HACKERS] Draft release notes for next week's releases

Oleg Bartunov-2 wrote > But still, icu provides us abbreviated keys and collation stability, Does include ICU mean that collation handling is identical across platforms? E.g. a query on Linux involving string comparison would yield the same result on MacOS and Windows? If that is the case I'm

Re: [HACKERS] Postgres_fdw join pushdown - INNER - FULL OUTER join combination generating wrong result

On 2016/03/28 18:17, Rajkumar Raghuwanshi wrote: I am testing postgres_fdw join pushdown feature for PostgreSQL 9.6 DB, and I observed below issue._ Observation:_ Inner join and full outer join combination on a table generating wrong result. SELECT * FROM lt; c1 1 2 (2 rows)

Re: [HACKERS] A question on systable_beginscan()

Hi, On 2016/03/25 23:49, Onder Kalaci wrote: > Hi hackers, > > As it's documented in the source code, systable_beginscan() could be used > to on non-system tables as well. My question is that, is it possible to > write a C code with systable_beginscan(), systable_getnext() and ScanKeys > which

Re: [HACKERS] Alter or rename enum value

> I do not know whether this would be a meaningful improvement for > common use-cases, though. (It'd help if people were more specific > about the use-cases they need to work.) For what its worth, in the company I am working for, InnoGames GmbH, not being able to alter enums is the number one

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Mon, Mar 28, 2016 at 5:50 PM, Kyotaro HORIGUCHI wrote: > Thank you for the new patch. Sorry to have overlooked some > versions. I'm looking the v19 patch now. > > make complains for an unused variable. > > | syncrep.c: In function ‘SyncRepGetSyncStandbys’: > |

Re: [HACKERS] backup tools ought to ensure created backups are durable

On Mon, Mar 28, 2016 at 3:11 AM, Michael Paquier wrote: > On Mon, Mar 28, 2016 at 8:30 AM, Andres Freund wrote: > > As pointed out in > > > http://www.postgresql.org/message-id/20160327232509.v5wgac5vskuse...@awork2.anarazel.de > > our backup tools

Re: [HACKERS] Two division by 0 errors in optimizer/plan/planner.c and optimizer/path/costsize.c

Hello, Piotr. Thanks for report. But I'm having some difficulties reproducing issues you described. I compiled PostgreSQL from master branch on FreeBSD 10.2 using this command: ``` CC=/usr/local/bin/gcc49 CFLAGS="-O0 -g" \ ./configure --enable-cassert --enable-debug \

Re: [HACKERS] Relation extension scalability

On Mon, Mar 28, 2016 at 7:21 AM, Dilip Kumar wrote: > I agree with that conclusion. I'm not quite sure where that leaves >> us, though. We can go back to v13, but why isn't that producing extra >> pages? It seems like it should: whenever a bulk extend rolls over to >> a

Re: [HACKERS] Draft release notes for next week's releases

On Mon, Mar 28, 2016 at 2:06 PM, Peter Geoghegan wrote: > On Mon, Mar 28, 2016 at 12:55 AM, Oleg Bartunov > wrote: > > We'll post the patch. > > Cool. > > > Teodor made something to get abbreviated keys work as > > I remember. I should say, that 27x

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 2016/03/28 17:50, Kyotaro HORIGUCHI wrote: > > # LISPers don't hesitate to dive into Sea of Parens. Sorry in advance to be off-topic: https://xkcd.com/297 :) Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

[HACKERS] Postgres_fdw join pushdown - INNER - FULL OUTER join combination generating wrong result

Hi, I am testing postgres_fdw join pushdown feature for PostgreSQL 9.6 DB, and I observed below issue. *Observation:* Inner join and full outer join combination on a table generating wrong result. SELECT * FROM lt; c1 1 2 (2 rows) SELECT * FROM ft; c1 1 2 (2 rows) \d+ ft

Re: [HACKERS] [PATCH] Phrase search ported to 9.6

Hi! On Sat, Mar 26, 2016 at 12:02 AM, David Steele wrote: > On 3/25/16 3:54 PM, Artur Zakirov wrote: > > On 25.03.2016 21:42, Dmitry Ivanov wrote: > >> Sorry for the delay, I desperately needed some time to finish a bunch of > >> dangling tasks. > >> > >> I've added some

Re: [HACKERS] Support for N synchronous standby servers - take 2

Thank you for the new patch. Sorry to have overlooked some versions. I'm looking the v19 patch now. make complains for an unused variable. | syncrep.c: In function ‘SyncRepGetSyncStandbys’: | syncrep.c:601:13: warning: variable ‘next’ set but not used [-Wunused-but-set-variable] |ListCell

Re: [HACKERS] multivariate statistics v14

On 03/26/2016 08:09 PM, Alvaro Herrera wrote: Tomas Vondra wrote: There are a few places where I reverted the pgindent formatting, because it seemed a bit too weird - the first one are the lists of function prototypes in common.h/mvstat.h, the second one are function calls to

Re: [HACKERS] multivariate statistics v14

Hi, On 03/26/2016 10:18 AM, Tatsuo Ishii wrote: Fair point. Attached is v18 of the patch, after pgindent cleanup. Here are some feedbacks to v18 patch. 1) regarding examples in create_statistics manual Here are numbers I got. "with statistics" referrers to the case where multivariate

Re: [HACKERS] Draft release notes for next week's releases

On Mon, Mar 28, 2016 at 12:55 AM, Oleg Bartunov wrote: > We'll post the patch. Cool. > Teodor made something to get abbreviated keys work as > I remember. I should say, that 27x improvement I got on my macbook. I will > check on linux. I think that Linux will be much

Re: [HACKERS] Draft release notes for next week's releases

On Mon, Mar 28, 2016 at 1:21 PM, Peter Geoghegan wrote: > On Mon, Mar 28, 2016 at 12:08 AM, Oleg Bartunov > wrote: > > Should we start thinking about ICU ? I compare Postgres with ICU and > without > > and found 27x improvement in btree index creation for

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Sun, Mar 27, 2016 at 7:30 AM, Thomas Munro wrote: > On Sat, Mar 26, 2016 at 2:48 AM, Michael Paquier > wrote: >> Should we worried about potential backward-incompatibilities with the >> new return values of walrcv_receive? > > There

Re: [HACKERS] pg_xlogdump fails to handle WAL file with multi-page XLP_FIRST_IS_CONTRECORD data

On Wed, Mar 23, 2016 at 6:16 PM, Michael Paquier wrote: > > > I'd just add dots at the end of the sentences in the comment blocks > because that's project style, but I'm being picky, except that the > logic looks quite good. > Since this is a bug affecting all stable

[HACKERS] pgbench - remove unused clientDone parameter

Remove pgbench clientDone unused "ok" parameter. I cannot get the point of keeping a useless parameter, which is probably there because at some point in the past it was used. If it is needed some day it can always be reinserted. -- Fabien.diff --git a/src/bin/pgbench/pgbench.c

[HACKERS] pgbench - show weight percent

This minor patch shows the expected drawing percent in multi-script reports, next to the relative weight. -- Fabiendiff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c index 4196b0e..3b63d69 100644 --- a/src/bin/pgbench/pgbench.c +++ b/src/bin/pgbench/pgbench.c @@ -3080,10

Re: [HACKERS] pgbench stats per script & other stuff

- that it does work:-) I'm not sure what happens by the script selection process, it should be checked carefully because it was not designed with allowing a zero weight, and it may depend on its/their positions. It may already work, but it really needs checking. Hmmm, it seems ok.

Re: [HACKERS] Draft release notes for next week's releases

On Mon, Mar 28, 2016 at 12:08 AM, Oleg Bartunov wrote: > Should we start thinking about ICU ? I compare Postgres with ICU and without > and found 27x improvement in btree index creation for russian strings. This > includes effect of abbreviated keys and ICU itself. Also,

Re: [HACKERS] Draft release notes for next week's releases

On Mar 28, 2016 09:44, "Peter Geoghegan" wrote: > > On Sat, Mar 26, 2016 at 4:34 PM, Tom Lane wrote: > > Probably the most discussion-worthy item is whether we can say > > anything more about the strxfrm mess. Should we make a wiki > > page about that and

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Fri, Mar 25, 2016 at 9:20 PM, Robert Haas wrote: > On Thu, Mar 24, 2016 at 9:29 AM, Masahiko Sawada > wrote: >> Also I felt a sense of discomfort regarding using [ and ] as a special >> character for priority method. >> Because (, ) and [, ] are

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Sun, Mar 27, 2016 at 5:48 PM, Andres Freund wrote: > > What's sizeof(BufferDesc) after applying these patches? It should better > be <= 64... > It is 72. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com

Re: [HACKERS] Relation extension scalability

On Mon, Mar 28, 2016 at 11:00 AM, Amit Kapila wrote: > I have not debugged the flow, but by looking at v13 code, it looks like it > will search both old and new. In > function > GetPageWithFreeSpaceExtended()->fsm_search_from_addr()->fsm_search_avail(), > the basic

  1   2   >