Re: [HACKERS] MinGW / Windows / printf format specifiers

On 19 February 2016 at 12:15, Chapman Flack wrote: > > The cause seems to be that Windows conventions have int = long = int32 > (even on 64-bit platforms) and only 'long long' = int64. Yes, it's an LLP64 platform. https://en.wikipedia.org/wiki/64-bit_computing > The

Re: [HACKERS] WAL logging problem in 9.4.3?

On Thu, Feb 18, 2016 at 4:27 PM, Michael Paquier wrote: > On Thu, Feb 4, 2016 at 3:24 PM, Heikki Linnakangas wrote: >> I dropped the ball on this one back in July, so here's an attempt to revive >> this thread. >> >> I spent some time fixing the

Re: [HACKERS] Typo in bufmgr.c that result in waste of memory

On Fri, Feb 19, 2016 at 8:28 AM, Takashi Horikawa wrote: > > Hi all, > > I have just found a typo in the source code (not in a comment) of bufmgr.c > that result in waste of memory. It might be a 'bug' but it does not result > in any incorrect operation but just results

Re: [HACKERS] Relaxing SSL key permission checks

On 02/18/2016 08:22 PM, Tom Lane wrote: Now, I have heard it argued that the OpenSSH/L authors are a bunch of idiots who know nothing about security. But it's not like insisting on restrictive permissions on key files is something we invented out of the blue. It's pretty standard practice,

Re: [HACKERS] Relaxing SSL key permission checks

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> I completely disagree that those file-permissions checks are useless. > If that's something you're concerned with then the right answer is to > monitor the file permissions- and there are tools which do exactly

[HACKERS] MinGW / Windows / printf format specifiers

So I announce a PL/Java 1.5.0-BETA1 with a comment that windows-MSVC was well tested but that I hadn't found anyone to test windows-mingw, and behold, what should happen but someone turns up with an interest in testing the mingw build, so we might have that back in shape as well for -BETA2.

Re: [HACKERS] about google summer of code 2016

On 19 Feb 2016 8:30 am, "Chapman Flack" wrote: > > On 02/18/16 19:35, Amit Langote wrote: > > > Apparently, the deadline is: February 20, 2016 at 04:00 (+0900 UTC) > > > > https://summerofcode.withgoogle.com/ > > For anybody finding that web site as anti-navigable as I did,

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Fri, Feb 19, 2016 at 11:53 AM, Peter Eisentraut wrote: > On 2/18/16 12:20 PM, Joe Conway wrote: >> Just to be clear, AFAIK there is no issue with the committed changes on >> Windows. If there is please provide a concrete example that we can discuss. > > Originally it was

Re: [HACKERS] about google summer of code 2016

On 02/18/16 19:35, Amit Langote wrote: > Apparently, the deadline is: February 20, 2016 at 04:00 (+0900 UTC) > > https://summerofcode.withgoogle.com/ For anybody finding that web site as anti-navigable as I did, here are more direct links to the actual rules, and terms of agreement for the

[HACKERS] Typo in bufmgr.c that result in waste of memory

Hi all, I have just found a typo in the source code (not in a comment) of bufmgr.c that result in waste of memory. It might be a 'bug' but it does not result in any incorrect operation but just results in waste of a few memory resource. As sizeof(PrivateRefCountArray) found in

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 2/18/16 12:20 PM, Joe Conway wrote: > Just to be clear, AFAIK there is no issue with the committed changes on > Windows. If there is please provide a concrete example that we can discuss. Originally it was mentioned that this feature could be used in the regression tests by making certain

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 2/18/16 3:30 AM, Andres Freund wrote: > I don't understand why you're so opposed to this. Several people said > that they're interested in this information in the current discussion > and it has been requested repeatedly over the years. I think no one except Andrew Dunstan has requested this,

Re: [HACKERS] Relaxing SSL key permission checks

