Re: [HACKERS] Allow "snapshot too old" error, to prevent bloat

On Feb 17, 2015 12:26 AM, "Andres Freund" wrote: > > On 2015-02-16 16:35:46 -0500, Bruce Momjian wrote: > > It seems we already have a mechanism in place that allows tuning of > > query cancel on standbys vs. preventing standby queries from seeing old > > data, specifically > > max_standby_streami

Re: [HACKERS] Manipulating complex types as non-contiguous structures in-memory

Attached is an 0.3 version, rebased over today's HEAD changes (applies to commit 9e3ad1aac52454569393a947c06be0d301749362 or later), and with some better logic for transferring expanded array values into and out of plpgsql functions. Using this example: create or replace function arraysetnum(n in

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

Hello, I had a look on gram.y and found other syntaxes using WITH option clause. At Wed, 11 Feb 2015 14:34:17 -0600, Jim Nasby wrote in <54dbbcc9.1020...@bluetreble.com> > I suspect at least some of this stems from how command line programs > tend to process options before arguments. I tend to a

Re: [HACKERS] pg_basebackup -x/X doesn't play well with archive_mode & wal_keep_segments

On Fri, Feb 13, 2015 at 9:18 AM, Andres Freund wrote: > On 2015-02-12 11:44:05 -0800, Sergey Konoplev wrote: >> On Thu, Feb 12, 2015 at 11:40 AM, Andres Freund >> wrote: >> > This obviously should not be the case. I'll have a look in a couple of >> > hours. Until then you can likely just work

Re: [HACKERS] We do not need pg_promote_v4_to_v6_addr/mask

Andrew Dunstan writes: > On 02/16/2015 09:07 PM, Tom Lane wrote: >> BTW, a bit of digging in the git logs and mail archives says that the code >> in question was originally added in 7.4 (commit 3c9bb8886df7d56a), in >> response to this discussion: >> http://www.postgresql.org/message-id/flat/20030

Re: [HACKERS] Expanding the use of FLEXIBLE_ARRAY_MEMBER for declarations like foo[1]

Andres Freund writes: > On 2015-02-17 05:51:22 +0900, Michael Paquier wrote: >> diff --git a/src/include/catalog/pg_authid.h >> b/src/include/catalog/pg_authid.h >> index e01e6aa..d8789a5 100644 >> --- a/src/include/catalog/pg_authid.h >> +++ b/src/include/catalog/pg_authid.h >> @@ -56,8 +56,10 @

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0

On Mon, Feb 16, 2015 at 4:11 PM, Peter Geoghegan wrote: >>> Jim Nasby said something about setting the HEAP_XMIN_INVALID hint bit. >>> Maybe he is right...if that can be made to be reliable (always >>> WAL-logged), it could be marginally better than setting xmin to >>> invalidTransactionId. >> >>

Re: [HACKERS] We do not need pg_promote_v4_to_v6_addr/mask

On 02/16/2015 09:07 PM, Tom Lane wrote: I wrote: We have some code in the server that attempts to match IPv4 address entries in pg_hba.conf to incoming connections that are in IPv6 protocol but have addresses in the range :::: (the IPv4-in-IPv6 subrange). As revealed by today's bug

Re: [HACKERS] We do not need pg_promote_v4_to_v6_addr/mask

I wrote: > We have some code in the server that attempts to match IPv4 address > entries in pg_hba.conf to incoming connections that are in IPv6 protocol > but have addresses in the range :::: (the IPv4-in-IPv6 > subrange). As revealed by today's bug report from Hugo Osvaldo Barrera, >

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

On 17/02/15 03:03, Andrew Dunstan wrote: On 02/16/2015 08:57 PM, Andrew Dunstan wrote: On 02/16/2015 08:48 PM, Petr Jelinek wrote: On 17/02/15 01:57, Peter Geoghegan wrote: On Mon, Feb 16, 2015 at 4:44 PM, Petr Jelinek wrote: We definitely want this feature, I wished to have this info many

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

On 17/02/15 02:57, Andrew Dunstan wrote: On 02/16/2015 08:48 PM, Petr Jelinek wrote: On 17/02/15 01:57, Peter Geoghegan wrote: On Mon, Feb 16, 2015 at 4:44 PM, Petr Jelinek wrote: We definitely want this feature, I wished to have this info many times. I would still like to see a benchmark.

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

On 02/16/2015 08:57 PM, Andrew Dunstan wrote: On 02/16/2015 08:48 PM, Petr Jelinek wrote: On 17/02/15 01:57, Peter Geoghegan wrote: On Mon, Feb 16, 2015 at 4:44 PM, Petr Jelinek wrote: We definitely want this feature, I wished to have this info many times. I would still like to see a benc

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

