Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

I wrote: > Michael Paquier writes: >> Yes, that's the problem. Instead of using details(), summary() is >> enough actually. And it is enough to let caller know the failure when >> just one test has been found as not passing. See attached. > This one works for me on

Re: [HACKERS] [PATCH] Logical decoding support for sequence advances

On 1 March 2016 at 05:30, Petr Jelinek wrote: > > On 29/02/16 03:23, Craig Ringer wrote: >> >> > Sound reasonable? >> > > I wonder if it would be acceptable to create new info flag for RM_SEQ_ID > that would behave just like XLOG_SEQ_LOG but would be used only for the >

Re: [HACKERS][REVIEW]: Password identifiers, protocol aging and SCRAM protocol

On Wed, Mar 2, 2016 at 4:05 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote: > [...] Thanks for the review. > The default value contains "scram". Shouldn't be here also: > >>Specifies a comma-separated list of supported password formats by >>the server. Supported formats are

Re: [HACKERS] 2016-03 Commitfest Manager

On Wed, Mar 02, 2016 at 03:34:39PM +0900, Michael Paquier wrote: > On Wed, Mar 2, 2016 at 2:53 PM, David Fetter wrote: > > On Wed, Mar 02, 2016 at 10:49:01AM +0900, Michael Paquier wrote: > >> On Wed, Mar 2, 2016 at 7:22 AM, Michael Paquier > >>

Re: [HACKERS] Incorrect error message in InitializeSessionUserId

On Tue, Mar 1, 2016 at 10:21 PM, Dmitriy Sarafannikov wrote: > I have found incorrect error message in InitializeSessionUserId function > if you try to connect to database by role Oid (for example > BackgroundWorkerInitializeConnectionByOid). > If role have no permissions to

Re: [HACKERS] 2016-03 Commitfest Manager

On Wed, Mar 2, 2016 at 2:53 PM, David Fetter wrote: > On Wed, Mar 02, 2016 at 10:49:01AM +0900, Michael Paquier wrote: >> On Wed, Mar 2, 2016 at 7:22 AM, Michael Paquier >> wrote: >> > On Wed, Mar 2, 2016 at 6:15 AM, David Steele

Re: [HACKERS] Publish autovacuum informations

On Tue, Mar 1, 2016 at 11:37 PM, Julien Rouhaud wrote: > I'm not sure what are the fancy things that Michael had in mind with > exposing the private structure. Michael, was it something like having > the ability to change some of these data through an extension? I was referring to you here :) I

Re: [HACKERS] GetExistingLocalJoinPath() vs. the docs

I think that you need to take a little broader look at this section. > At the top, it says "To use any of these functions, you need to > include the header file foreign/foreign.h in your source file", but > this function is defined in foreign/fdwapi.h. It's not clear to me > whether we should

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

Michael Paquier writes: > Yes, that's the problem. Instead of using details(), summary() is > enough actually. And it is enough to let caller know the failure when > just one test has been found as not passing. See attached. This one works for me on RHEL6. Pushed;

Re: [HACKERS] 2016-03 Commitfest Manager

On Wed, Mar 02, 2016 at 10:49:01AM +0900, Michael Paquier wrote: > On Wed, Mar 2, 2016 at 7:22 AM, Michael Paquier > wrote: > > On Wed, Mar 2, 2016 at 6:15 AM, David Steele wrote: > >> On 3/1/16 3:04 PM, Tom Lane wrote: > >>> David Steele

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

On Wed, Mar 2, 2016 at 2:10 AM, Anastasia Lubennikova wrote: > 01.03.2016 19:55, Anastasia Lubennikova: >> It is not the final version, because it breaks pg_dump for previous >> versions. I need some help from hackers here. >> pgdump. line 5466 >> if

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

On 2 March 2016 at 13:22, Michael Paquier wrote: > On Wed, Mar 2, 2016 at 2:18 PM, Alvaro Herrera > wrote: > > Tom Lane wrote: > >> I wrote: > >> > Can't use string ("Test::Builder") as a HASH ref while "strict refs" > in use at

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Wed, Mar 2, 2016 at 10:39 AM, Andres Freund wrote: > Sounds like a ppc vs. x86 issue. The regression was on the former, right? Well, Regression what I reported last two time, out of that one was on X86 and other was on PPC. Copied from older Threads

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

