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

On 11.02.2016 01:19, Tom Lane wrote: I wrote: Artur Zakirov writes: I think this is not a bug. It is a normal behavior. In Mac OS sscanf() with the %s format reads the string one character at a time. The size of letter 'Ñ…' is 2. And sscanf() separate it into two

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

On Thu, Feb 11, 2016 at 5:20 PM, Andres Freund wrote: > On 2016-02-11 09:25:30 +0530, Amit Kapila wrote: >> On Wed, Feb 10, 2016 at 1:42 PM, Michael Paquier >> wrote: >> > >> > On Wed, Feb 10, 2016 at 5:00 PM, Amit Kapila

Re: [HACKERS] custom function for converting human readable sizes to bytes

Hi assigned https://commitfest.postgresql.org/9/514/ Regards Pavel

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

On 2016-02-09 09:27:04 +, Dean Rasheed wrote: > Looking at this patch, I have mixed feelings about it. On the one hand > I really like the look of the output, and I can see that the non-fixed > nature of the output columns makes this hard to achieve server-side. > But on the other hand, this

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

On 2016-02-11 09:25:30 +0530, Amit Kapila wrote: > On Wed, Feb 10, 2016 at 1:42 PM, Michael Paquier > wrote: > > > > On Wed, Feb 10, 2016 at 5:00 PM, Amit Kapila > wrote: > > > Okay, but isn't it better that we remove the snapshot taken > > >

Re: [HACKERS] custom function for converting human readable sizes to bytes

2016-02-11 7:44 GMT+01:00 Vitaly Burovoy : > On 2/10/16, Pavel Stehule wrote: > > Hi Vitaly, > > > > please, can you send your version of this patch, how we talked about it > in > > Moscow? > > > > Thank you > > > > Pavel > > Hello, Pavel! > >

Re: [HACKERS] custom function for converting human readable sizes to bytes

This is last incarnation of my patch (cleaned and refactored by Vitaly Burovoy) -- 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] Speed up Clog Access by increasing CLOG buffers

On Thu, Feb 11, 2016 at 8:02 PM, Robert Haas wrote: > > On the substantive part of the patch, this doesn't look safe: > > +/* > + * Add ourselves to the list of processes needing a group XID status > + * update. > + */ > +proc->clogGroupMember = true; >

Re: [HACKERS] custom function for converting human readable sizes to bytes

Hi 2016-02-12 2:28 GMT+01:00 Vitaly Burovoy : > Hello! > > On 2/11/16, Pavel Stehule wrote: > > Hi > > > > assigned https://commitfest.postgresql.org/9/514/ > > > > Regards > > Pavel > > > This patch was almost done by the end of the previous

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Wed, Feb 10, 2016 at 8:51 PM, Robert Haas wrote: > > On Wed, Feb 10, 2016 at 1:32 AM, Amit Kapila wrote: > > The reason for using centralized way is that we need to request > > named tranches before initialization of shared memory and as far as

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

On 11.02.2016 03:33, Tom Lane wrote: Artur Zakirov writes: [ tsearch_aff_parse_v1.patch ] I've pushed this with some corrections --- notably, I did not like the lack of buffer-overrun prevention, and it did the wrong thing if a line had more than one trailing

Re: [HACKERS] Invalid user-level setting = confusing error message

Thom Brown writes: > At the moment, if we try to set up a configuration parameter for a > user which doesn't make sense in that context, we get an error message > that doesn't really tell us that we're not allowed to set it for > users: > # ALTER ROLE moo SET log_line_prefix =

[HACKERS] Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.

On Thu, Feb 11, 2016 at 9:36 AM, Robert Haas wrote: > On Thu, Feb 11, 2016 at 9:29 AM, Tom Lane wrote: >> Robert Haas writes: >>> Add some isolation tests for deadlock detection and resolution. >> >> Buildfarm says this needs work

Re: [HACKERS] Improved error reporting in format()