On 02/16/2015 08:48 PM, Petr Jelinek wrote: On 17/02/15 01:57, Peter Geoghegan wrote: On Mon, Feb 16, 2015 at 4:44 PM, Petr Jelinek wrote: We definitely want this feature, I wished to have this info many times. I would still like to see a benchmark. Average of 3 runs of read-only pgbenc

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

On 17/02/15 01:57, Peter Geoghegan wrote: On Mon, Feb 16, 2015 at 4:44 PM, Petr Jelinek wrote: We definitely want this feature, I wished to have this info many times. I would still like to see a benchmark. Average of 3 runs of read-only pgbench on my system all with pg_stat_statement act

Re: [HACKERS] Join push-down support for foreign tables

Let me put some comments in addition to where you're checking now. [design issues] * Cost estimation Estimation and evaluation of cost for remote join query is not an obvious issue. In principle, local side cannot determine the cost to run remote join without remote EXPLAIN, because local side has

[HACKERS] We do not need pg_promote_v4_to_v6_addr/mask

We have some code in the server that attempts to match IPv4 address entries in pg_hba.conf to incoming connections that are in IPv6 protocol but have addresses in the range :::: (the IPv4-in-IPv6 subrange). As revealed by today's bug report from Hugo Osvaldo Barrera, this code has been

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

On Mon, Feb 16, 2015 at 4:44 PM, Petr Jelinek wrote: > We definitely want this feature, I wished to have this info many times. I would still like to see a benchmark. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

On 21/01/15 17:32, Andrew Dunstan wrote: On 01/21/2015 11:21 AM, Arne Scheffer wrote: Why is it a bad thing to call the column "stddev_samp" analog to the aggregate function or make a note in the documentation, that the sample stddev is used to compute the solution? ... But I will add a n

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0

On Mon, Feb 16, 2015 at 12:00 AM, Heikki Linnakangas wrote: > So INSERT ON CONFLICT IGNORE on a table with an exclusion constraint might > fail. I don't like that. The point of having the command in the first place > is to deal with concurrency issues. If it sometimes doesn't work, it's > broken.

Re: [HACKERS] Expanding the use of FLEXIBLE_ARRAY_MEMBER for declarations like foo[1]

On 2015-02-17 05:51:22 +0900, Michael Paquier wrote: > - 0002 does the same for catalog tables > - 0003 changes varlena in c.h. This is done as a separate patch > because this needs some other modifications as variable-length things > need to be placed at the end of structures, because of: > -- rol

Re: [HACKERS] Commit fest 2015-12 enters money time

> On Tue, Feb 17, 2015 at 8:50 AM, Kouhei Kaigai wrote: > >> > I couldn't find operation to add new entry on the current CF. > >> > >> Go to the bottom of this CF: > >> https://commitfest.postgresql.org/4/ > >> Then click on "New patch". > >> > > I couldn't find the "New patch" link on both of IE

Re: [HACKERS] Commit fest 2015-12 enters money time

On Tue, Feb 17, 2015 at 8:50 AM, Kouhei Kaigai wrote: >> > I couldn't find operation to add new entry on the current CF. >> >> Go to the bottom of this CF: >> https://commitfest.postgresql.org/4/ >> Then click on "New patch". >> > I couldn't find the "New patch" link on both of IE and Chrome, > ev

Re: [HACKERS] Commit fest 2015-12 enters money time

> > I couldn't find operation to add new entry on the current CF. > > Go to the bottom of this CF: > https://commitfest.postgresql.org/4/ > Then click on "New patch". > I couldn't find the "New patch" link on both of IE and Chrome, even though I logged in. Did you do something special? Thanks, --

Re: [HACKERS] NULL checks of deferenced pointers in picksplit method of intarray

On Tue, Feb 17, 2015 at 6:49 AM, Kevin Grittner wrote: > Michael Paquier wrote: > >> Coverity is pointing out that _int_split.c has unnecessary checks >> for deferenced pointers in 5 places. > >> Attached is a patch to adjust those things. > > Pushed. Thanks! Thanks. >> Also, as far as I under

Re: [HACKERS] Commit fest 2015-12 enters money time

On Tue, Feb 17, 2015 at 7:39 AM, Kohei KaiGai wrote: > 2015-02-16 12:25 GMT+09:00 Michael Paquier : >> >> >> On Fri, Feb 13, 2015 at 10:06 AM, Michael Paquier >> wrote: >>> >>> In order to move on to the next CF, I am going to go through all the >>> remaining patches and update their status accor

Re: [HACKERS] Allow "snapshot too old" error, to prevent bloat

On 2015-02-16 16:35:46 -0500, Bruce Momjian wrote: > It seems we already have a mechanism in place that allows tuning of > query cancel on standbys vs. preventing standby queries from seeing old > data, specifically > max_standby_streaming_delay/max_standby_archive_delay. We obsessed > about how u

