Re: [HACKERS] extend pgbench expressions with functions

OK, so I had an extra look at this patch and I am marking it as ready for committer. Ok. Attached is a rebase after recent changes in pgbench code & doc. -- Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index 42d0667..d42208a 100644 --- a/doc/src/sgml/ref

Re: [HACKERS] Patch: ResourceOwner optimization for tables with many partitions

Hello, Tom. I'm a bit concerned regarding assumption that sizeof int never exceeds 4 bytes. While this could be true today for most C compilers, standard [1][2] doesn't guarantee that. Perhaps we should add something like: StaticAssertStmt(sizeof(int) <= sizeof(int32), "int size exceeds int32

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

Hello Alvaro, I'm not really sure about the fact that we operate on those Stats structs without locking. I see upthread you convinced Michael that it was okay, but is it really? How severe is the damage if two threads happen to collide? For stats shared among threads, when it occurs one dat

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

Hello again, If you want to implement real non-ambiguous-prefix code (i.e. have "se" for "select-only", but reject "s" as ambiguous) be my guest. I'm fine with filtering out ambiguous cases (i.e. just the "s" case). Attached a small patch for that. -- Fabien.diff --git a/doc/src/sgml/ref/p

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On 2016/01/27 12:20, Etsuro Fujita wrote: On 2016/01/26 22:57, Rushabh Lathia wrote: On Tue, Jan 26, 2016 at 4:15 PM, Etsuro Fujita mailto:fujita.ets...@lab.ntt.co.jp>> wrote: On 2016/01/25 17:03, Rushabh Lathia wrote: int IsForeignRelUpdatable (Relation rel);

Re: [HACKERS] GIN pending list clean up exposure to SQL

On Mon, Jan 25, 2016 at 3:54 PM, Jeff Janes wrote: > On Wed, Jan 20, 2016 at 6:17 AM, Fujii Masao wrote: >> On Sat, Jan 16, 2016 at 7:42 AM, Julien Rouhaud >> wrote: >>> On 15/01/2016 22:59, Jeff Janes wrote: On Sun, Jan 10, 2016 at 4:24 AM, Julien Rouhaud wrote: >>> >>> All looks fin

Re: [HACKERS] WIP: Failover Slots

Hi all Here's v3 of failover slots. It doesn't add the UI yet, but it's now functionally complete except for timeline following for logical slots, and I have a plan for that. From 533a9327b54ba744b0a1fb0048e8cfe7d3d45ea1 Mon Sep 17 00:00:00 2001 From: Craig Ringer Date: Wed, 20 Jan 2016 17:16:29

[HACKERS] Mac OS: invalid byte sequence for encoding "UTF8"

Hello. When a user try to create a text search dictionary for the russian language on Mac OS then called the following error message: CREATE EXTENSION hunspell_ru_ru; + ERROR: invalid byte sequence for encoding "UTF8": 0xd1 + CONTEXT: line 341 of configuration file "/Users/stas/code/postg

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

Hello again, Here's part b rebased, pgindented and with some minor additional tweaks (mostly function commands and the function renames I mentioned). Patch looks ok to me, various tests where ok as well. Still concerned about the unlocked stat accums. See my arguments in other mail. I can

[HACKERS] Trivial doc fix in logicaldecoding.sgml

Hi, Please find attached a simple copy-paste fix for CREATE_REPLICATION_SLOT syntax. -- Alex From 05119485a473febe8ffd95103fd7774bc31ee079 Mon Sep 17 00:00:00 2001 From: Oleksandr Shulgin Date: Wed, 27 Jan 2016 11:27:35 +0100 Subject: [PATCH] Fix CREATE_REPLICATION_SLOT syntax in logicaldecoding

Re: [HACKERS] Mac OS: invalid byte sequence for encoding "UTF8"

On Wed, Jan 27, 2016 at 10:59 AM, Artur Zakirov wrote: > Hello. > > When a user try to create a text search dictionary for the russian > language on Mac OS then called the following error message: > > CREATE EXTENSION hunspell_ru_ru; > + ERROR: invalid byte sequence for encoding "UTF8": 0xd1 >

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

Fabien COELHO wrote: > >It seems a bit funny to have the start_time not be reset when 0.0 is > >passed, which is almost all the callers. Using a float as a boolean > >looks pretty odd; is that kosher? Maybe it'd be a good idea to have a > >separate boolean flag instead? > Obviously this would w

[HACKERS] Minor improvement to fdwhandler.sgml

Here is a small patch to do s/for/For/ to two section titles in fdwhandlers.sgml, for consistency. Best regards, Etsuro Fujita diff --git a/doc/src/sgml/fdwhandler.sgml b/doc/src/sgml/fdwhandler.sgml index dc2d890..9c8406c 100644 --- a/doc/src/sgml/fdwhandler.sgml +++ b/doc/src/sgml/fdwhandler.sgm

Re: [HACKERS] Mac OS: invalid byte sequence for encoding "UTF8"

On 27.01.2016 13:46, Shulgin, Oleksandr wrote: Not sure why the file uses "SET KOI8-R" directive then? This directive is used only by Hunspell program. PostgreSQL ignores this directive and assumes that input affix and dictionary files in the UTF-8 encoding. What error message do you g

[HACKERS] Fwd: [DOCS] pgbench doc typos

Two trivial changes to doc/src/sgml/ref/pgbench.sgml Erik Rijkers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Mac OS: invalid byte sequence for encoding "UTF8"

Hi. I tried that and confirm strange behaviour. It seems that problem with small cyrillic letter ‘х’. (simplest obscene language filter? =) That can be reproduced with simpler test Stas test.c Description: Binary data > On 27 Jan 2016, at 13:59, Artur Zakirov wrote: > > On 27.01.2016 13

Re: [HACKERS] Fwd: [DOCS] pgbench doc typos

On 2016-01-27 11:06, Erik Rijkers wrote: Two trivial changes to doc/src/sgml/ref/pgbench.sgml Sorry - now attached. Erik Rijkers --- ./doc/src/sgml/ref/pgbench.sgml.orig 2016-01-27 12:29:16.857488633 +0100 +++ ./doc/src/sgml/ref/pgbench.sgml 2016-01-27 12:30:09.643862616 +0100 @@ -1056,7 +10

[HACKERS] Using user mapping OID as hash key for connection hash

Hi All, As discussed in postgres_fdw join pushdown thread [1], for two different effective local users which use public user mapping we will be creating two different connections to the foreign server with the same credentials. Robert suggested [2] that we should use user mapping OID as the connec

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

> > This patch affects header files. By any chance didn't you forget to > > run `make clean` after applying it? As we discussed above, when you > > change .h files autotools doesn't rebuild dependent .c files: > > > > Yes, actually i always compile using "make clean;make -j20; make > install" If y

Re: [HACKERS] [PATCH] better systemd integration

Hi 2015-11-17 15:08 GMT+01:00 Peter Eisentraut : > I have written a couple of patches to improve the integration of the > postgres daemon with systemd. > > The setup that is shipped with Red Hat- and Debian-family packages at > the moment is just an imitation of the old shell scripts, relying on

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On Wed, Jan 27, 2016 at 2:50 PM, Etsuro Fujita wrote: > On 2016/01/27 12:20, Etsuro Fujita wrote: > >> On 2016/01/26 22:57, Rushabh Lathia wrote: >> >>> On Tue, Jan 26, 2016 at 4:15 PM, Etsuro Fujita >>> mailto:fujita.ets...@lab.ntt.co.jp>> >>> wrote: >>> >>> On 2016/01/25 17:03, Rushabh Lath

Re: [HACKERS] Mac OS: invalid byte sequence for encoding "UTF8"

On 27.01.2016 14:14, Stas Kelvich wrote: Hi. I tried that and confirm strange behaviour. It seems that problem with small cyrillic letter ‘х’. (simplest obscene language filter? =) That can be reproduced with simpler test Stas The test program was corrected. Now it uses wchar_t type. And

Re: [HACKERS] Proposal:Use PGDLLEXPORT for libpq

Craig Ringer wrote: On 27 January 2016 at 00:16, Yury Zhuravlev wrote: It says more about the modules, and not about libpq. Using gendef.pl for this library in the light of the development of my CMake build seems silly. For what it's worth I personally agree. I'd rather have PGDLLEXPORT

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On 26.01.2016 13:53, Michael Paquier wrote: Imagine for example a script that in some rare cases passes happens to pass infinity into generate_series() - in that case I'd much rather error out than wait till the end of the universe. So +1 from me to checking for infinity. +1 ERROR infinite

Re: [HACKERS] Proposal:Use PGDLLEXPORT for libpq

On Wed, Jan 27, 2016 at 9:30 PM, Yury Zhuravlev wrote: > What's the point now support the MSVC? Many companies use it, including mine, and likely EDB. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.or

Re: [HACKERS] Proposal:Use PGDLLEXPORT for libpq

Yury Zhuravlev wrote: > If so many problems with MSVC can discard his support of Postgres? That doesn't sound likely. Keep in mind that users might want to compile extension modules, and not everyone is going to use mingw for that. As far as I know, stuff compiled with MSVC is not compatible wi

Re: [HACKERS] Proposal:Use PGDLLEXPORT for libpq

On 27 January 2016 at 20:54, Alvaro Herrera wrote: > > If so many problems with MSVC can discard his support of Postgres? > I strongly disagree. MSVC is a high quality compiler and the primary tool for the platform. Yes, it's behind on standards support and that's annoying - OTOH MinGW relies

Re: [HACKERS] Proposal:Use PGDLLEXPORT for libpq

On 2016-01-27 21:05:06 +0800, Craig Ringer wrote: > On 27 January 2016 at 20:54, Alvaro Herrera > wrote: > > > If so many problems with MSVC can discard his support of Postgres? > I strongly disagree. MSVC is a high quality compiler and the primary tool > for the platform. I think it's pretty

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

On Wed, Dec 23, 2015 at 9:37 AM, Robert Haas wrote: >> But yes, let me concede more clearly: the cost model is based on >> frobbing. But at least it's relatively honest about that, and is >> relatively simple. I think it might be possible to make it simpler, >> but I have a feeling that anything w

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

22.01.2016 13:48, Aleksander Alekseev: Then, this thread became too tangled. I think it's worth to write a new message with the patch, the test script, some results and brief overview of how does it really works. It will make following review much easier. Sure. HASHHDR represents a hash table

[HACKERS] WAL Re-Writes

As discussed previously about WAL Re-Writes [1], I have done some investigation in that area which I would like to share. Currently we always write WAL in 8KB blocks, which could lead to a lot of re-write of data for small-transactions. Consider the case where the amount to be written is usually

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

> This comment certainly requires some changes. Fixed. > BTW, could you explain why init_table_size was two times less than > max_table_size? I have no clue. My best guess is that it was a reasonable thing to do in the past. Then somebody changed a code and now there is little reason to use ini

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

Hello again, Obviously this would work. I did not think the special case was worth the extra argument. This one has some oddity too, because the second argument is ignored depending on the third. Do as you feel. Actually my question was whether keeping the original start_time was the intended

Re: [HACKERS] insert/update performance

> > But what kind of rows would satisfy heap_page_prune() and what would not? > > In my case all updates are doing the same thing (there is no HOT > updates, obviously), but why some updated rows are reported by > heap_page_prune() but the others are not? And it's also a random > issue. That means

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

On Wed, Jan 27, 2016 at 5:15 PM, Aleksander Alekseev < a.aleks...@postgrespro.ru> wrote: > Most likely HASHHDR.mutex is not only bottleneck in your case so my > patch doesn't help much. Unfortunately I don't have access to any > POWER8 server so I can't investigate this issue. I suggest to use a >

Re: [HACKERS] Why format() adds double quote?

Tatsuo Ishii wrote: > 2) What does the SQL standard say? Do they say that non ASCII white > spaces should be treated as ASCII white spaces? I've used white space in the example, but I'm concerned about punctuation too. unicode.org has this helpful paper: http://www.unicode.org/L2/L2000

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Hi > > > I though about it lot of, and I see a the core of problems in orthogonal > > constructed exceptions in Python and Postgres. We working with statements > > elog, ereport, RAISE EXCEPTION - and these statements are much more like > > templates - can generate any possible exception. Python