Thank you, committed Jim Nasby wrote: On 1/2/16 5:57 PM, Jim Nasby wrote: Attached patch clarifies that %-related error messages with hints as well as (IMHO) improving the clarity of the message: Sorry, forgot to update regression tests. New patch attached. -- Teodor Sigaev

Re: [HACKERS] Fuzzy substring searching with the pg_trgm extension

1 - sml_limit to similarity_limit. sml_threshold is difficult to write I think, similarity_limit is more simple. It seems to me that threshold is right word by meaning. sml_threshold is my choice. 2 - subword_similarity() to word_similarity(). Agree, according to Mike Rylander opinion in

[HACKERS] Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.

On Thu, Feb 11, 2016 at 9:29 AM, Tom Lane wrote: > Robert Haas writes: >> Add some isolation tests for deadlock detection and resolution. > > Buildfarm says this needs work ... > > dromedary is one of mine, do you need me to look into what is >

Re: [HACKERS] Freeze avoidance of very large table.

Thank you for reviewing this patch! On Wed, Feb 10, 2016 at 4:39 PM, Kyotaro HORIGUCHI wrote: > Hello, > > At Thu, 4 Feb 2016 02:32:29 +0900, Masahiko Sawada > wrote in

Re: [HACKERS] GinPageIs* don't actually return a boolean

On Thu, Feb 11, 2016 at 9:15 AM, Andres Freund wrote: > On 2016-02-11 08:50:41 -0500, Robert Haas wrote: >> Are we thinking to back-patch this? I would be disinclined to >> back-patch widespread changes like this. If there's a specific >> instance related to Gin where this

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

On Thu, Feb 11, 2016 at 9:11 AM, Aleksander Alekseev wrote: >> Thanks, this looks way better. Some more comments: >> >> - I don't think there's any good reason for this patch to change the >> calling convention for ShmemInitHash(). Maybe that's a good idea and >>

Re: [HACKERS] GinPageIs* don't actually return a boolean

On 2016-02-11 09:51:26 -0500, Robert Haas wrote: > I have never been quite clear on what you think is going to cause > stdbool.h inclusions to become more common. Primarily because it's finally starting to be supported across the board, thanks to MS finally catching up. Then there's uglyness

Re: [HACKERS] max_parallel_degree context level

On 11 February 2016 at 13:18, Robert Haas wrote: > On Thu, Feb 11, 2016 at 7:40 AM, Thom Brown wrote: >> As it currently stands, max_parallel_degree is set to a superuser >> context > > I don't have a clue why it's like that. It seems like it should be >

Re: [HACKERS] checkpointer continuous flushing - V16

On Thu, Feb 11, 2016 at 1:44 PM, Andres Freund wrote: > On 2016-02-04 16:54:58 +0100, Andres Freund wrote: >> Fabien asked me to post a new version of the checkpoint flushing patch >> series. While this isn't entirely ready for commit, I think we're >> getting closer. >> >> I

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

On Thu, Feb 11, 2016 at 9:53 AM, Robert Haas wrote: > The fact that InitLocks() doesn't do this has been discussed before > and there's no consensus on changing it. It is, at any rate, a > separate issue. I'll go through the rest of this patch again now. I did a little

Re: [HACKERS] [PATCH v4] GSSAPI encryption support