On 2/18/16 10:17 AM, Tom Lane wrote: > Christoph Berg writes: >> Currently the server insists on ssl_key_file's permissions to be 0600 >> or less, and be owned by the database user. Debian has been patching >> be-secure.c since forever (the git history goes back to 8.2beta1) to

Re: [HACKERS] Relaxing SSL key permission checks

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > Further, the notion that *this* is the footgun is completely off the > > reservation- if the files have been changed to allow untrusted users to > > have access to them, there isn't diddly we can do about

Re: [HACKERS] Relaxing SSL key permission checks

Stephen Frost writes: > Further, the notion that *this* is the footgun is completely off the > reservation- if the files have been changed to allow untrusted users to > have access to them, there isn't diddly we can do about it. I completely disagree that those

Re: [HACKERS] WIP: Access method extendability

On Fri, Feb 19, 2016 at 12:51 AM, Alexander Korotkov wrote: >> 11 I'd really like to see regression tests (TAP-tests?) for replication >> with generic xlog. > > > TAP test for replication added to bloom contrib. This test run on additional > make target wal-check. Just putting my eyes on that...

Re: [HACKERS] Relaxing SSL key permission checks

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Andres Freund writes: > > ... We don't prevent the user from making the > > configuration file world-writable either, > > Maybe we should. It wasn't an issue originally, because the config files > were necessarily inside $PGDATA which

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

On Sat, Feb 13, 2016 at 2:26 PM, Michael Paquier wrote: > On Sat, Feb 13, 2016 at 1:01 PM, Robert Haas wrote: >> On Fri, Feb 12, 2016 at 12:56 PM, Andres Freund wrote: >>> On 2016-02-12 12:37:35 -0500, Robert Haas wrote:

Re: [HACKERS] [DOCS] The number of bytes is stored in index_size of pgstatindex() ?