Re: [HACKERS] Existence check for suitable index in advance when concurrently refreshing.

On Wed, Jan 27, 2016 at 4:42 PM, Fujii Masao wrote: > On Tue, Jan 26, 2016 at 9:33 PM, Masahiko Sawada > wrote: >> Hi all, >> >> In concurrently refreshing materialized view, we check whether that >> materialized view has suitable index(unique and not having WHERE >> condition), after filling da

Re: [HACKERS] Why format() adds double quote?

Tatsuo Ishii wrote: > What is the "visual hint"? If you are talking about psql's output, it > never adds "visual hint" (double quotations). > > If you are talking about the string handling in a program, what kind > of program cares about "visiual"? Sure. The scenario I'm thinking abo

[HACKERS] Implementing a new Scripting Language

Hi all, We have an open source scripting engine named Lucee that is used primarily for web application -- https://github.com/lucee/Lucee -- it is written in Java and is usually run as a servlet, but can be accessed in other ways (like JSR-223). You can think of the language as a combination

Re: [HACKERS] Tsvector editing functions

Hi > On 22 Jan 2016, at 19:03, Tomas Vondra wrote: > OK, although I do recommend using more sensible variable names, i.e. why how > to use 'lexemes' instead of 'lexarr' for example? Similarly for the other > functions. Changed. With old names I tried to follow conventions in surrounding code,