Re: [HACKERS] Issue installing doc tools on OSX

On 2/16/15 6:10 PM, Florian Pflug wrote: > BTW, why does the list of suggested packages include docbook-xml? That is used for building the man pages. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/p

Re: [HACKERS] Issue installing doc tools on OSX

On 2/16/15 6:10 PM, Florian Pflug wrote: > On Feb16, 2015, at 23:18 , Peter Eisentraut wrote: >> On 2/15/15 9:23 PM, David Steele wrote: That seems a bit incredible, since port should be able to resolve the dependencies by itself. I suggest that this should be reported as a bug to

Re: [HACKERS] Issue installing doc tools on OSX

On Feb16, 2015, at 23:18 , Peter Eisentraut wrote: > On 2/15/15 9:23 PM, David Steele wrote: >>> That seems a bit incredible, since port should be able to resolve the >>> dependencies by itself. I suggest that this should be reported as a bug >>> to MacPorts. >> >> Sure, that has been my experie

Re: [HACKERS] Using 128-bit integers for sum, avg and statistics aggregates

On 02/13/2015 02:07 PM, Michael Paquier wrote: Andreas, are you planning to continue working on this patch? Peter has provided some comments that are still unanswered. Yes, but I am quite busy right now. I will try to find time some time later this week. -- Andreas Karlsson -- Sent via pgs

Re: [HACKERS] Commit fest 2015-12 enters money time

2015-02-16 12:25 GMT+09:00 Michael Paquier : > > > On Fri, Feb 13, 2015 at 10:06 AM, Michael Paquier > wrote: >> >> In order to move on to the next CF, I am going to go through all the >> remaining patches and update their status accordingly. And sorry for >> slacking a bit regarding that. If you

Re: [HACKERS] GSoC 2015 - mentors, students and admins.

I'm interested in participating in gsoc 2015 as student. Sincerely, Ivanitskiy Ilya.

Re: [HACKERS] Issue installing doc tools on OSX

On 2/15/15 9:23 PM, David Steele wrote: >> That seems a bit incredible, since port should be able to resolve the >> dependencies by itself. I suggest that this should be reported as a bug >> to MacPorts. > > Sure, that has been my experience, but the error message was very clear. > Unfortunately

[HACKERS] Re: NULL checks of deferenced pointers in picksplit method of intarray

Michael Paquier wrote: > Coverity is pointing out that _int_split.c has unnecessary checks > for deferenced pointers in 5 places. > Attached is a patch to adjust those things. Pushed. Thanks! > Also, as far as I understood from this code, no elements > manipulated are NULL, perhaps this is wo

Re: [HACKERS] Allow "snapshot too old" error, to prevent bloat

On Sun, Feb 15, 2015 at 11:36:50AM -0500, Tom Lane wrote: > I wonder if we couldn't achieve largely the same positive effects through > adding a simple transaction-level timeout option. That would be far > easier for users to understand and manage, it would be trivial to allow > specific high-valu

Re: [HACKERS] Allow "snapshot too old" error, to prevent bloat

On 2/16/15 2:41 AM, Andres Freund wrote: Since you actually don't want cancellations for the long running reporting queries it very much might be sensible to switch to a more complicated version of HeapTupleSatisfiesVacuum() if there's longrunning queries. One that can recognize if rows are actua

Re: [HACKERS] Perl coding error in msvc build system?

> This patch been reviewed by 4 people, resulting in 2 minor suggestions > for changes (adding an m modifier, and removing a bogus last). > > It has 2 clear upvotes and 0 downvotes. > > I think it should be revised along the lines suggested and committed > without further ado. My patch actually

[HACKERS] Expanding the use of FLEXIBLE_ARRAY_MEMBER for declarations like foo[1]

Hi, In a lot of places in the code we have many structures doing declarations of the type foo[1] to emulate variable length arrays. Attached are a set of patches aimed at replacing that with FLEXIBLE_ARRAY_MEMBER to prevent potential failures that could be caused by compiler optimizations and impr

Re: [HACKERS] GSoC 2015 - mentors, students and admins.

I would also like to participate as a student. 2015-02-16 13:28 GMT-02:00 Dmitry Dolgov <9erthali...@gmail.com>: > I would like to participate as student. > > On 10 February 2015 at 03:52, Thom Brown wrote: > >> Hi all, >> >> Google Summer of Code 2015 is approaching. I'm intending on registeri

[HACKERS] Query Rewrite with Postgres' materialized views

Hello, Are there any plans for implementing query rewriting (i.e. allowing the optimizer to substitute materialized views for queries) in upcoming versions? I have recently seen this answer , saying that query rewriting cou

Re: [HACKERS] GSoC 2015 - mentors, students and admins.