On Wed, Mar 2, 2016 at 2:18 PM, Alvaro Herrera wrote: > Tom Lane wrote: >> I wrote: >> > Can't use string ("Test::Builder") as a HASH ref while "strict refs" in >> > use at /usr/share/perl5/Test/Builder.pm line 1798. >> >> > The referenced line number is the end of the

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

Tom Lane wrote: > I wrote: > > Can't use string ("Test::Builder") as a HASH ref while "strict refs" in use > > at /usr/share/perl5/Test/Builder.pm line 1798. > > > The referenced line number is the end of the file, > > Oh, scratch that; I was looking at the wrong file. Actually, >

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On March 1, 2016 8:41:33 PM PST, Dilip Kumar wrote: >On Tue, Mar 1, 2016 at 10:19 AM, Dilip Kumar >wrote: > >> >> OK, I will test it, sometime in this week. >> > >I have tested this patch in my laptop, and there i did not see any >regression at 1

[HACKERS] Recovery test failure for recovery_min_apply_delay on hamster

Hi all, I have enabled yesterday the recovery test suite on hamster, and we did not have to wait long before seeing the first failure on it, the machine being slow as hell so it is quite good at catching race conditions:

Re: [HACKERS] Relation extension scalability

On Tue, Mar 1, 2016 at 4:36 PM, Amit Kapila wrote: > One thing that is slightly unclear is that whether there is any overhead > due to buffer eviction especially when the buffer to be evicted is already > dirty and needs XLogFlush(). One reason why it might not hurt is

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

Hi 2016-03-01 18:48 GMT+01:00 Catalin Iacob : > On 3/1/16, Pavel Stehule wrote: > >> I though about it before and I prefer variant with possibility to enter > >> message as keyword parameter. > > That's also ok, but indeed with a check that it's

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

Craig Ringer writes: > Really, really this time, the version in git that actually works, not a > format-patch'd version before I made a last fix. Sigh. I can't even blame > lack of coffee... Hmm, still doesn't work for me: make check-world dies with Can't use string

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

On Wed, Mar 2, 2016 at 1:33 PM, Tom Lane wrote: > Craig Ringer writes: >> This upset buildfarm members running prehistoric Perl versions because >> is_passing was added after 5.8.8. > > Sir, RHEL6 is not prehistoric ... and this is failing on my server

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

On Tue, Mar 1, 2016 at 8:13 PM, Aleksander Alekseev < a.aleks...@postgrespro.ru> wrote: > > Hello, Amit > > > I am not sure, if this is exactly what has been suggested by Robert, > > so it is not straightforward to see if his suggestion can allow us to > > use NUM_FREELISTS as 8 rather than 32. I

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Tue, Mar 1, 2016 at 10:19 AM, Dilip Kumar wrote: > > OK, I will test it, sometime in this week. > I have tested this patch in my laptop, and there i did not see any regression at 1 client Shared buffer 10GB, 5 mins run with pgbench, read-only test base

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

Craig Ringer writes: > This upset buildfarm members running prehistoric Perl versions because > is_passing was added after 5.8.8. Sir, RHEL6 is not prehistoric ... and this is failing on my server too. I'm not sure when "is_passing" was added, but it was later than 5.10.1.

Re: [HACKERS] 2016-03 Commitfest Manager

On 02/03/16 17:01, Michael Paquier wrote: On Wed, Mar 2, 2016 at 11:25 AM, David Steele wrote: Agreed. I see you created the new CF so no reason to keep it open. OK. Done. May the force to manage all those patches be with you, manager. May the Source be with you

Re: [HACKERS] 2016-03 Commitfest Manager

On Wed, Mar 2, 2016 at 11:25 AM, David Steele wrote: > Agreed. I see you created the new CF so no reason to keep it open. OK. Done. May the force to manage all those patches be with you, manager. -- Michael -- Sent via pgsql-hackers mailing list

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

On 2 March 2016 at 10:07, Craig Ringer wrote: > On 2 March 2016 at 05:46, Alvaro Herrera wrote: > > >> >> I think we should change the existing psql method to be what you propose >> as psql_expert. I don't see any advantage in keeping the old

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