Michael Paquier writes: > On Thu, Feb 11, 2016 at 6:06 AM, Robbie Harwood wrote: >> >> - The GSSAPI authentication code has been moved without modification. >> In doing so, the temptation to modify it (flags, error checking, that >> big

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Thu, Feb 11, 2016 at 12:10 PM, Amit Kapila wrote: > Okay, changed as per suggestion. Looks good to me; committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Freeze avoidance of very large table.

On Wed, Feb 3, 2016 at 12:32 PM, Masahiko Sawada wrote: > I've divided the main patch into two patches; add frozen bit patch and > pg_upgrade support patch. > 000 patch is almost same as previous code. (includes small fix) > 001 patch provides rewriting visibility map as a

Re: [HACKERS] custom function for converting human readable sizes to bytes

Hi 2016-02-11 7:44 GMT+01:00 Vitaly Burovoy : > On 2/10/16, Pavel Stehule wrote: > > Hi Vitaly, > > > > please, can you send your version of this patch, how we talked about it > in > > Moscow? > > > > Thank you > > > > Pavel > > Hello, Pavel! >

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

On 11 February 2016 at 08:43, Andres Freund wrote: > On 2016-02-09 09:27:04 +, Dean Rasheed wrote: >> Looking at this patch, I have mixed feelings about it. On the one hand >> I really like the look of the output, and I can see that the non-fixed >> nature of the output

Re: [HACKERS] Fuzzy substring searching with the pg_trgm extension

The behavior of this function is surprising to me. select substring_similarity('dog' , 'hotdogpound') ; substring_similarity -- 0.25 Substring search was desined to search similar word in string: contrib_regression=# select substring_similarity('dog' ,

Re: [HACKERS] [PROPOSAL] Improvements of Hunspell dictionaries support

Thank you for the review. On 10.02.2016 19:46, Teodor Sigaev wrote: I duplicate the patch here. it's very good thing to update disctionaries to support modern versions. And thank you for improving documentation. Also I've impressed by long description in spell.c header. Som notices about

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Thinking about this some more though, perhaps *sorting* the columns is > the wrong way to be thinking about it. Perhaps a better approach would > be to allow the columns to be *listed* (optionally, using a separate > query). Something like the following (don't get too hung up on the > syntax): > >

[HACKERS] max_parallel_degree context level

Hi all, As it currently stands, max_parallel_degree is set to a superuser context, but we probably want to discuss whether we want to keep it this way prior to releasing 9.6. Might we want to reduce its level so that users can adjust it accordingly? They'd still be limited by

[HACKERS] Request for Code Review: BPGSQL

Hello, team! I am writing on behalf of the BPGSQL Project [1] to request a code audit from a core PGSQL team member. The current maintainer is worried about the security of the code, and is considering closing the project unless it can be properly reviewed [2]. As a project living downstream[3]

Re: [HACKERS] Fuzzy substring searching with the pg_trgm extension

I have attached a new version of the patch. It fixes error of operators <->> and %>: - operator <->> did not pass the regression test in CentOS 32 bit (gcc 4.4.7 20120313). - operator %> did not pass the regression test in FreeBSD 32 bit (gcc 4.2.1 20070831). It was because of variable

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Thu, Feb 11, 2016 at 3:15 AM, Amit Kapila wrote: > Sounds sensible, however after changes, CreateLWLocks() started > looking unreadable, so moved initialization and registration of tranches > to separate functions. Seems good. > Increased number of tranches allocated

[HACKERS] Invalid user-level setting = confusing error message

Hi, At the moment, if we try to set up a configuration parameter for a user which doesn't make sense in that context, we get an error message that doesn't really tell us that we're not allowed to set it for users: # ALTER ROLE moo SET log_line_prefix = '%s'; ERROR: parameter "log_line_prefix"

Re: [HACKERS] [PATCH v4] GSSAPI encryption support

On Thu, Feb 11, 2016 at 6:06 AM, Robbie Harwood wrote: > For your consideration, here is a new version of GSSAPI encryption > support. For those who prefer, it's also available on my github: >

Re: [HACKERS] max_parallel_degree context level

On Thu, Feb 11, 2016 at 7:40 AM, Thom Brown wrote: > As it currently stands, max_parallel_degree is set to a superuser > context, but we probably want to discuss whether we want to keep it > this way prior to releasing 9.6. Might we want to reduce its level so > that users can

Re: [HACKERS] Fuzzy substring searching with the pg_trgm extension

On Thu, Feb 11, 2016 at 8:11 AM, Teodor Sigaev wrote: >> I have attached a new version of the patch. It fixes error of operators >> <->> and >> %>: >> - operator <->> did not pass the regression test in CentOS 32 bit (gcc >> 4.4.7 >> 20120313). >> - operator %> did not pass the

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

On Tue, Feb 9, 2016 at 11:14 PM, Amit Kapila wrote: >> Patches still apply 1 month later. > > Thanks for verification! > >> >> I don't really have an opinion on the variable naming. I guess they >> only need making longer if there's going to be some confusion about >>

Re: [HACKERS] Request for Code Review: BPGSQL

W dniu 11.02.2016 o 14:06, Rich Jones pisze: > Hello, team! > > I am writing on behalf of the BPGSQL Project [1] to request a code audit > from a core PGSQL team member. > > The current maintainer is worried about the security of the code, and is > considering closing the project unless it can

Re: [HACKERS] extend pgbench expressions with functions

On Thu, Feb 11, 2016 at 12:37 AM, Fabien COELHO wrote: > v26 attached implements these changes. +/* the argument list has been built in reverse order, it is fixed here */ +expr->u.function.args = reverse_elist(args); Hm. I may be missing something, but why is that

Re: [HACKERS] Fuzzy substring searching with the pg_trgm extension

On 11.02.2016 16:35, Mike Rylander wrote: On Thu, Feb 11, 2016 at 8:11 AM, Teodor Sigaev wrote: I have attached a new version of the patch. It fixes error of operators <->> and %>: - operator <->> did not pass the regression test in CentOS 32 bit (gcc 4.4.7 20120313). -

Re: [HACKERS] GinPageIs* don't actually return a boolean

On Tue, Feb 9, 2016 at 11:53 PM, Michael Paquier wrote: > On Wed, Feb 10, 2016 at 1:17 AM, Yury Zhuravlev > wrote: >> I've just run into a problem with these macro. Function ginStepRight breaks >> completely when compiled using the MSVC2013

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

Hello, Robert > Thanks, this looks way better. Some more comments: > > - I don't think there's any good reason for this patch to change the > calling convention for ShmemInitHash(). Maybe that's a good idea and > maybe it isn't, but it's a separate issue from what this patch is > doing, and if

Re: [HACKERS] GinPageIs* don't actually return a boolean

On 2016-02-11 08:50:41 -0500, Robert Haas wrote: > Are we thinking to back-patch this? I would be disinclined to > back-patch widespread changes like this. If there's a specific > instance related to Gin where this is causing a tangible problem, we > could back-patch just that part, with a clear

Re: [HACKERS] Fuzzy substring searching with the pg_trgm extension

On 11.02.2016 16:11, Teodor Sigaev wrote: I have attached a new version of the patch. It fixes error of operators <->> and %>: - operator <->> did not pass the regression test in CentOS 32 bit (gcc 4.4.7 20120313). - operator %> did not pass the regression test in FreeBSD 32 bit (gcc 4.2.1

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

On Thu, Feb 11, 2016 at 9:04 AM, Robert Haas wrote: >> Is there anything, I can do to move this forward? > > Well, looking at this again, I think I'm OK to go with your names. > That doesn't seem like the thing to hold up the patch for. So I'll go > ahead and push the

Re: [HACKERS] max_parallel_degree context level

On 11 February 2016 at 12:40, Thom Brown wrote: > Hi all, > > As it currently stands, max_parallel_degree is set to a superuser > context, but we probably want to discuss whether we want to keep it > this way prior to releasing 9.6. Might we want to reduce its level so > that

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.

Robert Haas writes: >> That would be great. Taking a look at what happened, I have a feeling >> this may be a race condition of some kind in the isolation tester. It >> seems to have failed to recognize that a1 started waiting, and that >> caused the "deadlock detected"

Re: [HACKERS] max_parallel_degree context level

On Thu, Feb 11, 2016 at 10:32 AM, Simon Riggs wrote: > A few questions and thoughts to help decide... > > Does it take into account the parallel degree during planning? > Does it take into account the actual parallel degree during planning? max_worker_processes is a query

Re: [HACKERS] max_parallel_degree context level

On 02/11/2016 07:55 AM, Robert Haas wrote: > On Thu, Feb 11, 2016 at 10:32 AM, Simon Riggs wrote: >> If you make max_worker_processes USERSET won't everybody just set it to >> max_worker_processes? > > I think that you meant for the first instance of max_worker_processes >

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

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > Sent: Thursday, February 11, 2016 1:26 PM > To: Kaigai Kouhei(海外 浩平) > Cc: Andres Freund; Amit Kapila; pgsql-hackers > Subject: Re: CustomScan in a

Re: NextXID format change (was Re: [HACKERS] exposing pg_controldata and pg_config as functions)

On Wed, Feb 10, 2016 at 10:23:41AM +0900, Michael Paquier wrote: > On Wed, Feb 10, 2016 at 9:57 AM, Joe Conway wrote: > > I'll commit the attached tomorrow if there are no other concerns voiced. > > Just a nitpick regarding this block: > + if (strchr(p, '/') !=

Re: NextXID format change (was Re: [HACKERS] exposing pg_controldata and pg_config as functions)

On Fri, Feb 12, 2016 at 9:18 AM, Bruce Momjian wrote: > On Wed, Feb 10, 2016 at 10:23:41AM +0900, Michael Paquier wrote: >> On Wed, Feb 10, 2016 at 9:57 AM, Joe Conway wrote: >> > I'll commit the attached tomorrow if there are no other concerns voiced. >> >>

Re: [HACKERS] custom function for converting human readable sizes to bytes

Hello! On 2/11/16, Pavel Stehule wrote: > Hi > > assigned https://commitfest.postgresql.org/9/514/ > > Regards > Pavel This patch was almost done by the end of the previous CF(2016-01): there was few little flaws which are solved by now. I have reviewed this patch. It

Re: [HACKERS] pgcrypto: add s2k-count

On Fri, Feb 12, 2016 at 2:46 AM, Robert Haas wrote: > On Wed, Feb 10, 2016 at 12:44 AM, Jeff Janes wrote: >> I did not bump the extension version. I realized the migration file >> would be empty, as there no change to SQL-level functionality (the new

Re: [HACKERS] extend pgbench expressions with functions

On Fri, Feb 12, 2016 at 2:41 AM, Fabien COELHO wrote: > > Hello Michaël, > >> +/* the argument list has been built in reverse order, it is fixed >> here */ >> +expr->u.function.args = reverse_elist(args); >> Hm. I may be missing something, but why is that necessary?

Re: [HACKERS] [PATCH v4] GSSAPI encryption support

On Fri, Feb 12, 2016 at 3:56 AM, Robbie Harwood wrote: > Michael Paquier writes: >> On Thu, Feb 11, 2016 at 6:06 AM, Robbie Harwood wrote: >>> - The GSSAPI authentication code has been moved without modification. >>> In

Re: [HACKERS] Removing Functionally Dependent GROUP BY Columns

David Rowley writes: > [ prune_group_by_clause_ab4f491_2016-01-23.patch ] > [ check_functional_grouping_refactor.patch ] I've committed this with mostly-cosmetic revisions (principally, rewriting a lot of the comments, which seemed on the sloppy side). >> * Both of

[HACKERS] Clock with Adaptive Replacement

Hi hackers, What do you think about improving cache replacement clock-sweep algorithm in PostgreSQL with adaptive version proposed in this article: http://www-cs.stanford.edu/~sbansal/pubs/fast04.pdf Are there some well known drawbacks of this approach or it will be interesting to adopt

Re: [HACKERS] Add schema-qualified relnames in constraint error messages.

On Thu, Feb 11, 2016 at 10:53 AM, Pavel Stehule wrote: > > most recent error in verbose mode, without making a permanent session > >> > state change. Something like >> > >> > regression=# insert into bar values(1); >> > ERROR: insert or update on table "bar" violates

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

On Fri, Feb 12, 2016 at 2:56 AM, Robert Haas wrote: > On Fri, Feb 5, 2016 at 3:36 AM, Michael Paquier > wrote: >> So, here are some thoughts to make that more user-friendly. I think >> that the critical issue here is to properly flatten the meta

Re: [HACKERS] Way to check whether a particular block is on the shared_buffer?

> On Tue, Feb 9, 2016 at 6:35 PM, Kouhei Kaigai wrote: > > Unfortunately, it was not sufficient. > > > > Due to the assumption, the buffer page to be suspended does not exist > > when a backend process issues a series P2P DMA command. (If block would > > be already loaded to

Re: [HACKERS] GinPageIs* don't actually return a boolean

On Fri, Feb 12, 2016 at 3:45 AM, Tom Lane wrote: > Andres Freund writes: >> On 2016-02-11 13:37:17 -0500, Tom Lane wrote: >>> Absolutely; they don't work safely for testing bits that aren't in the >>> rightmost byte of a flag word, for instance. I'm on

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

On Wed, Feb 10, 2016 at 10:55:10AM -0500, Tom Lane wrote: > Interestingly, we seem to have managed to greatly reduce the "other" > time (which I presume is basically mdpostchkpt unlinking) since 9.2. > The worst case observed in HEAD is about 100s: > > regression=# select

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Fri, Feb 12, 2016 at 12:39 AM, Robert Haas wrote: > > On Thu, Feb 11, 2016 at 12:10 PM, Amit Kapila wrote: > > Okay, changed as per suggestion. > > Looks good to me; committed. > Thanks! Attached patch changes the name of some of the existing

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.

We're not out of the woods on this :-( ... jaguarundi, which is the first of the CLOBBER_CACHE_ALWAYS animals to run these tests, didn't like them at all. I think I fixed the deadlock-soft-2 failure, but its take on deadlock-hard is: *** 17,25 step s6a7: LOCK TABLE a7; step s7a8: LOCK

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

02.02.2016 15:50, Anastasia Lubennikova: 31.01.2016 11:04, David Rowley: On 27 January 2016 at 03:35, Anastasia Lubennikova wrote: including_columns_3.0 is the latest version of patch. And changes regarding the previous version are attached in a separate patch.

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.

I wrote: > No, because the machines that are failing are showing a "" > annotation that your reference output *doesn't* have. I think what is > actually happening is that these machines are seeing the process as > waiting and reporting it, whereas on your machine the backend detects > the

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Thu, Feb 11, 2016 at 6:45 PM, Robert Haas wrote: > > On Thu, Feb 11, 2016 at 3:15 AM, Amit Kapila wrote: > > Sounds sensible, however after changes, CreateLWLocks() started > > looking unreadable, so moved initialization and registration of

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.

On Thu, Feb 11, 2016 at 12:04 PM, Tom Lane wrote: > I wrote: >> No, because the machines that are failing are showing a "" >> annotation that your reference output *doesn't* have. I think what is >> actually happening is that these machines are seeing the process as >>

Re: [HACKERS] Performance degradation in commit ac1d794

On Thu, Jan 14, 2016 at 12:28 PM, Tom Lane wrote: > Andres Freund writes: >> This brings me to something related: I'm wondering if we shouldn't merge >> unix/win32_latch.c. > > Well, it's duplicated code on the one hand versus maze-of-ifdefs on the >

Re: [HACKERS] Performance degradation in commit ac1d794

Robert Haas writes: > I think we should either get this fixed RSN or revert the problematic > commit until we get it fixed. I'd be rather disappointed about the > latter because I think this was a very good thing on the merits, but > probably not good enough to justify

Re: [HACKERS] GinPageIs* don't actually return a boolean

Robert Haas wrote: So, is it being pulled in indirectly by some other #include? I can double-check it tomorrow. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Add schema-qualified relnames in constraint error messages.

On Tue, Jan 5, 2016 at 10:16 PM, Tom Lane wrote: > Jim Nasby writes: >> FWIW, I suspect very few people know about the verbosity setting (I >> didn't until a few months ago...) Maybe psql should hint about it the >> first time an error is reported in

Re: [HACKERS] Performance degradation in commit ac1d794

On Thu, Feb 11, 2016 at 12:48 PM, Tom Lane wrote: > Robert Haas writes: >> I think we should either get this fixed RSN or revert the problematic >> commit until we get it fixed. I'd be rather disappointed about the >> latter because I think this was a

Re: [HACKERS] Performance degradation in commit ac1d794

On 2016-02-11 12:50:58 -0500, Robert Haas wrote: > On Thu, Feb 11, 2016 at 12:48 PM, Tom Lane wrote: > > Robert Haas writes: > >> I think we should either get this fixed RSN or revert the problematic > >> commit until we get it fixed. I'd be rather

Re: [HACKERS] Add schema-qualified relnames in constraint error messages.

> most recent error in verbose mode, without making a permanent session > > state change. Something like > > > > regression=# insert into bar values(1); > > ERROR: insert or update on table "bar" violates foreign key constraint > "bar_f1_fkey" > > DETAIL: Key (f1)=(1) is not present in table

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

On Fri, Feb 5, 2016 at 3:36 AM, Michael Paquier wrote: > So, here are some thoughts to make that more user-friendly. I think > that the critical issue here is to properly flatten the meta data in > the custom language and represent it properly in a new catalog, >

Re: [HACKERS] GinPageIs* don't actually return a boolean

Andres Freund writes: > On 2016-02-11 09:51:26 -0500, Robert Haas wrote: >> I have never been quite clear on what you think is going to cause >> stdbool.h inclusions to become more common. > Primarily because it's finally starting to be supported across the > board, thanks to

Re: [HACKERS] Performance degradation in commit ac1d794

On Thu, Feb 11, 2016 at 12:53 PM, Andres Freund wrote: >> One problem is that it makes for misleading results if you try to >> benchmark 9.5 against 9.6. > > You need a really beefy box to show the problem. On a large/new 2 socket > machine the performance regression in in the

Re: [HACKERS] [PATCH v4] GSSAPI encryption support

On Thu, Feb 11, 2016 at 8:42 AM, Michael Paquier wrote: > + * Portions Copyright (c) 2015-2016, Red Hat, Inc. > + * Portions Copyright (c) 1996-2016, PostgreSQL Global Development Group > I think that this part may be a problem... Not sure the feeling of the > others

Re: [HACKERS] GinPageIs* don't actually return a boolean

On 2016-02-11 13:06:14 -0500, Tom Lane wrote: > But I'm unconvinced that we need to make our .c files prepared for > stdbool.h to be #included in them. The fixes, besides two stylistic edits around !! use, are all in headers. The issue is that we return things meant to be used in a boolean

Re: [HACKERS] Performance degradation in commit ac1d794

On 2016-02-11 13:09:27 -0500, Robert Haas wrote: > On Thu, Feb 11, 2016 at 12:53 PM, Andres Freund wrote: > >> One problem is that it makes for misleading results if you try to > >> benchmark 9.5 against 9.6. > > > > You need a really beefy box to show the problem. On a

Re: [HACKERS] GinPageIs* don't actually return a boolean

On Thu, Feb 11, 2016 at 9:54 AM, Andres Freund wrote: > On 2016-02-11 09:51:26 -0500, Robert Haas wrote: >> I have never been quite clear on what you think is going to cause >> stdbool.h inclusions to become more common. > > Primarily because it's finally starting to be

Re: [HACKERS] pgcrypto: add s2k-count

On Wed, Feb 10, 2016 at 12:44 AM, Jeff Janes wrote: > pgcrypto supports s2k-mode for key-stretching during symmetric > encryption, and even defaults to s2k-mode=3, which means configurable > iterations. But it doesn't support s2k-count to actually set those > iterations to

[HACKERS] pl/pgsql exported functions

Most of the pl/pgsql functions and variables are prefixed plpgsql_, so they don't risk conflicting with other shared libraries loaded. There are a couple that are not prefixed. Attached patch fixes that. It's mostly a cleanup, but I think it's something we should do since it's only 2 variables

Re: [HACKERS] extend pgbench expressions with functions

Hello Michaël, +/* the argument list has been built in reverse order, it is fixed here */ +expr->u.function.args = reverse_elist(args); Hm. I may be missing something, but why is that necessary? This is basically doing a double-reversion to put all the arguments in the correct order

Re: [HACKERS] pl/pgsql exported functions

2016-02-11 18:29 GMT+01:00 Magnus Hagander : > Most of the pl/pgsql functions and variables are prefixed plpgsql_, so > they don't risk conflicting with other shared libraries loaded. > > There are a couple that are not prefixed. Attached patch fixes that. It's > mostly a

Re: [HACKERS] Updated backup APIs for non-exclusive backups

Hi Magnus, thanks for working on this topic. What it does is very similar to what Barman's pgespresso extension does and I'd like to see it implemented soon in the core. I've added myself as reviewer for the patch on commitfest site. Regards, Marco -- Marco Nenciarini - 2ndQuadrant Italy

Re: [HACKERS] Performance degradation in commit ac1d794

On Thu, Feb 11, 2016 at 1:19 PM, Andres Freund wrote: >> > Putting it on the open items list sounds good to me. >> >> Well, OK, I've done that then. I don't really agree that it's not a >> problem; the OP said he saw a 3x regression, and some of my colleagues >> doing

Re: [HACKERS] GinPageIs* don't actually return a boolean

Andres Freund writes: > And anyway, these macros are a potential issue even without stdbool.h > style booleans. Absolutely; they don't work safely for testing bits that aren't in the rightmost byte of a flag word, for instance. I'm on board with making these fixes, I'm just

Re: [HACKERS] GinPageIs* don't actually return a boolean

On 2016-02-11 13:37:17 -0500, Tom Lane wrote: > Andres Freund writes: > > And anyway, these macros are a potential issue even without stdbool.h > > style booleans. > > Absolutely; they don't work safely for testing bits that aren't in the > rightmost byte of a flag word, for

Re: [HACKERS] Performance degradation in commit ac1d794

Robert Haas writes: > On Thu, Feb 11, 2016 at 1:19 PM, Andres Freund wrote: >> Well, I can't do anything about that right now. I won't have the time to >> whip up the new/more complex API we discussed upthread in the next few >> days. So either we go

Re: [HACKERS] checkpointer continuous flushing - V16

On 2016-02-04 16:54:58 +0100, Andres Freund wrote: > Fabien asked me to post a new version of the checkpoint flushing patch > series. While this isn't entirely ready for commit, I think we're > getting closer. > > I don't want to post a full series right now, but my working state is > available

Re: [HACKERS] Performance degradation in commit ac1d794

On Thu, Feb 11, 2016 at 1:41 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Feb 11, 2016 at 1:19 PM, Andres Freund wrote: >>> Well, I can't do anything about that right now. I won't have the time to >>> whip up the new/more

Re: [HACKERS] GinPageIs* don't actually return a boolean

Andres Freund writes: > On 2016-02-11 13:37:17 -0500, Tom Lane wrote: >> Absolutely; they don't work safely for testing bits that aren't in the >> rightmost byte of a flag word, for instance. I'm on board with making >> these fixes, I'm just unconvinced that stdbool is a good