I would like to participate as student. On 10 February 2015 at 03:52, Thom Brown wrote: > Hi all, > > Google Summer of Code 2015 is approaching. I'm intending on registering > PostgreSQL again this year. > > Before I do that, I'd like to have an idea of how many people are > interested in being

Re: [HACKERS] Really bad blowups with hash outer join and nulls

On 16.2.2015 03:38, Andrew Gierth wrote: >> "Tomas" == Tomas Vondra >> writes: > > Tomas> Improving the estimates is always good, but it's not going > to Tomas> fix the case of non-NULL values (it shouldn't be all > that Tomas> difficult to create such examples with a value whose > hash st

Re: [HACKERS] GSoC 2015 - mentors, students and admins.

On 13 February 2015 at 15:40, Thom Brown wrote: > > On 12 February 2015 at 14:55, Alexander Korotkov > wrote: > >> Hi! >> >> On Mon, Feb 9, 2015 at 11:52 PM, Thom Brown wrote: >> >>> Google Summer of Code 2015 is approaching. I'm intending on registering >>> PostgreSQL again this year. >>> >>>

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On 2015-02-16 20:55:20 +0900, Michael Paquier wrote: > On Mon, Feb 16, 2015 at 8:30 PM, Syed, Rahila > wrote: > > > > > Regarding the sanity checks that have been added recently. I think that > > they are useful but I am suspecting as well that only a check on the record > > CRC is done because t

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On 2015-02-16 11:30:20 +, Syed, Rahila wrote: > - * As a trivial form of data compression, the XLOG code is aware that > - * PG data pages usually contain an unused "hole" in the middle, which > - * contains only zero bytes. If hole_length > 0 then we have removed > - * such a "hole" from the

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On Mon, Feb 16, 2015 at 8:30 PM, Syed, Rahila wrote: > > Regarding the sanity checks that have been added recently. I think that > they are useful but I am suspecting as well that only a check on the record > CRC is done because that's reliable enough and not doing those checks > accelerates a bi

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

Hello, Thank you for reviewing and testing the patch. >+ /* leave if data cannot be compressed */ >+ if (compressed_len == 0) >+ return false; >This should be < 0, pglz_compress returns -1 when compression fails. > >+ if (pglz_decompress(block_image, bkpb->

Re: [HACKERS] Replication identifiers, take 4

On 2015-02-16 11:34:10 +0200, Heikki Linnakangas wrote: > Yes, thanks. Note to self and everyone else looking at this: It's important > to keep in mind is that the replication IDs are completely internal to the > local cluster. They are *not* sent over the wire. Well, if you *want* to, you could s

Re: [HACKERS] Replication identifiers, take 4

On 02/16/2015 11:18 AM, Andres Freund wrote: On 2015-02-16 11:07:09 +0200, Heikki Linnakangas wrote: How does this work if you have multiple replication systems in use in the same cluster? You might use Slony to replication one table to one system, and BDR to replication another table with anoth

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0

On 2015-02-16 10:00:24 +0200, Heikki Linnakangas wrote: > On 02/16/2015 02:44 AM, Peter Geoghegan wrote: > >>Are we happy with acquiring the SpeculativeInsertLock heavy-weight lock for > >>every insertion? That seems bad for performance reasons. Also, are we happy > >>with adding the new fields to

Re: [HACKERS] Replication identifiers, take 4

On 2015-02-16 11:07:09 +0200, Heikki Linnakangas wrote: > On 02/16/2015 02:21 AM, Andres Freund wrote: > >Furthermore the fact that the origin of records is recorded allows to > >avoid decoding them in logical decoding. That has both efficiency > >advantages (we can do so before they are stored in

Re: [HACKERS] Replication identifiers, take 4

On 02/16/2015 02:21 AM, Andres Freund wrote: Furthermore the fact that the origin of records is recorded allows to avoid decoding them in logical decoding. That has both efficiency advantages (we can do so before they are stored in memory/disk) and functionality advantages. Imagine using a logica

Re: [HACKERS] Allow "snapshot too old" error, to prevent bloat

On 2015-02-16 05:19:11 +, Kevin Grittner wrote: > Tom Lane wrote: > > Jim Nasby writes: > >> On 2/15/15 10:36 AM, Tom Lane wrote: > >>> I wonder if we couldn't achieve largely the same positive effects through > >>> adding a simple transaction-level timeout option. > > We suggested this to o

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0

On 02/16/2015 02:44 AM, Peter Geoghegan wrote: On Sat, Feb 14, 2015 at 2:06 PM, Heikki Linnakangas wrote: I did not solve the potential for livelocks (discussed at http://www.postgresql.org/message-id/cam3swztftt_fehet3tu3ykcpcypynnauquz3q+naasnh-60...@mail.gmail.com). The patch always super-de