On 2 March 2016 at 11:23, Craig Ringer wrote: > Really, this time. > Really, really this time, the version in git that actually works, not a format-patch'd version before I made a last fix. Sigh. I can't even blame lack of coffee... -- Craig Ringer

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

On 2 March 2016 at 11:22, Craig Ringer wrote: > 2016-03-02 6:57 GMT+08:00 Alvaro Herrera : > >> Just pushed 0006. >> >> > This upset buildfarm members running prehistoric Perl versions because > is_passing was added after 5.8.8. > > Fix attached.

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

2016-03-02 6:57 GMT+08:00 Alvaro Herrera : > Just pushed 0006. > > This upset buildfarm members running prehistoric Perl versions because is_passing was added after 5.8.8. Fix attached. I think I'm going to have to do an archaeology-grade Perl install, there's just too

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

On Thu, Feb 18, 2016 at 3:45 AM, Masahiko Sawada wrote: > Attached updated 5 patches. > I would like to explain these patch shortly again here to make > reviewing more easier. > > We can divided these patches into 2 purposes. > > 1. Freeze map > 000_ patch adds additional

Re: [HACKERS] Random inconsistencies in GiST support function declarations

On Mon, Jan 18, 2016 at 2:29 PM, Tom Lane wrote: > > Fixing the pg_proc entries in HEAD seems like no big deal, but some of > the errors are in contrib modules. If we wanted to be really clean > about that, we'd have to bump those modules' extension versions, which > is a

Re: [HACKERS] 2016-03 Commitfest Manager

On 3/1/16 8:49 PM, Michael Paquier wrote: > On Wed, Mar 2, 2016 at 7:22 AM, Michael Paquier > wrote: >> On Wed, Mar 2, 2016 at 6:15 AM, David Steele wrote: >>> On 3/1/16 3:04 PM, Tom Lane wrote: David Steele writes: >

Re: [HACKERS] Equivalent of --enable-tap-tests in MSVC scripts

On Wed, Mar 2, 2016 at 12:40 AM, Andrew Dunstan wrote: > On 03/01/2016 08:00 AM, Michael Paquier wrote: >> As of now the MSVC scripts control if TAP tests are enabled or not >> using a boolean flag as $config->{tap_tests}. However, this flag is >> just taken into account in

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

On 2 March 2016 at 05:46, Alvaro Herrera wrote: > > I think we should change the existing psql method to be what you propose > as psql_expert. I don't see any advantage in keeping the old one. Many > of the existing uses of psql should become what you call

Re: [HACKERS] 2016-03 Commitfest Manager

On Wed, Mar 2, 2016 at 7:22 AM, Michael Paquier wrote: > On Wed, Mar 2, 2016 at 6:15 AM, David Steele wrote: >> On 3/1/16 3:04 PM, Tom Lane wrote: >>> David Steele writes: I volunteered a while back to be the CFM and I

Re: [HACKERS] Addition of extra commit fest entry to park future patches

On Wed, Mar 2, 2016 at 5:46 AM, Magnus Hagander wrote: > Yes, it's trivial to rename. That's the only advantage of our ugly url > scheme which uses the surrogate key in the url instead of the actual name of > the CF :) 2016-09 has been created then:

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

On 2 March 2016 at 07:07, Alvaro Herrera wrote: > Craig Ringer wrote: > > > diff --git a/src/test/perl/TestLib.pm b/src/test/perl/TestLib.pm > > index 3d11cbb..8c13655 100644 > > --- a/src/test/perl/TestLib.pm > > +++ b/src/test/perl/TestLib.pm > > @@ -112,9 +112,11 @@

Re: [HACKERS] The plan for FDW-based sharding

Hi, On 03/01/2016 08:02 PM, Bruce Momjian wrote: On Tue, Mar 1, 2016 at 07:56:58PM +0100, Petr Jelinek wrote: Note that I am not saying that other discussed approaches are any better, I am saying that we should know approximately what we actually want and not just beat FDWs with a hammer and

[HACKERS] pl/tcl Unicode conversion doesn't actually work?