Re: [HACKERS] Implementing a new Scripting Language

Why do you want that at the database level? Do you have end-to-end scenario that benefits from using Lucee? >I was wondering how difficult it would be to implement a Postgres extension >that will act as a wrapper around it and will allow to write functions in that >language? Have you checked PL

Re: [HACKERS] Implementing a new Scripting Language

On 1/27/2016 8:40 AM, Vladimir Sitnikov wrote: Why do you want that at the database level? Do you have end-to-end scenario that benefits from using Lucee? Lucee is very intuitive and powerful, so it's more for ease of use than anything, and to attract more Lucee users to use PostgreSQL (most of

Re: [HACKERS] Why format() adds double quote?

"Daniel Verite" writes: > This boils down to the fact that the current quote_ident gives: > =# select quote_ident('test․table'); > quote_ident > -- > "test․table" > whereas the quote_ident patched as proposed gives: > =# select quote_ident('test․table'); > quote_ident >

Re: [HACKERS] Log operating system user connecting via unix socket

Hi again. About the privileges, our support can create roles / databases, drop existing databases, dump /restore, change other users passwords. It's not feasible right now create a 1:1 map of system users and postgres users. Maybe in the future. I wrote 2 possible patches, both issuing a detail m

Re: [HACKERS] Implementing a new Scripting Language

