Re: [HACKERS] vac truncation scan problems

On Mon, Mar 30, 2015 at 8:54 PM, Jeff Janes wrote: > After freeing up the rows at the end of the table so it is eligible for > truncation, then running a manual VACUUM to actually release the space, I > kept running into the problem that the truncation scan was consistently > suspended and then a

Re: [HACKERS] Maximum number of WAL files in the pg_xlog directory

On Tue, 3 Mar 2015 11:15:13 -0500 Bruce Momjian wrote: > On Tue, Oct 14, 2014 at 01:21:53PM -0400, Bruce Momjian wrote: > > On Tue, Oct 14, 2014 at 09:20:22AM -0700, Jeff Janes wrote: > > > On Mon, Oct 13, 2014 at 12:11 PM, Bruce Momjian wrote: > > > > > > > > > I looked into this, and cam

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

On Tue, Mar 31, 2015 at 9:40 AM, Peter Eisentraut wrote: > On 3/30/15 6:29 PM, Michael Paquier wrote: > > > > > > On Tue, Mar 31, 2015 at 5:39 AM, Peter Eisentraut > > wrote: > > > > On 3/25/15 1:32 AM, Michael Paquier wrote: > > > Well, I have no other cases than

[HACKERS] GUC context information in the document.

Hello, I had a question that whether a change of some GUC parameter needs restart or not and similar questions come every now and then. As shown below, descriptions about GUC context is surely put there but I believe the average reader of the document doesn't recognize that clearly while looking i

[HACKERS] vac truncation scan problems

After freeing up the rows at the end of the table so it is eligible for truncation, then running a manual VACUUM to actually release the space, I kept running into the problem that the truncation scan was consistently suspended and then aborted due to a conflicting lock requested/held. But the per

Re: [HACKERS] Relation extension scalability

On Mon, Mar 30, 2015 at 8:57 PM, Stephen Frost wrote: > > > If we're able to extend based on page-level locks rather than the global > relation locking that we're doing now, then I'm not sure we really need > to adjust how big the extents are any more. The reason for making > bigger extents is be

Re: [HACKERS] What exactly is our CRC algorithm?

On 25/03/15 18:24, Heikki Linnakangas wrote: On 03/25/2015 07:20 PM, Andres Freund wrote: On 2015-03-25 19:18:51 +0200, Heikki Linnakangas wrote: Or better yet, a direct configure test to check if the intrinsic exists - that way we get to also use it on Intel compilers, which I believe also has

[HACKERS] Cleanup double semicolons at the end of source lines

Hi, While reading the code I noticed couple of double semicolons at the end of lines so I searched for all of them and replaced them with single ones. The resulting diff is attached. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training

Re: [HACKERS] Streaming replication

> On 31/03/15 12:45, Tatsuo Ishii wrote: >> In the doc: >> >> 25.2.5. Streaming Replication >> : >> The standby connects to the primary, which streams WAL records to the >> standby as they're generated, without waiting for the WAL file to be >> filled. >> >> This seems to claim that walsender sen

Re: [HACKERS] Bug #10432 failed to re-find parent key in index

Hello, Just wondering if what Peter said was the last word on this? JD -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564 PostgreSQL Centered full stack support, consulting and development. Announcing "I'm offended" is basically telling the world you can't control your own e

Re: [HACKERS] PATCH: pgbench - merging transaction logs