I'd always sort of assumed that the UTF_U2E() / UTF_E2U() macros in pltcl.c were enabled by default. I just realized that that isn't so: they're enabled by a test #if defined(UNICODE_CONVERSION) && HAVE_TCL_VERSION(8,1) UNICODE_CONVERSION is defined nowhere in our sources, and I can find no

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

Craig Ringer wrote: > diff --git a/src/test/perl/TestLib.pm b/src/test/perl/TestLib.pm > index 3d11cbb..8c13655 100644 > --- a/src/test/perl/TestLib.pm > +++ b/src/test/perl/TestLib.pm > @@ -112,9 +112,11 @@ INIT > # > sub tempdir > { > + my ($prefix) = @_; > + $prefix = "tmp_test" if

Re: [HACKERS] Convert pltcl from strings to objects

Victor Wagner writes: > On Mon, 22 Feb 2016 17:57:36 -0600 > Jim Nasby wrote: >> Is there any backwards compatibility risk to these changes? Could >> having that new info break someone's existing code? > I don't think so. ErrorCode and ErrorInfo

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

Just pushed 0006. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] 2016-03 Commitfest Manager

On Wed, Mar 2, 2016 at 6:15 AM, David Steele wrote: > On 3/1/16 3:04 PM, Tom Lane wrote: >> David Steele writes: >>> I volunteered a while back to be the CFM and I haven't seen any other >>> volunteers or objections to my offer. >> >>> I am still ready,

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

Craig Ringer wrote: > Hi all > > I've been working with the new TAP tests for recovery and have a number of > enhancements I'd like to make to the tooling to make writing tests easier > and nicer. I think we should change the existing psql method to be what you propose as psql_expert. I don't

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

"Daniel Verite" writes: > I've tried adding another large field to see what happens if the whole row > exceeds 2GB, and data goes to the client rather than to a file. > My idea was to check if the client side was OK with that much data on > a single COPY row, but it turns

Re: [HACKERS] [NOVICE] WHERE clause not used when index is used

Sorry to keep coming back to this, but I just realized that the next para in _bt_preprocess_keys' doco explains yet another way in which this patch is broken: * Note that one reason we need direction-sensitive required-key flags is * precisely that we may not be able to eliminate redundant

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

I wrote: > If splitting the table into 3 fields, each smaller than 512MB: > > postgres=# create table big2 as select > substring(binarycol from 1 for 300*1024*1024) as b1, > substring(binarycol from 1+300*1024*1024 for 300*1024*1024) as b2 , > substring(binarycol from 1+600*1024*1024

Re: [HACKERS] Publish autovacuum informations