> If the pl/v8 was easily ported to Windows then I probably wouldn't even try > to add Lucee, That is a good question. ChakraCore has been open sourced recently. It might be easier to build under Windows. >That seems like a good place to start, thanks I am not sure you would be able to bind high

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Hi 2016-01-18 21:37 GMT+01:00 Alvaro Herrera : > > diff --git a/src/pl/plpgsql/src/pl_comp.c b/src/pl/plpgsql/src/pl_comp.c > > new file mode 100644 > > index 1ae4bb7..c819517 > > *** a/src/pl/plpgsql/src/pl_comp.c > > --- b/src/pl/plpgsql/src/pl_comp.c > > *** plpgsql_parse_tripword(

Re: [HACKERS] Implementing a new Scripting Language

On 01/27/2016 11:46 AM, Igal @ Lucee.org wrote: >> Have you checked PL/Java? > That seems like a good place to start, thanks. Are there also any docs > about the subject? I just did a quick search on Lucee and what I found suggests that it compiles to JVM bytecode and runs on a JVM. If that is t

Re: [HACKERS] Implementing a new Scripting Language

On 1/27/2016 9:58 AM, jflack wrote: I just did a quick search on Lucee and what I found suggests that it compiles to JVM bytecode and runs on a JVM. If that is the case, and it can compile methods that will have the sort of method signatures PL/Java expects, and you can put the .class files in a

Re: [HACKERS] Implementing a new Scripting Language

On 1/27/2016 9:57 AM, Vladimir Sitnikov wrote: That is a good question. ChakraCore has been open sourced recently. It might be easier to build under Windows. interesting. but now we will need to write an extension for that, e.g. PL/Chakra, which brings back my original question: are there any

Re: [HACKERS] Log operating system user connecting via unix socket

José, * José Arthur Benetasso Villanova (jose.art...@gmail.com) wrote: > I wrote 2 possible patches, both issuing a detail message only if > log_connections is enabled. > > The first one using the Stephen Frost suggestion, inside the Port struct (I > guess that this is the one, I coudn't find the

Re: [HACKERS] Implementing a new Scripting Language

2016-01-27 19:21 GMT+01:00 Igal @ Lucee.org : > On 1/27/2016 9:57 AM, Vladimir Sitnikov wrote: > >> That is a good question. ChakraCore has been open sourced recently. It >> might be easier to build under Windows. >> > interesting. but now we will need to write an extension for that, e.g. > PL/Ch

Re: [HACKERS] Implementing a new Scripting Language

2016-01-27 19:37 GMT+01:00 Pavel Stehule : > > > 2016-01-27 19:21 GMT+01:00 Igal @ Lucee.org : > >> On 1/27/2016 9:57 AM, Vladimir Sitnikov wrote: >> >>> That is a good question. ChakraCore has been open sourced recently. It >>> might be easier to build under Windows. >>> >> interesting. but now

Re: [HACKERS] Implementing a new Scripting Language

On 1/27/2016 10:41 AM, Pavel Stehule wrote: 2016-01-27 19:37 GMT+01:00 Pavel Stehule >: David Fetter wrote some presentation - some years ago was popular to write own PL me too https://wiki.postgresql.org/images/a/a2/Plpgsql_internals.pdf

Re: [HACKERS] Implementing a new Scripting Language

On 01/27/2016 01:17 PM, Igal @ Lucee.org wrote: > the next version of Lucee (currently in Beta) does support JSR-223, > which I actually mentioned as a viable solution in my first email in Sorry, I jumped in late. > this thread. That would be awesome if PL/Java would support JSR-223. Ok, if yo

Re: [HACKERS] Implementing a new Scripting Language

On 1/27/2016 10:48 AM, Chapman Flack wrote: Ok, if your 233 support is already in beta, you'll get there before we do, but the paths should intersect eventually. :) Actually, once your support for JSR-223 is implemented (it's two-twenty-three, not thirty ;)), we will be able to use Javascript