On 29.3.2015 10:58, Fabien COELHO wrote: >>> So my overall conclusion is: >>> >>> (1) The simple thread-shared file approach would save pgbench from >>> post-processing merge-sort heavy code, for a reasonable cost. >> >> No it wouldn't - you're missing the fact that the proposed approach >> (share

[HACKERS] pg_rewind tests

There are some small issues with the pg_rewind tests. This technique check: all $(prove_check) :: local $(prove_check) :: remote for passing arguments to "prove" does not work with the tools included in Perl 5.8. While sorting out the portability issues in the TAP framework duri

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

On 3/30/15 6:29 PM, Michael Paquier wrote: > > > On Tue, Mar 31, 2015 at 5:39 AM, Peter Eisentraut > wrote: > > On 3/25/15 1:32 AM, Michael Paquier wrote: > > Well, I have no other cases than ones of the type mentioned upthread, > > and honestly I am fine as

Re: [HACKERS] Streaming replication

On 31/03/15 12:45, Tatsuo Ishii wrote: > In the doc: > > 25.2.5. Streaming Replication > : > The standby connects to the primary, which streams WAL records to the > standby as they're generated, without waiting for the WAL file to be > filled. > > This seems to claim that walsender sends WAL file

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

On 3/30/15 5:46 AM, Ronan Dunklau wrote: Hello hackers, I've tried my luck on pgsql-bugs before, with no success, so I report these problem here. The documentation mentions the following limits for sizes: Maximum Field Size 1 GB Maximum Row Size1.6 TB However, it seems like rows

[HACKERS] Streaming replication

In the doc: 25.2.5. Streaming Replication : The standby connects to the primary, which streams WAL records to the standby as they're generated, without waiting for the WAL file to be filled. This seems to claim that walsender sends WAL files which has not been fsync'd yet. However, in walsender.c

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Mon, Mar 30, 2015 at 7:41 PM, Jim Nasby wrote: > > On 3/27/15 2:23 PM, Fabrízio de Royes Mello wrote: >> >> Hi all, >> >> I'm tweaking some autovacuum settings in a table with high write usage >> but with ALTER TABLE .. SET ( .. ) this task was impossible, so I did a >> catalog update (pg_clas

Re: [HACKERS] How about to have relnamespace and relrole?

On 3/29/15 1:55 PM, Tom Lane wrote: Andrew Dunstan writes: I have just claimed this as committer in the CF, but on reviewing the emails it looks like there is disagreement about the need for it at all, especially from Tom and Robert. I confess I have often wanted regnamespace, particularly,

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

On Tue, Mar 31, 2015 at 07:29:07AM +0900, Michael Paquier wrote: > On Tue, Mar 31, 2015 at 5:39 AM, Peter Eisentraut wrote: > > > On 3/25/15 1:32 AM, Michael Paquier wrote: > > > Well, I have no other cases than ones of the type mentioned upthread, > > > and honestly I am fine as long as we do no

Re: [HACKERS] Bug fix for missing years in make_date()

On Mon, Mar 30, 2015 at 05:35:29PM -0500, Jim Nasby wrote: > On 3/26/15 5:26 PM, David Fetter wrote: > >+ * Note: Non-positive years are take to be BCE. > > s/take/taken/ Good point. Next patch attached. Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfette

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On 3/27/15 2:23 PM, Fabrízio de Royes Mello wrote: Hi all, I'm tweaking some autovacuum settings in a table with high write usage but with ALTER TABLE .. SET ( .. ) this task was impossible, so I did a catalog update (pg_class) to change reloptions. Maybe it's a stupid doubt, but why we need t

Re: [HACKERS] Implementing a join algorithm in Postgres

On 3/27/15 3:01 AM, Ravi Kiran wrote: I have written a C program which reads from 3 files(Each file is table having 2 columns and thousands of rows).The program is used to join those 3 tables and the algorithm which I have written will work only for those 3 files. Now I want to test this program

Re: [HACKERS] Bug fix for missing years in make_date()

On 3/26/15 5:26 PM, David Fetter wrote: +* Note: Non-positive years are take to be BCE. s/take/taken/ -- Jim Nasby, Data Architect, Blue Treble Consulting Data in Trouble? Get it in Treble! http://BlueTreble.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

On Tue, Mar 31, 2015 at 5:39 AM, Peter Eisentraut wrote: > On 3/25/15 1:32 AM, Michael Paquier wrote: > > Well, I have no other cases than ones of the type mentioned upthread, > > and honestly I am fine as long as we do not apply maths to a version > > string. So attached is a patch that adds VER

Re: [HACKERS] Vacuuming big btree indexes without pages with deleted items

On 3/27/15 5:15 AM, Vladimir Borodin wrote: Hi all. I have described [0] a problem with delaying replicas after vacuuming a relation with big btree index. It stucks in replaying WAL record of type XLOG_BTREE_VACUUM like that (with lastBlockVacuumed 0): rmgr: Btree len (rec/tot): 20/

Re: [HACKERS] Ignoring entries generated by autoconf in code tree

Peter Eisentraut writes: > On 3/25/15 10:34 AM, Tom Lane wrote: >> Michael Paquier writes: >>> When running autoconf from the root tree, autom4te.cache/ is >>> automatically generated. >>> Wouldn't it make sense to add an entry in .gitignore for that? >> Personally, I don't want such a thing, as

Re: [HACKERS] Ignoring entries generated by autoconf in code tree

On 3/25/15 10:34 AM, Tom Lane wrote: > Michael Paquier writes: >> When running autoconf from the root tree, autom4te.cache/ is >> automatically generated. >> Wouldn't it make sense to add an entry in .gitignore for that? > > Personally, I don't want such a thing, as then I would tend to forget >

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

On 3/25/15 1:32 AM, Michael Paquier wrote: > Well, I have no other cases than ones of the type mentioned upthread, > and honestly I am fine as long as we do not apply maths to a version > string. So attached is a patch that adds VERSION_NUM in > Makefile.global. How would you make use of this in a

Re: [HACKERS] proposal: searching in array function - array_position

2015-03-30 21:30 GMT+02:00 Alvaro Herrera : > Pavel Stehule wrote: > > 2015-03-22 11:30 GMT+01:00 Dean Rasheed : > > > > In the public docs, you should s/position/subscript because that's the > > > term used throughout the docs for an index into an array. I still like > > > the name array_position

Re: [HACKERS] [COMMITTERS] pgsql: Centralize definition of integer limits.

On 2015-03-30 15:38:16 -0400, Tom Lane wrote: > Michael Paquier writes: > > On Mon, Mar 30, 2015 at 7:48 PM, Andres Freund wrote: > >> On 2015-03-30 14:01:25 +0900, Michael Paquier wrote: > >>> My OSX dev box is generating a couple of warnings since this commit: > >>> pg_dump.c:14548:45: warning:

Re: [HACKERS] [COMMITTERS] pgsql: Centralize definition of integer limits.

Michael Paquier writes: > On Mon, Mar 30, 2015 at 7:48 PM, Andres Freund wrote: >> On 2015-03-30 14:01:25 +0900, Michael Paquier wrote: >>> My OSX dev box is generating a couple of warnings since this commit: >>> pg_dump.c:14548:45: warning: format specifies type 'long' but the >>> argument has t

Re: [HACKERS] proposal: searching in array function - array_position

Pavel Stehule wrote: > 2015-03-22 11:30 GMT+01:00 Dean Rasheed : > > In the public docs, you should s/position/subscript because that's the > > term used throughout the docs for an index into an array. I still like > > the name array_position() for the function though, because it's > > consistent

Re: [HACKERS] Error with index on unlogged table

Michael Paquier wrote: > On Thu, Mar 26, 2015 at 1:02 AM, Fabrízio de Royes Mello > wrote: > > I didn't found any other similar bug introduced by 85b506bb. > > > > Attached the original patch provided by Michael with some regression tests. > > Thanks for adding a test, this looks fine to me (did

Re: [HACKERS] Bug #10432 failed to re-find parent key in index

On Mon, Mar 30, 2015 at 7:50 PM, Joshua D. Drake wrote: > We have a database that has run into this problem. The version is 9.1.15 on > Linux. I note in this thread: > > http://www.postgresql.org/message-id/cam-w4hp34ppwegtcwjbznwhq0cmu-lxna62vjku8qrtwlob...@mail.gmail.com > > That things appear t

[HACKERS] Bug #10432 failed to re-find parent key in index

Hello, We have a database that has run into this problem. The version is 9.1.15 on Linux. I note in this thread: http://www.postgresql.org/message-id/cam-w4hp34ppwegtcwjbznwhq0cmu-lxna62vjku8qrtwlob...@mail.gmail.com That things appear to be fixed in 9.4 but they have not been back-patched?

[HACKERS] WAL format changes break the suppression of do-nothing checkpoints.

commit 2c03216d831160bedd72d45f7 has invalidated the part of the docs saying "If no WAL has been written since the previous checkpoint, new checkpoints will be skipped even if checkpoint_timeout has passed", presumably by accident. It seems that this part is no longer true when it should be true:

Re: [HACKERS] INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0

On Sat, Mar 28, 2015 at 6:36 PM, Andres Freund wrote: > Just had a longer chat with Peter about this patch. It was a very useful chat. Thanks for making yourself available to do it. > * Not a fan of the heap flags usage, the reusage seems sketch to me > * Explain should show the arbiter index in

Re: [HACKERS] WIP: SCRAM authentication

* Heikki Linnakangas (hlinn...@iki.fi) wrote: > There have been numerous threads on replacing our MD5 authentication > method, so I started hacking on that to see what it might look like. > Just to be clear, this is 9.6 material. Attached is a WIP patch > series that adds support for SCRAM. There's

Re: [HACKERS] Relation extension scalability

* David Steele (da...@pgmasters.net) wrote: > On 3/30/15 6:45 AM, Andres Freund wrote: > > On 2015-03-30 09:33:57 +0530, Amit Kapila wrote: > >> Another thing to note here is that during extension we are extending > >> just one block, won't it make sense to increment it by some bigger > >> number (

Re: [HACKERS] Parallel Seq Scan

On Wed, Mar 25, 2015 at 6:27 AM, Amit Kapila wrote: > Apart from that I have moved the Initialization of dsm segement from > InitNode phase to ExecFunnel() (on first execution) as per suggestion > from Robert. The main idea is that as it creates large shared memory > segment, so do the work when

Re: [HACKERS] Parallel Seq Scan

On Wed, Mar 18, 2015 at 11:43 PM, Amit Kapila wrote: >> I think I figured out the problem. That fix only helps in the case >> where the postmaster noticed the new registration previously but >> didn't start the worker, and then later notices the termination. >> What's much more likely to happen i

Re: [HACKERS] Parallel Seq Scan

On Fri, Mar 27, 2015 at 2:34 AM, Amit Kapila wrote: > The reason of this problem is that above tab-completion is executing > query [1] which contains subplan for the funnel node and currently > we don't have capability (enough infrastructure) to support execution > of subplans by parallel workers.

Re: [HACKERS] Concurrent calls of _hash_getnewbuf()

Antonin Houska writes: > When doing my experiments with bucket split ([1]), I noticed a comment that > _hash_getnewbuf should not be called concurrently. However, there's no > synchronization of calls from _hash_splitbucket in HEAD. I could reproduce > such concurrent calls using gdb (multiple buc

Re: [HACKERS] Relation extension scalability

On 3/30/15 6:45 AM, Andres Freund wrote: > On 2015-03-30 09:33:57 +0530, Amit Kapila wrote: >> Another thing to note here is that during extension we are extending >> just one block, won't it make sense to increment it by some bigger >> number (we can even take input from user for the same where us

Re: [HACKERS] getting rid of "thread fork emulation" in pgbench?

On Mon, Mar 30, 2015 at 2:00 AM, Fabien COELHO wrote: >> I really, really wish you'd stop arguing against the patch to allow >> merging of pgbench logs in this basis. > > Hmmm. I'm lost. I thought that discussing how to best implement a feature > was part of reviewing a patch. Of course it is. B

Re: [HACKERS] Combining Aggregates

On 30 March 2015 at 01:08, David Rowley wrote: > On 18 December 2014 at 02:48, Simon Riggs wrote: >> >> David, if you can update your patch with some docs to explain the >> behaviour, it looks complete enough to think about committing it in >> early January, to allow other patches that depend upo

[HACKERS] pg_dump / copy bugs with "big lines" ?

Hello hackers, I've tried my luck on pgsql-bugs before, with no success, so I report these problem here. The documentation mentions the following limits for sizes: Maximum Field Size 1 GB Maximum Row Size1.6 TB However, it seems like rows bigger than 1GB can't be COPYed out: ro=#

Re: [HACKERS] Relation extension scalability

On 2015-03-30 09:33:57 +0530, Amit Kapila wrote: > In the past, I have observed in one of the Write-oriented tests that > backend's have to flush the pages by themselves many a times, so > in above situation that can lead to more severe bottleneck. Yes. > > I've prototyped solving this for heap r

Re: [HACKERS] Index-only scans with btree_gist

On 03/29/2015 04:30 AM, Andreas Karlsson wrote: On 03/29/2015 03:25 AM, Andreas Karlsson wrote: On 03/28/2015 09:36 PM, Andreas Karlsson wrote: Thanks! Do you know if it is possible to add index-only scan support to range indexes? I have never looked at those and do not know if they are lossy.

[HACKERS] Concurrent calls of _hash_getnewbuf()

When doing my experiments with bucket split ([1]), I noticed a comment that _hash_getnewbuf should not be called concurrently. However, there's no synchronization of calls from _hash_splitbucket in HEAD. I could reproduce such concurrent calls using gdb (multiple bucket splits in progress at a time

Re: [HACKERS] Rounding to even for numeric data type

Michael Paquier wrote: > Well, I am not sure about that... But reading this thread changing the > default rounding sounds unwelcome. So it may be better to just put in > words the rounding method used now in the docs, with perhaps a mention > that this is not completely in-line with the SQL spec if