On 3/1/16 3:02 PM, Julien Rouhaud wrote: You mean for database wide vacuum? I mean manual vacuum. Some hooks and stats would apply only to autovac obviously (and it'd be nice to get visibility into the scheduling decisions both daemons are making). But as much as possible things should be

Re: [HACKERS] Improve error handling in pltcl

On 2/29/16 10:01 PM, Tom Lane wrote: Jim Nasby writes: On 2/28/16 5:50 PM, Jim Nasby wrote: Per discussion in [1], this patch improves error reporting in pltcl. I forgot to mention that this work is sponsored by Flight Aware (http://flightaware.com). Huh ... I

Re: [HACKERS] [NOVICE] WHERE clause not used when index is used

I wrote: > I believe the way to fix this would be to stop regarding SK_BT_MATCHED > as state, and instead treat it as a scankey property identified during > _bt_preprocess_keys, analogously to SK_BT_REQFWD/SK_BT_REQBKWD --- and, > like those, you'd need two flags not one since the properties will

Re: [HACKERS] 2016-03 Commitfest Manager

On 3/1/16 3:04 PM, Tom Lane wrote: > David Steele writes: >> I volunteered a while back to be the CFM and I haven't seen any other >> volunteers or objections to my offer. > >> I am still ready, eager, and willing! > > I haven't heard any other volunteers either. You have

Re: [HACKERS] psql completion for ids in multibyte string

On Wed, Mar 2, 2016 at 7:54 AM, Robert Haas wrote: > On Mon, Feb 29, 2016 at 6:32 PM, Thomas Munro > wrote: >> On Fri, Feb 26, 2016 at 6:34 PM, Kyotaro HORIGUCHI >> wrote: >>> Hello, this is the second patch

Re: [HACKERS] Publish autovacuum informations

On 01/03/2016 20:29, Jim Nasby wrote: > On 3/1/16 8:37 AM, Julien Rouhaud wrote: >>> > >>> >We understood (IMHO is an interesting idea) but as Michael said >>> hooks is >>> >for a general purpose. So can you demonstrate other use cases for this >>> >new hooks? >>> > >> I can think of several

Re: [HACKERS] Addition of extra commit fest entry to park future patches

On Tue, Mar 1, 2016 at 3:40 PM, Tom Lane wrote: > Magnus Hagander writes: > > On Tue, Mar 1, 2016 at 10:12 AM, Alvaro Herrera < > alvhe...@2ndquadrant.com> > > wrote: > >> Magnus Hagander wrote: > >>> Yeah, we can do that. I'd suggest we either name it

Re: [HACKERS] Addition of extra commit fest entry to park future patches

Magnus Hagander writes: > On Tue, Mar 1, 2016 at 10:12 AM, Alvaro Herrera > wrote: >> Magnus Hagander wrote: >>> Yeah, we can do that. I'd suggest we either name it based on the current >>> tentative date for CF1 (september), or name it specificaly

Re: [HACKERS] Addition of extra commit fest entry to park future patches

On 3/1/16 3:35 PM, Kevin Grittner wrote: > On Tue, Mar 1, 2016 at 2:28 PM, Magnus Hagander wrote: >> On Tue, Mar 1, 2016 at 10:12 AM, Alvaro Herrera >> wrote: >>> Magnus Hagander wrote: > I'd suggest we either name it based on the current

Re: [HACKERS] Addition of extra commit fest entry to park future patches

On 3/1/16 3:28 PM, Magnus Hagander wrote: > On Tue, Mar 1, 2016 at 10:12 AM, Alvaro Herrera > Magnus Hagander wrote: > > > Yeah, we can do that. I'd suggest we either name it based on the current > > tentative date for CF1 (september), or name it specificaly "9.7-first" > or > >

Re: [HACKERS] Addition of extra commit fest entry to park future patches

On Tue, Mar 1, 2016 at 2:28 PM, Magnus Hagander wrote: > On Tue, Mar 1, 2016 at 10:12 AM, Alvaro Herrera > wrote: >> Magnus Hagander wrote: >>> I'd suggest we either name it based on the current tentative >>> date for CF1 (september), or name it

Re: [HACKERS] Addition of extra commit fest entry to park future patches

On Tue, Mar 1, 2016 at 10:12 AM, Alvaro Herrera wrote: > Magnus Hagander wrote: > > On Tue, Mar 1, 2016 at 8:09 AM, Michael Paquier < > michael.paqu...@gmail.com> > > wrote: > > > > > Hi all, > > > > > > I guess that commit fest 2016-03 is going to begin soon, at which

Re: [HACKERS] 2016-03 Commitfest Manager

David Steele writes: > I volunteered a while back to be the CFM and I haven't seen any other > volunteers or objections to my offer. > I am still ready, eager, and willing! I haven't heard any other volunteers either. You have the conn, sir.

Re: [HACKERS] [NOVICE] WHERE clause not used when index is used

I wrote: > Petr Jelinek writes: >> I can only get the issue when the sort order of the individual keys does >> not correlate and the operator sorts according to the first column and >> there are duplicate values for the first column. > Yeah, I think the combination of ASC

[HACKERS] 2016-03 Commitfest Manager

I volunteered a while back to be the CFM and I haven't seen any other volunteers or objections to my offer. I am still ready, eager, and willing! -- -David da...@pgmasters.net signature.asc Description: OpenPGP digital signature

Re: [HACKERS] PROPOSAL: Fast temporary tables

As far as I know we are trying to kill two birds with one stone: 1. Reduce overhead of accessing temporary tables 2. Make it possible to create temporary tables on replica. Replicas with hot-standby are widely used for running read-only OLAP queries. But such queries usually stores intermediate

Re: [HACKERS] Publish autovacuum informations

On 3/1/16 8:37 AM, Julien Rouhaud wrote: > >We understood (IMHO is an interesting idea) but as Michael said hooks is >for a general purpose. So can you demonstrate other use cases for this >new hooks? > I can think of several usage. First, since the hook will always be called, an extension

Re: [HACKERS] The plan for FDW-based sharding

On 03/01/2016 09:19 PM, Petr Jelinek wrote: Since this thread heavily discusses the XTM, I have question about the XTM as proposed because one thing is very unclear to me - what happens when user changes the XTM plugin on the server? I didn't see any xid handover API which makes me wonder if

Re: [HACKERS] PROPOSAL: Fast temporary tables

On 3/1/16 10:05 AM, Atri Sharma wrote: Fair point, that means inventing a whole new OID generation structure.. Generation is just the tip of the iceberg. You still need the equivalent to foreign keys (ie: pg_depend). While you would never have a permanent object depend on a temp object, the

Re: Commitfest Bug (was: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)

On Tue, Mar 1, 2016 at 7:27 AM, Tom Lane wrote: > +1 for not moving such patches to the new CF until the author does > something --- at which point they'd change to "Needs Review" state. > But we should not change them into that state without author input. > And I don't see

Re: [HACKERS] The plan for FDW-based sharding

On Tue, Mar 1, 2016 at 02:02:44PM -0500, Bruce wrote: > On Tue, Mar 1, 2016 at 07:56:58PM +0100, Petr Jelinek wrote: > > Note that I am not saying that other discussed approaches are any > > better, I am saying that we should know approximately what we > > actually want and not just beat FDWs

Re: [HACKERS][REVIEW]: Password identifiers, protocol aging and SCRAM protocol

On 1 March 2016 at 06:34, Michael Paquier wrote: > On Mon, Feb 29, 2016 at 8:43 PM, Valery Popov > wrote: > > vpopov@vpopov-Ubuntu:~/Projects/pwdtest/postgresql$ git branch > > Thanks for the input! > > >

Re: [HACKERS] The plan for FDW-based sharding

On Tue, Mar 1, 2016 at 07:56:58PM +0100, Petr Jelinek wrote: > Note that I am not saying that other discussed approaches are any > better, I am saying that we should know approximately what we > actually want and not just beat FDWs with a hammer and hope sharding > will eventually emerge and call

Re: [HACKERS] Reduce lock levels others reloptions in ALTER TABLE

On Mon, Feb 29, 2016 at 12:58 PM, Fabrízio de Royes Mello wrote: > Some time ago we added [1] the infrastructure to allow different lock levels > for relation options. > > So per discussion [2] the attached patch reduce lock levels down to > ShareUpdateExclusiveLock for:

Re: [HACKERS] The plan for FDW-based sharding

On 27/02/16 04:54, Robert Haas wrote: On Fri, Feb 26, 2016 at 10:56 PM, Konstantin Knizhnik wrote: We do not have formal prove that proposed XTM is "general enough" to handle all possible transaction manager implementations. But there are two general ways of dealing

Re: [HACKERS] psql completion for ids in multibyte string

On Mon, Feb 29, 2016 at 6:32 PM, Thomas Munro wrote: > On Fri, Feb 26, 2016 at 6:34 PM, Kyotaro HORIGUCHI > wrote: >> Hello, this is the second patch plitted out. This allows >> multibyte names to be completed in psql. >> >> At Fri,

Re: [HACKERS] [NOVICE] WHERE clause not used when index is used

I wrote: > I'm not sure if the costing change is a bug or not --- the non-bitmap scan > does seem to be cheaper in reality, but not by a couple orders of > magnitude as the planner now thinks. Ah, scratch that, I wasn't looking closely enough. The 9.4 plan is an IndexScan whereas 9.5+ uses

Re: [HACKERS] Fixing wrong comment on PQmblen and PQdsplen.

On Fri, Feb 26, 2016 at 12:33 AM, Kyotaro HORIGUCHI wrote: > I divided the last patch into one typo-fix patch and one > improvement patch. This is the former one. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL

Re: [HACKERS] [NOVICE] WHERE clause not used when index is used

Petr Jelinek writes: > On 01/03/16 18:37, Tom Lane wrote: >> However, I'm not sure that's 100% of the issue, because in playing around >> with this I was having a harder time reproducing the failure outside of >> Tobias' example than I expected. There may be more than one

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

On Mon, Feb 29, 2016 at 8:01 AM, Amit Kapila wrote: > On Thu, Feb 25, 2016 at 2:54 AM, Peter Eisentraut wrote: >> >> Could you enhance the documentation about the difference between "wait >> event type name" and "wait event name" (examples?)? >> > > I am

Re: [HACKERS] A trivial fix on extensiblenode

On Mon, Feb 29, 2016 at 4:07 AM, Kouhei Kaigai wrote: > RegisterExtensibleNodeMethods() initializes its hash table > with keysize=NAMEDATALEN, instead of EXTNODENAME_MAX_LEN. > > The attached patch fixes it. Oops. Thanks, committed. -- Robert Haas EnterpriseDB:

Re: [HACKERS] The plan for FDW-based sharding

On 01/03/16 18:18, Konstantin Knizhnik wrote: On 01.03.2016 19:03, Robert Haas wrote: On Tue, Mar 1, 2016 at 10:37 AM, Bruce Momjian wrote: On Tue, Mar 1, 2016 at 10:19:45AM -0500, Robert Haas wrote: Two reasons: 1. There is no ideal implementation of DTM which will fit

Re: [HACKERS] extend pgbench expressions with functions

On Wed, Feb 17, 2016 at 3:22 AM, Fabien COELHO wrote: > Indeed. My gcc 4.8.4 with --Wall does not show the warning, too bad. > > Attached is the fixed patch for the array method. Committed with a few tweaks, including running pgindent over some of it. -- Robert Haas

Re: [HACKERS] [NOVICE] WHERE clause not used when index is used

On 01/03/16 18:37, Tom Lane wrote: Jeff Janes writes: Bisects down to: 606c0123d627b37d5ac3f7c2c97cd715dde7842f is the first bad commit commit 606c0123d627b37d5ac3f7c2c97cd715dde7842f Author: Simon Riggs Date: Tue Nov 18 10:24:55 2014 +

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

On 3/1/16, Pavel Stehule wrote: >> I though about it before and I prefer variant with possibility to enter >> message as keyword parameter. That's also ok, but indeed with a check that it's not specified twice which I see you already added. > I merged your patches

Re: [HACKERS] [NOVICE] WHERE clause not used when index is used

Jeff Janes writes: > Bisects down to: > 606c0123d627b37d5ac3f7c2c97cd715dde7842f is the first bad commit > commit 606c0123d627b37d5ac3f7c2c97cd715dde7842f > Author: Simon Riggs > Date: Tue Nov 18 10:24:55 2014 + > Reduce btree scan

Re: [HACKERS] [NOVICE] WHERE clause not used when index is used

* Tom Lane (t...@sss.pgh.pa.us) wrote: > [ trimming -novice from the cc list ] > > Jeff Janes writes: > > On Tue, Mar 1, 2016 at 7:40 AM, Tom Lane wrote: > >> (Problem is reproducible in 9.5 and HEAD, but not 9.4.) > > > Bisects down to: > > >

Re: [HACKERS] Confusing with commit time usage in logical decoding

On 01/03/16 18:18, Andres Freund wrote: Hi, On 2016-03-01 18:09:28 +0100, Petr Jelinek wrote: On 01/03/16 17:57, Alvaro Herrera wrote: Artur Zakirov wrote: Hello, Andres You have introduced a large replication progress tracking infrastructure last year. And there is a problem described at

Re: [HACKERS] [NOVICE] WHERE clause not used when index is used

[ trimming -novice from the cc list ] Jeff Janes writes: > On Tue, Mar 1, 2016 at 7:40 AM, Tom Lane wrote: >> (Problem is reproducible in 9.5 and HEAD, but not 9.4.) > Bisects down to: > 606c0123d627b37d5ac3f7c2c97cd715dde7842f is the first bad commit

Re: [HACKERS] Confusing with commit time usage in logical decoding

Andres Freund wrote: > I'd rather just initialize commit_time to parsed->xact_time. That also works. Probably also change its declaration to actually be TimestampTz ... > This indeed is clearly a bug. I do wonder if anybody has a good idea > about how to add regression tests for this? It's

Re: [HACKERS] Small PATCH: check of 2 Perl modules

On Tue, Feb 16, 2016 at 11:48 AM, Victor Wagner wrote: > On Tue, 16 Feb 2016 12:23:56 -0300 > Alvaro Herrera wrote: > >> ... but I agree with the point upthread that this should wait to see >> what happens with the CMake stuff, since this is not a

Re: [HACKERS] [NOVICE] WHERE clause not used when index is used

On Tue, Mar 1, 2016 at 7:40 AM, Tom Lane wrote: > Tobias Florek writes: >> When creating an index to use for an ORDER BY clause, a simple query >> starts to return more results than expected. See the following detailed >> log. > > Ugh. That is *badly*

Re: [HACKERS] [NOVICE] WHERE clause not used when index is used

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Tobias Florek writes: > > When creating an index to use for an ORDER BY clause, a simple query > > starts to return more results than expected. See the following detailed > > log. > > Ugh. That is *badly* broken. I thought maybe it

Re: [HACKERS] GetExistingLocalJoinPath() vs. the docs

On Tue, Feb 16, 2016 at 7:53 AM, Ashutosh Bapat wrote: > PFA patch fixing those things. I think that you need to take a little broader look at this section. At the top, it says "To use any of these functions, you need to include the header file foreign/foreign.h

Re: [HACKERS] The plan for FDW-based sharding

On 01.03.2016 19:03, Robert Haas wrote: On Tue, Mar 1, 2016 at 10:37 AM, Bruce Momjian wrote: On Tue, Mar 1, 2016 at 10:19:45AM -0500, Robert Haas wrote: Two reasons: 1. There is no ideal implementation of DTM which will fit all possible needs and be efficient for all

Re: [HACKERS] Confusing with commit time usage in logical decoding

Hi, On 2016-03-01 18:09:28 +0100, Petr Jelinek wrote: > On 01/03/16 17:57, Alvaro Herrera wrote: > >Artur Zakirov wrote: > >>Hello, Andres > >> > >>You have introduced a large replication progress tracking infrastructure > >>last year. And there is a problem described at the link in the quote

Re: [HACKERS] Confusing with commit time usage in logical decoding

Petr Jelinek wrote: > On 01/03/16 17:57, Alvaro Herrera wrote: > >Artur Zakirov wrote: > >>Hello, Andres > >> > >>You have introduced a large replication progress tracking infrastructure > >>last year. And there is a problem described at the link in the quote below. > >> > >>Attached patch fix

Re: [HACKERS] The plan for FDW-based sharding

Thank you very much for you comments. On 01.03.2016 18:19, Robert Haas wrote: On Sat, Feb 27, 2016 at 2:29 AM, Konstantin Knizhnik wrote: How do you prevent clock skew from causing serialization anomalies? If node receives message from "feature" it just needs to

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

29.02.2016 18:17, Anastasia Lubennikova: 25.02.2016 21:39, Jeff Janes: As promised, here's the new version of the patch "including_columns_4.0". I fixed all issues except some points mentioned below. Thanks for the update patch. I get a compiler warning: genam.c: In function

Re: [HACKERS] Confusing with commit time usage in logical decoding

Artur Zakirov wrote: > Hello, Andres > > You have introduced a large replication progress tracking infrastructure > last year. And there is a problem described at the link in the quote below. > > Attached patch fix this issue. Is this patch correct? I will be grateful if > it is and if it will

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

"Daniel Verite" writes: > Alvaro Herrera wrote: >> If others can try this patch to ensure it enables pg_dump to work on >> their databases, it would be great. > It doesn't seem to help if one field exceeds 1Gb, for instance when > inflated by a bin->hex

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

Alvaro Herrera wrote: > If others can try this patch to ensure it enables pg_dump to work on > their databases, it would be great. It doesn't seem to help if one field exceeds 1Gb, for instance when inflated by a bin->hex translation. postgres=# create table big as select

  1   2   >