Peter Geoghegan writes: > On Thu, Feb 18, 2016 at 4:15 PM, Tom Lane wrote: >> Because they've been removed from the right-link/left-link chains. > That isn't the same thing as being inaccessible by scans, clearly > (just what you call the "leaf scan

Re: [HACKERS] about google summer of code 2016

On 2016/02/18 22:44, Alexander Korotkov wrote: > On Wed, Feb 17, 2016 at 10:40 AM, Amit Langote wrote: >> I didn't find for 2016 but here is the PostgreSQL wiki page for the last >> year's GSoC page: https://wiki.postgresql.org/wiki/GSoC_2015#Project_Ideas > > > I've created wiki page for GSoC

Re: [HACKERS] [DOCS] The number of bytes is stored in index_size of pgstatindex() ?

On Thu, Feb 18, 2016 at 4:15 PM, Tom Lane wrote: > Because they've been removed from the right-link/left-link chains. That isn't the same thing as being inaccessible by scans, clearly (just what you call the "leaf scan sequence"). Besides, half-dead pages still have

Re: [HACKERS] [DOCS] The number of bytes is stored in index_size of pgstatindex() ?

Peter Geoghegan writes: > Why would dead pages not get traversed by scans? Because they've been removed from the right-link/left-link chains. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] [DOCS] The number of bytes is stored in index_size of pgstatindex() ?

On Thu, Feb 18, 2016 at 3:06 PM, Tom Lane wrote: > Don't see why; the documentation and field names clearly imply that those > numbers are accumulated only over leaf pages. Then I guess what might be lacking is a delineation of what a leaf page is for the purposes of

Re: [HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?

On Tue, Feb 16, 2016 at 7:10 AM, Tom Lane wrote: > Given this, I'm on board with just removing the weasel-wording about > timer resolution, except maybe for commit_delay where useful values > are small enough that it's a hazard on old systems. +1, but I'd move the guidance

Re: [HACKERS] New pg_upgrade data directory inside old one?

On Mon, Feb 15, 2016 at 06:32:06PM +0100, Magnus Hagander wrote: > > > On Mon, Feb 15, 2016 at 6:29 PM, Bruce Momjian wrote: > > Someone on IRC reported that if they had run the pg_upgrade-created > delete_old_cluster.sh shell script it would have deleted their old

Re: [HACKERS] [DOCS] The number of bytes is stored in index_size of pgstatindex() ?

Peter Geoghegan writes: > I think that the P_ISLEAF() instrumentation of free space and > fragments might still need to happen for deleted and/or half dead > pages. Don't see why; the documentation and field names clearly imply that those numbers are accumulated only over leaf

Re: [HACKERS] [DOCS] The number of bytes is stored in index_size of pgstatindex() ?

On Thu, Feb 18, 2016 at 11:52 AM, Tom Lane wrote: > It looks like this was done correctly to begin with, and I broke it in > d287818eb514d431b1a68e1f3940cd958f82aa34. Not sure what I was thinking :-( I think that you might not have simply changed the order in a totally

Re: [HACKERS] [DOCS] The number of bytes is stored in index_size of pgstatindex() ?

I wrote: > Peter Geoghegan writes: >> I think we should change it. It seems like a bug to me. > Me too. Is it enough bug-like to be something to back-patch, or should > we just change it in HEAD? Actually, there's a significantly worse bug here: I just realized that the page

Re: [HACKERS] [DOCS] The number of bytes is stored in index_size of pgstatindex() ?

I vote back patch. Subtle differences between the branches should be avoided. -- Peter Geoghegan

Re: [HACKERS] [DOCS] The number of bytes is stored in index_size of pgstatindex() ?

Peter Geoghegan writes: > On Thu, Feb 18, 2016 at 10:49 AM, Tom Lane wrote: >> Yeah, that seems a bit strange to me as well. Should we change it to >> count the root as an internal page, or is that going too far? > I think we should change it. It seems like

Re: [HACKERS] [DOCS] The number of bytes is stored in index_size of pgstatindex() ?

On Thu, Feb 18, 2016 at 10:49 AM, Tom Lane wrote: > Yeah, that seems a bit strange to me as well. Should we change it to > count the root as an internal page, or is that going too far? I think we should change it. It seems like a bug to me. I've had the same point come up

Re: [HACKERS] [DOCS] The number of bytes is stored in index_size of pgstatindex() ?

Peter Geoghegan writes: > That's odd. Having taken a quick look at pgstatindex_impl(), I dislike > that it counts the root separately from internal pages. That's not how > they're actually presented and understood in the code. Yeah, that seems a bit strange to me as well.

Re: [HACKERS] [DOCS] The number of bytes is stored in index_size of pgstatindex() ?

On Thu, Feb 18, 2016 at 10:01 AM, Tom Lane wrote: > Yeah ... the numbers already appear not to add up because the root page > is counted in index_size but not any other column, so there's already > something worthy of explanation there. Maybe something like "The reported >

Re: [HACKERS] [DOCS] The number of bytes is stored in index_size of pgstatindex() ?

Peter Geoghegan writes: > On Thu, Feb 18, 2016 at 9:40 AM, Tom Lane wrote: >> I think this is a bug and we ought to fix the code to include the >> metapage in the reported index_size. Thoughts? > I tend to agree, but I think you should note that

Re: [HACKERS] [DOCS] The number of bytes is stored in index_size of pgstatindex() ?

On Thu, Feb 18, 2016 at 9:40 AM, Tom Lane wrote: > I think this is a bug and we ought to fix the code to include the > metapage in the reported index_size. Thoughts? I tend to agree, but I think you should note that specifically in the documentation. I'm in favor of tools

Re: [HACKERS] [DOCS] The number of bytes is stored in index_size of pgstatindex() ?

=?UTF-8?B?5aSn5aGa5oay5Y+4?= writes: > It seems that description of index_size that is returned by pgstatindex() is > wrong. > The document says "Total number of pages in index". > But it looks like the number of bytes is stored in index_size. Hmm, you're right,

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

18.02.2016 20:18, Anastasia Lubennikova: 04.02.2016 20:16, Peter Geoghegan: On Fri, Jan 29, 2016 at 8:50 AM, Anastasia Lubennikova wrote: I fixed it in the new version (attached). Thank you for the review. At last, there is a new patch version 3.0. After some

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 02/18/2016 12:30 AM, Andres Freund wrote: > On 2016-02-17 21:19:08 -0500, Peter Eisentraut wrote: >> On 2/17/16 9:08 PM, Michael Paquier wrote: >>> On Thu, Feb 18, 2016 at 11:02 AM, Peter Eisentraut wrote: On 2/17/16 5:20 PM, Josh berkus wrote: > I have a use-case for

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

On 2/18/16, Pavel Stehule wrote: > it doesn't look badly. Is there any possibility how to emulate it with > Python2 ? What do you think about some similar implementation on Python2? The example code I gave works as is in Python2. The Python3 keyword only arguments are

Re: [HACKERS] Question about Restart point and checkpoint_segments

Sorry for the noise, I got my answer. 2016-02-16 18:02 GMT+01:00 Benoit Lobréau : > Hello, > > I am using a hot_standby setup on PostgreSQL 9.1 > While I was testing, I found out that only checkpoint_timeout (+ a > checkpoint since the last restart point) could trigger

Re: [HACKERS] Relaxing SSL key permission checks

Andres Freund writes: > ... We don't prevent the user from making the > configuration file world-writable either, Maybe we should. It wasn't an issue originally, because the config files were necessarily inside $PGDATA which we restrict permissions on. But these days you

Re: [HACKERS] Relaxing SSL key permission checks

On 2016-02-18 10:17:49 -0500, Tom Lane wrote: > Christoph Berg writes: > > Currently the server insists on ssl_key_file's permissions to be 0600 > > or less, and be owned by the database user. Debian has been patching > > be-secure.c since forever (the git history goes back to

Re: [HACKERS] Relaxing SSL key permission checks

Bruce Momjian writes: > On Thu, Feb 18, 2016 at 10:17:49AM -0500, Tom Lane wrote: >> We could allow group-readable if we had some way to know whether to >> trust the specific group, but I don't think there's any practical >> way to do that. System conventions vary too much. >

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

Another update - separated new internal function to satisfy opr_sanity.sql diff --git a/contrib/tcn/tcn.c b/contrib/tcn/tcn.c index 7352b29..3a6d4f5 100644 --- a/contrib/tcn/tcn.c +++ b/contrib/tcn/tcn.c @@ -160,7 +160,7 @@ triggered_change_notification(PG_FUNCTION_ARGS)

Re: [HACKERS] Relaxing SSL key permission checks

On Thu, Feb 18, 2016 at 10:17:49AM -0500, Tom Lane wrote: > Christoph Berg writes: > > Currently the server insists on ssl_key_file's permissions to be 0600 > > or less, and be owned by the database user. Debian has been patching > > be-secure.c since forever (the git history

Re: [HACKERS] Relaxing SSL key permission checks

Christoph Berg writes: > Currently the server insists on ssl_key_file's permissions to be 0600 > or less, and be owned by the database user. Debian has been patching > be-secure.c since forever (the git history goes back to 8.2beta1) to > relax that to 0640 or less, and owned by

Re: [HACKERS] [WIP] speeding up GIN build with parallel workers

On Wed, 17 Feb 2016 23:01:47 +0300 Oleg Bartunov wrote: > My feedback is (Mac OS X 10.11.3) > > set gin_parallel_workers=2; > create index message_body_idx on messages using gin(body_tsvector); > LOG: worker process: parallel worker for PID 5689 (PID 6906) was > terminated

[HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

Hi As far as I see there is one basic update function for jsonb, that can't be covered by `jsonb_set` - insert a new value into an array at arbitrary position. Using `jsonb_set` function we can only append into array at the end/at the beginning, and it looks more like a hack: ``` =# select

Re: [HACKERS] [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl

On Mon, Feb 15, 2016 at 12:03 AM, Tom Lane wrote: > > Robert Haas writes: > > > With respect to pg_locks - and for that matter also pg_stat_activity - > > I think you are right that improvement is needed. > > This is really the core of my concern at the

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

Dean Rasheed wrote: > If I want to sort the rows coming out of a query, my first thought > is always going to be to add/adjust the query's ORDER BY clause, not > use some weird +/- psql syntax. About the vertical sort, I agree on all your points. It's best to rely on ORDER BY for all the

Re: [HACKERS] about google summer of code 2016

On Wed, Feb 17, 2016 at 10:40 AM, Amit Langote < langote_amit...@lab.ntt.co.jp> wrote: > On 2016/02/17 16:27, Shubham Barai wrote: > > Hello everyone, > > > > I am currently pursuing my bachelor of engineering in computer science > > at Maharashtra > > Institute of Technology, Pune ,India. I am

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

Peter Eisentraut wrote: > On 2/9/16 11:21 AM, Daniel Verite wrote: > > Note that NULL values in the column that pivots are discarded > > by \crosstabview, because NULL as the name of a column does not > > make sense. > > Why not? > > All you're doing is printing it out, and psql is

[HACKERS] Relaxing SSL key permission checks

Hi, Currently the server insists on ssl_key_file's permissions to be 0600 or less, and be owned by the database user. Debian has been patching be-secure.c since forever (the git history goes back to 8.2beta1) to relax that to 0640 or less, and owned by root or the database user. The reason for

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

Daniel Verite wrote: > > > ORDER BY name > > > \crosstabview cols = (select to_char(d, 'Mon') from > > > generate_series('2000-01-01'::date, '2000-12-01', '1 month') d) > > > > My concern with that is that often you don't know what the columns will > > be, because you don't know what

Re: [HACKERS] a raft of parallelism-related bug fixes

On Thu, Feb 18, 2016 at 9:45 PM, Craig Ringer wrote: > That lets you make assertions about replication behaviour. It was built for > BDR and I think we'll need something along those lines in core if/when any > kind of logical replication facilities land, for things like

Re: [HACKERS] a raft of parallelism-related bug fixes

On 18 February 2016 at 20:35, Michael Paquier wrote: > On Thu, Feb 18, 2016 at 5:35 PM, Amit Langote > wrote: > > On 2016/02/18 16:38, Craig Ringer wrote: > >> I should resurrect Abhijit's patch to allow the isolationtester to talk > to

Re: [HACKERS] a raft of parallelism-related bug fixes

On Thu, Feb 18, 2016 at 5:35 PM, Amit Langote wrote: > On 2016/02/18 16:38, Craig Ringer wrote: >> I should resurrect Abhijit's patch to allow the isolationtester to talk to >> multiple servers. We'll want that when we're doing tests like "assert that >> this change

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

Hello, >Remaining tasks are; >- Document patch. >- Regression test patch. >- Syntax error message for s_s_names improvement. Please find patch attached for regression test for multisync replication. I have created this patch over Michael's recovery-test-suite patch. Please review it. Regards

Re: [HACKERS] Convert pltcl from strings to objects

On Tue, 9 Feb 2016 16:23:21 -0600 Jim Nasby wrote: > Currently, pl/tcl is implemented through nothing but string > manipulation. In other words, the C code is effectively creating a > giant string that the tcl interpreter must re-parse every time the > function is

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On Thu, Feb 18, 2016 at 3:48 PM, Etsuro Fujita wrote: > On 2016/02/16 16:40, Etsuro Fujita wrote: > >> On 2016/02/16 16:02, Ashutosh Bapat wrote: >> >>> On Tue, Feb 16, 2016 at 12:26 PM, Etsuro Fujita >>>

Re: [HACKERS] checkpointer continuous flushing - V16

On 2016-02-18 09:51:20 +0100, Fabien COELHO wrote: > I've looked at these patches, especially the whole bench of explanations and > comments which is a good source for understanding what is going on in the > WAL writer, a part of pg I'm not familiar with. > > When reading the patch 0002

Re: [HACKERS] checkpointer continuous flushing - V16

On 2016-02-11 19:44:25 +0100, Andres Freund wrote: > The first two commits of the series are pretty close to being ready. I'd > welcome review of those, and I plan to commit them independently of the > rest as they're beneficial independently. The most important bits are > the comments and docs

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On 2016/02/16 16:40, Etsuro Fujita wrote: On 2016/02/16 16:02, Ashutosh Bapat wrote: On Tue, Feb 16, 2016 at 12:26 PM, Etsuro Fujita > wrote: On 2016/02/16 15:22, Ashutosh Bapat wrote: During join planning, the

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

On 18 February 2016 at 02:00, Vitaly Burovoy wrote: >> + else >> + have_digits = false; > Does it worth to move it to the declaration and remove that "else" block? > + boolhave_digits = false; OK, that's probably a bit neater. > Is it

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

On 2016/02/12 21:19, Etsuro Fujita wrote: Comments on specific points follow. This seems to need minor rebasing in the wake of the join pushdown patch. Will do. Done. + /* Likewise for ForeignScan that has pushed down INSERT/UPDATE/DELETE */ + if (IsA(plan, ForeignScan) && +

Re: [HACKERS] Performance improvement for joins where outer side is unique

On 23/01/2016 12:42 am, "David Rowley" wrote: > > On 23 January 2016 at 05:36, Tomas Vondra wrote: > > Otherwise I think the patch is ready for committer - I think this is a > > valuable optimization and I see nothing wrong with the

Re: [HACKERS] checkpointer continuous flushing - V16

Hello Andres, 0001: Make SetHintBit() a bit more aggressive, afaics that fixes all the potential regressions of 0002 0002: Fix the overaggressive flushing by the wal writer, by only flushing every wal_writer_delay ms or wal_writer_flush_after bytes. I've looked at these

Re: [HACKERS] pg_ctl promote wait

On 18 February 2016 at 08:33, Andres Freund wrote: > Hi, > > On 2016-02-17 21:47:50 -0500, Peter Eisentraut wrote: > > It would be nice if pg_ctl promote supported the -w (wait) option. > > > > How could pg_ctl determine when the promotion has finished? > > How about looking

Re: [HACKERS] a raft of parallelism-related bug fixes

On 2016/02/18 16:38, Craig Ringer wrote: > I should resurrect Abhijit's patch to allow the isolationtester to talk to > multiple servers. We'll want that when we're doing tests like "assert that > this change isn't visible on the replica before it becomes visible on the > master". (Well, except we

Re: [HACKERS] pg_ctl promote wait

Hi, On 2016-02-17 21:47:50 -0500, Peter Eisentraut wrote: > It would be nice if pg_ctl promote supported the -w (wait) option. > > How could pg_ctl determine when the promotion has finished? How about looking into pg_control? ControlFileData->state ought to have the correct information.

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 2016-02-17 21:19:08 -0500, Peter Eisentraut wrote: > On 2/17/16 9:08 PM, Michael Paquier wrote: > > On Thu, Feb 18, 2016 at 11:02 AM, Peter Eisentraut wrote: > >> On 2/17/16 5:20 PM, Josh berkus wrote: > >>> I have a use-case for this feature, at part of it containerized > >>>

Re: [HACKERS] pg_ctl promote wait

On 18 February 2016 at 02:47, Peter Eisentraut wrote: > It would be nice if pg_ctl promote supported the -w (wait) option. > > How could pg_ctl determine when the promotion has finished? > > We could query pg_is_in_recovery(), but that would require database > access, which we