[HACKERS] pgbench small bug fix

While testing for something else I encountered two small bugs under very low rate (--rate=0.1). The attached patches fixes these. - when a duration (-T) is specified, ensure that pgbench ends at that time (i.e. do not wait for a transaction beyond the end of the run). - when there is a p

Re: [HACKERS] [Proposal] Table partition + join pushdown

On Mon, Jan 25, 2016 at 9:09 PM, Kouhei Kaigai wrote: > Of course, its implementation is not graceful enough, especially, above > point because this extra filter will change expected number of rows to > be produced by inner relation, and relevant cost. > Right now, his patch calls cost_seqscan() a

Re: [HACKERS] Implementing a new Scripting Language

On 01/27/2016 02:06 PM, Igal @ Lucee.org wrote: > two-twenty-three, not thirty ;)), Thanks. :) On occasions in the past I have written it correctly ... there is evidence in the archives > we will be able to use Javascript > through that via the Nashorn project, Yes, that's an attraction f

Re: [HACKERS] WAL Re-Writes

On 27/01/2016 13:30, Amit Kapila wrote: Thoughts? Are the decreases observed with SSD as well as spinning rust? I might imagine that decreasing the wear would be advantageous, especially if the performance decrease is less with low read latency. -- Sent via pgsql-hackers mailing list (p

Re: [HACKERS] Batch update of indexes

On Wed, Jan 20, 2016 at 4:28 AM, Konstantin Knizhnik wrote: > Please notice that such alter table statement, changing condition for > partial index, is not supported now. > But I do not see any principle problems with supporting such construction. > We should just include in the index all records

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Tue, Jan 26, 2016 at 3:10 AM, and...@anarazel.de wrote: > I do think there's a considerable benefit in improving the > instrumentation here, but his strikes me as making live more complex for > more users than it makes it easier. At the very least this should be > split into two fields (type &

Re: [HACKERS] GIN pending list clean up exposure to SQL

On 27/01/2016 10:27, Fujii Masao wrote: > On Mon, Jan 25, 2016 at 3:54 PM, Jeff Janes > wrote: >> On Wed, Jan 20, 2016 at 6:17 AM, Fujii Masao >> wrote: >>> On Sat, Jan 16, 2016 at 7:42 AM, Julien Rouhaud >>> wrote: On 15/01/2016 22:59, Jeff Janes wrote: > On Sun, Jan 10, 2016 at 4:24

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On Tue, Jan 26, 2016 at 11:37 PM, Vinayak Pokale wrote: > Hi, > > Please find attached updated patch with an updated interface. Well, this isn't right. You've got this sort of thing: +scanned_index_pages += RelationGetNumberOfBlocks(Irel[i]); +/* Report progress to the s

Re: [HACKERS] CustomScan under the Gather node?

On Tue, Jan 26, 2016 at 1:30 AM, Kouhei Kaigai wrote: > What enhancement will be necessary to implement similar feature of > partial seq-scan using custom-scan interface? > > It seems to me callbacks on the three points below are needed. > * ExecParallelEstimate > * ExecParallelInitializeDSM > * E

Re: [HACKERS] Interesting read on SCM upending software and hardware architecture

W dniu 18.01.2016, pon o godzinie 18∶55 -0600, użytkownik Jim Nasby napisał: [ cut ] >  > My original article doesn't talk about SSDs; it's talking about  > non-volatile memory architectures (quoted extract below). Fusion IO > is  > an example of this, and if NVDIMMs become available we'll see even

Re: [HACKERS] extend pgbench expressions with functions

On Sat, Jan 16, 2016 at 1:10 PM, Fabien COELHO wrote: > All these results are fine from my point of view. > >> And this one generates a core dump: >> \set cid debug(-9223372036854775808 / -1) >> Floating point exception: 8 (core dumped) That does not seem acceptable to me. I don't want pgbench t

Re: [HACKERS] Implementing a new Scripting Language

On 1/27/2016 11:47 AM, Chapman Flack wrote: Thanks. :) On occasions in the past I have written it correctly ... there is evidence in the archives I believe that! I actually never remember if it's 223 or 233 and I always google it before I post, so in a way I cheated ;) we will be able

Re: [HACKERS] extend pgbench expressions with functions

On Wed, Jan 27, 2016 at 3:39 AM, Fabien COELHO wrote: > Attached is a rebase after recent changes in pgbench code & doc. +/* use short names in the evaluator */ +#define INT(v) coerceToInt(&v) +#define DOUBLE(v) coerceToDouble(&v) +#define SET_INT(pv, ival) setIntValue(pv, ival) +#define SET_DOUB

Re: [HACKERS] Patch: ResourceOwner optimization for tables with many partitions

On Wed, Jan 27, 2016 at 3:57 AM, Aleksander Alekseev wrote: > I'm a bit concerned regarding assumption that sizeof int never exceeds 4 > bytes. While this could be true today for most C compilers, standard > [1][2] doesn't guarantee that. Perhaps we should add something like: > > StaticAssertStmt(

Re: [HACKERS] extend pgbench expressions with functions

Hello Robert, And this one generates a core dump: \set cid debug(-9223372036854775808 / -1) Floating point exception: 8 (core dumped) That does not seem acceptable to me. I don't want pgbench to die a horrible death if a floating point exception occurs any more than I want the server to do

Re: [HACKERS] extend pgbench expressions with functions

Hello Robert, Attached is a rebase after recent changes in pgbench code & doc. +/* use short names in the evaluator */ +#define INT(v) coerceToInt(&v) +#define DOUBLE(v) coerceToDouble(&v) +#define SET_INT(pv, ival) setIntValue(pv, ival) +#define SET_DOUBLE(pv, dval) setDoubleValue(pv, dval)

Re: [HACKERS] Why format() adds double quote?

2016-01-26 23:40 GMT-02:00 Tatsuo Ishii : >> Thanks for advocate, I see here that it even produces that output with >> simple spaces. >> >> postgres=# create table x ("aí " text); >> CREATE TABLE >> postgres=# \d x >> Tabela "public.x" >> Coluna | Tipo | Modificadores >> --+

Re: [HACKERS] Why format() adds double quote?

> I've used white space in the example, but I'm concerned about > punctuation too. > > unicode.org has this helpful paper: > http://www.unicode.org/L2/L2000/00260-sql.pdf > which studies Unicode in SQL-99 identifiers. > > The relevant BNF they extracted from the standard looks like this: > > ide

Re: [HACKERS] [PATCH] we have added support for box type in SP-GiST index

Alexander Lebedev wrote: > Hello, Hacker. > > * [PATCH] add a box index to sp-gist I closed this patch as "returned with feedback" because the author didn't reply in three months. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Trai

Re: [HACKERS] Why format() adds double quote?

> "Daniel Verite" writes: >> This boils down to the fact that the current quote_ident gives: > >> =# select quote_ident('test․table'); >> quote_ident >> -- >> "test․table" > >> whereas the quote_ident patched as proposed gives: > >> =# select quote_ident('test․table'); >> quote

Re: [HACKERS] extend pgbench expressions with functions

On Thu, Jan 28, 2016 at 7:07 AM, Fabien COELHO wrote: > I do not think that it is really worth fixing, but I will not prevent anyone > to fix it. I still think it does. Well, if there is consensus to address this one and optionally the other integer overflows even on back branches, I'll write a p

Re: [HACKERS] Add numeric_trim(numeric)

Marko Tiikkaja wrote: > Hi, > > Here's a patch for the second function suggested in 5643125e.1030...@joh.to. I think this patch got useful feedback but we never saw a followup version posted. I closed it as returned-with-feedback. Feel free to submit a new version for the 2016-03 commitfest. -

Re: [HACKERS] CustomScan under the Gather node?

> On Tue, Jan 26, 2016 at 1:30 AM, Kouhei Kaigai wrote: > > What enhancement will be necessary to implement similar feature of > > partial seq-scan using custom-scan interface? > > > > It seems to me callbacks on the three points below are needed. > > * ExecParallelEstimate > > * ExecParallelIniti

Re: [HACKERS] [PoC] Asynchronous execution again (which is not parallel)

On Thu, Jan 21, 2016 at 4:26 AM, Kyotaro HORIGUCHI wrote: > I put some consideration and trial on callbacks as a means to > async(early)-execution. Thanks for working on this. >> > Suppose we equip each EState with the ability to fire "callbacks". >> > Callbacks have the signature: >> > >> > typ

Re: [HACKERS] remove wal_level archive

On 1/26/16 10:56 AM, Simon Riggs wrote: > Removing one of "archive" or "hot standby" will just cause confusion and > breakage, so neither is a good choice for removal. I'm pretty sure nothing would break, but I do agree that it could be confusing. > What we should do is > 1. Map "archive" and "h

Re: [HACKERS] remove wal_level archive

On Thu, Jan 28, 2016 at 10:53 AM, Peter Eisentraut wrote: > On 1/26/16 10:56 AM, Simon Riggs wrote: >> What we should do is >> 1. Map "archive" and "hot_standby" to one level with a new name that >> indicates that it can be used for both/either backup or replication. >> (My suggested name fo

Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan support on readfuncs.c)

On Mon, Jan 25, 2016 at 8:06 PM, Kouhei Kaigai wrote: > Sorry for my late response. I've been unavailable to have enough > time to touch code for the last 1.5 month. > > The attached patch is a revised one to handle private data of > foregn/custom scan node more gracefully. > > The overall consens

Re: [HACKERS] [POC] FETCH limited by bytes.

On Mon, Jan 25, 2016 at 4:18 PM, Corey Huinker wrote: > Revised in patch v3: > * get_option() and get_fetch_size() removed, fetch_size searches added to > existing loops. > * Move fetch_size <= 0 tests into postgres_fdw_validator() routine in > option.c > * DEBUG1 message removed, never intended t

Re: [HACKERS] Set search_path + server-prepared statements = cached plan must not change result type

On Mon, Jan 25, 2016 at 2:11 PM, Vladimir Sitnikov wrote: > I want to treat 'prepare' operation as an optimization step, so it is > functionally equivalent to sending a query text. > > In other words, I would like backend to track search_path and other > parameters if necessary transparently‎, c

Re: [HACKERS] Combining Aggregates

On Sat, Jan 23, 2016 at 6:26 PM, Jeff Janes wrote: > On Fri, Jan 22, 2016 at 4:53 PM, David Rowley > wrote: >> >> It seems that I must have mistakenly believed that non-existing >> columns for previous versions were handled using the power of magic. >> Turns out that I was wrong, and they need to

Re: [HACKERS] [PATCH] better systemd integration

On 1/27/16 7:02 AM, Pavel Stehule wrote: > The issues: > > 1. configure missing systemd integration test, compilation fails: > > postmaster.o postmaster.c > postmaster.c:91:31: fatal error: systemd/sd-daemon.h: No such file or > directory Updated patch attached that fixes this by adding addition

Re: [HACKERS] Implementing a new Scripting Language

On 01/27/16 16:31, Igal @ Lucee.org wrote: > This can be a major thing. I will open a ticket in > https://github.com/tada/pljava -- or is it already on the roadmap? Now that you mention it, it isn't officially in a ticket. Though it's not like I was going to forget. :) I can guarantee it won't

Re: [HACKERS] Minor code improvements to create_foreignscan_plan/ExecInitForeignScan

On Thu, Jan 21, 2016 at 5:55 AM, Etsuro Fujita wrote: > On 2016/01/21 7:04, Alvaro Herrera wrote: >> Etsuro Fujita wrote: >>> >>> On second thought, I noticed that detecting whether we see a system >>> column >>> that way needs more cycles in cases where the reltargetlist and the >>> restriction c

Re: [HACKERS] Set search_path + server-prepared statements = cached plan must not change result type

On Monday, January 25, 2016, Vladimir Sitnikov wrote: > I want to treat 'prepare' operation as an optimization step, so it is > functionally equivalent to sending a query text. > > In other words, I would like backend to track search_path and other > parameters if necessary transparently‎, creati

Re: [HACKERS] Implementing a new Scripting Language

On 1/27/2016 7:12 PM, Chapman Flack wrote: Now that you mention it, it isn't officially in a ticket. Though it's not like I was going to forget. :) I can guarantee it won't be in 1.5... Speaking of tickets, I should probably make actual tickets, for after 1.5.0, out of all the items now showin

Re: [HACKERS] Fwd: Core dump with nested CREATE TEMP TABLE

On Sun, Jan 03, 2016 at 12:35:56AM -0500, Noah Misch wrote: > On Sat, Jan 02, 2016 at 07:22:13PM -0500, Tom Lane wrote: > > Noah Misch writes: > > > I am inclined to add an Assert(portal->status != PORTAL_ACTIVE) to > > > emphasize > > > that this is backup only. MarkPortalActive() callers remai

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Thu, Jan 28, 2016 at 2:12 AM, Robert Haas wrote: > > On Tue, Jan 26, 2016 at 3:10 AM, and...@anarazel.de wrote: > > I do think there's a considerable benefit in improving the > > instrumentation here, but his strikes me as making live more complex for > > more users than it makes it easier. At

Re: [HACKERS] Fwd: Core dump with nested CREATE TEMP TABLE

On Thu, Jan 28, 2016 at 12:40 PM, Noah Misch wrote: > On Sun, Jan 03, 2016 at 12:35:56AM -0500, Noah Misch wrote: >> On Sat, Jan 02, 2016 at 07:22:13PM -0500, Tom Lane wrote: >> > Noah Misch writes: >> > > I am inclined to add an Assert(portal->status != PORTAL_ACTIVE) to >> > > emphasize >> > >

Re: Odd behavior in foreign table modification (Was: Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW)

On Thu, Jan 21, 2016 at 4:05 AM, Etsuro Fujita wrote: >> By the way, I'm not too sure I understand the need for the core >> changes that are part of this patch, and I think that point merits >> some discussion. Whenever you change core like this, you're changing >> the contract between the FDW an

Re: [HACKERS] GIN pending list clean up exposure to SQL

On Thu, Jan 28, 2016 at 5:54 AM, Julien Rouhaud wrote: > On 27/01/2016 10:27, Fujii Masao wrote: >> On Mon, Jan 25, 2016 at 3:54 PM, Jeff Janes >> wrote: >>> On Wed, Jan 20, 2016 at 6:17 AM, Fujii Masao >>> wrote: On Sat, Jan 16, 2016 at 7:42 AM, Julien Rouhaud wrote: > On 15/01/2

Re: [HACKERS] checkpointer continuous flushing

On Wed, Jan 20, 2016 at 9:02 AM, Andres Freund wrote: > Chatting on IM with Heikki, I noticed that we're pretty pessimistic in > SetHintBits(). Namely we don't set the bit if XLogNeedsFlush(commitLSN), > because we can't easily set the LSN. But, it's actually fairly common > that the pages LSN is

Re: [HACKERS] Fwd: Core dump with nested CREATE TEMP TABLE

On Wed, Jan 27, 2016 at 10:40 PM, Noah Misch wrote: > On Sun, Jan 03, 2016 at 12:35:56AM -0500, Noah Misch wrote: >> On Sat, Jan 02, 2016 at 07:22:13PM -0500, Tom Lane wrote: >> > Noah Misch writes: >> > > I am inclined to add an Assert(portal->status != PORTAL_ACTIVE) to >> > > emphasize >> > >

Re: [HACKERS] Implementing a new Scripting Language

On 01/27/16 22:26, Igal @ Lucee.org wrote: > If I can help with anything with the pl/Java project I'd love to help. Man, you do NOT know what you just walked into. :D The most imminent thing I see happening is s/1.5.0-SNAPSHOT/1.5.0-BETA1 which is not far off, so testing is always good. Maybe a

Re: [HACKERS] extend pgbench expressions with functions

On Wed, Jan 27, 2016 at 5:43 PM, Fabien COELHO wrote: > Pgbench is a bench tool, not a production tool. I don't really see how that's relevant. When I run a program and it dies after causing the operating system to send it a fatal signal, I say to myself "self, that program has a bug". Other pe

  1   2   >