Re: [HACKERS] Postgres_fdw join pushdown - INNER - FULL OUTER join combination generating wrong result

Thanks Ashutosh for the patch. I have applied and tested it. Now getting proper result for reported issue. Thanks & Regards, Rajkumar Raghuwanshi QMG, EnterpriseDB Corporation On Tue, Mar 29, 2016 at 7:50 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > > Observation:_ Inner join

Re: [HACKERS] Breakage with VACUUM ANALYSE + partitions

On Sat, Mar 26, 2016 at 01:39:42PM +0100, Andres Freund wrote: > On 2016-03-25 12:02:05 -0400, Robert Haas wrote: > > Gosh, that's surprising. I wonder if that just revealed an underlying > > issue rather than creating it. > > I think that's the case; it's just somewhat unlikely to hit in other

Re: [HACKERS] Performance degradation in commit 6150a1b0

On Thu, Mar 31, 2016 at 01:10:56AM -0400, Noah Misch wrote: > On Sun, Mar 27, 2016 at 02:15:50PM +0200, Andres Freund wrote: > > On 2016-03-27 02:34:32 +0530, Ashutosh Sharma wrote: > > > As mentioned in my earlier mail i was not able to apply > > > *pinunpin-cas-5.patch* on commit *6150a1b0, > >

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

On Wed, Mar 30, 2016 at 1:01 PM, Robbie Harwood wrote: > A new version of my GSSAPI encryption patchset is available, both in > this email and on my github: > https://github.com/frozencemetery/postgres/tree/feature/gssencrypt9 > > This version is intended to address David's

Re: [HACKERS] Performance degradation in commit 6150a1b0

On Sun, Mar 27, 2016 at 02:15:50PM +0200, Andres Freund wrote: > On 2016-03-27 02:34:32 +0530, Ashutosh Sharma wrote: > > As mentioned in my earlier mail i was not able to apply > > *pinunpin-cas-5.patch* on commit *6150a1b0, > > That's not surprising; that's pretty old. > > > *therefore i

Re: [HACKERS] Recovery test failure for recovery_min_apply_delay on hamster

On Sun, Mar 13, 2016 at 10:18:46PM +0100, Michael Paquier wrote: > On Wed, Mar 9, 2016 at 9:05 PM, Michael Paquier > wrote: > > On Wed, Mar 9, 2016 at 12:29 PM, Alvaro Herrera > > wrote: > >> Michael Paquier wrote: > >>> After sleeping (best

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

On Thu, Mar 24, 2016 at 01:02:57PM +0900, Etsuro Fujita wrote: > On 2016/03/24 11:14, Michael Paquier wrote: > >On Wed, Mar 23, 2016 at 10:05 PM, Thom Brown wrote: > >>I've noticed that you now can't cancel a query if there's DML pushdown > >>to a foreign server. This previously

Re: [HACKERS] Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.

On Thu, Mar 10, 2016 at 01:04:11AM +0900, Masahiko Sawada wrote: > As a result of looked into code around the recvoery, ISTM that the > cause is related to relation cache clear. > In heap_xlog_visible, if the standby server receives WAL record then > relation cache is eventually cleared in

Re: [HACKERS] Relation extension scalability

On Tue, Mar 29, 2016 at 10:08 AM, Amit Kapila wrote: > Yes, that makes sense. One more point is that if the reason for v13 > giving better performance is extra blocks (which we believe in certain > cases can leak till the time Vacuum updates the FSM tree), do you think

Re: [HACKERS] So, can we stop supporting Windows native now?

Craig Ringer writes: > On 31 March 2016 at 07:49, Josh berkus wrote: >> So, can we stop supporting Windows native now? > Why would we want to? > The cost is small. Surely you jest. Windows is the single biggest PITA platform from a portability

Re: [HACKERS] pg_xlogdump fails to handle WAL file with multi-page XLP_FIRST_IS_CONTRECORD data

On Thu, Mar 31, 2016 at 6:27 AM, Craig Ringer wrote: > > > Can you describe the process used to generate the sample WAL segment? > > Shame that I can't find the sql file used to create the problematic WAL segment. But this is what I did. I wrote a plpgsql function which

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

On Thu, Mar 31, 2016 at 3:55 AM, Masahiko Sawada wrote: > On Wed, Mar 30, 2016 at 11:43 PM, Masahiko Sawada > wrote: >> On Tue, Mar 29, 2016 at 5:36 PM, Kyotaro HORIGUCHI >> wrote: >>> I personally don't think it

Re: [HACKERS] Very small patch for decode.c

Konstantin Knizhnik wrote: > diff --git a/src/backend/replication/logical/decode.c > b/src/backend/replication/logical/decode.c > index 2380ea2..a992662 100644 > --- a/src/backend/replication/logical/decode.c > +++ b/src/backend/replication/logical/decode.c > @@ -488,7 +488,7 @@

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

On Thu, Mar 31, 2016 at 1:14 AM, Robert Haas wrote: > On Wed, Mar 30, 2016 at 9:46 AM, Michael Paquier > wrote: >>> Things I noticed: >>> 1. >>> when using either >>> CREATE ROLE >>> ALTER ROLE >>> with the parameter >>>

Re: [HACKERS] snapshot too old, configured by time

Michael Paquier wrote: > Just a note: I began looking at the tests, but finished looking at the > patch entirely at the end by curiosity. Regarding the integration of > this patch for 9.6, I think that bumping that to 9.7 would be wiser > because the patch needs to be re-written largely, and

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

On 3/30/16 4:18 AM, Magnus Hagander wrote: > > On Wed, Mar 30, 2016 at 4:10 AM, David Steele > wrote: > > This certainly looks like it would work but it raises the barrier for > implementing backups by quite a lot. It's fine for

Re: [HACKERS] Correction for replication slot creation error message in 9.6

On Thu, Mar 31, 2016 at 10:15 AM, Ian Barwick wrote: > Currently pg_create_physical_replication_slot() may refer to > the deprecated wal_level setting "archive": (Adding Peter in CC who committed this patch). > Patch changes the error message to: > > ERROR: replication

Re: [HACKERS] Please correct/improve wiki page about abbreviated keys bug

Okay. I'll look at it later today. -- Peter Geoghegan

Re: [HACKERS] Please correct/improve wiki page about abbreviated keys bug

On 03/30/2016 02:47 PM, Josh berkus wrote: > On 03/29/2016 07:43 PM, Peter Geoghegan wrote: >> Do you think it would be okay if the SQL query to detect potentially >> affected indexes only considered the leading attribute? Since that's >> the only attribute that could use abbreviated keys, it

[HACKERS] Correction for replication slot creation error message in 9.6

Hi Currently pg_create_physical_replication_slot() may refer to the deprecated wal_level setting "archive": postgres=# SHOW wal_level ; wal_level --- minimal (1 row) postgres=# SELECT pg_create_physical_replication_slot('some_slot'); ERROR: replication slots can only be

Re: [HACKERS] pg_xlogdump fails to handle WAL file with multi-page XLP_FIRST_IS_CONTRECORD data

On 23 March 2016 at 18:04, Pavan Deolasee wrote: > > > On Wed, Mar 23, 2016 at 1:13 PM, Michael Paquier < > michael.paqu...@gmail.com> wrote: > >> >> + /* >> +* Compute targetRecOff. It should typically be greater than short >> +* page-header since

Re: [HACKERS] So, can we stop supporting Windows native now?

On 31 March 2016 at 07:49, Josh berkus wrote: > So, can we stop supporting Windows native now? Why would we want to? The cost is small. People use it. Things like integrated SSPI authentication only work on native. About the only issue I think it causes is with the build

Re: [HACKERS] pg_xlogdump fails to handle WAL file with multi-page XLP_FIRST_IS_CONTRECORD data

On 23 March 2016 at 18:04, Pavan Deolasee wrote: > > > On Wed, Mar 23, 2016 at 1:13 PM, Michael Paquier < > michael.paqu...@gmail.com> wrote: > >> >> + /* >> +* Compute targetRecOff. It should typically be greater than short >> +* page-header since

Re: [HACKERS] Very small patch for decode.c

On 31 March 2016 at 03:34, Konstantin Knizhnik wrote: > diff --git a/src/backend/replication/logical/decode.c > b/src/backend/replication/logical/decode.c > index 2380ea2..a992662 100644 > --- a/src/backend/replication/logical/decode.c > +++

Re: [HACKERS] Timeline following for logical slots

On 31 March 2016 at 07:15, Alvaro Herrera wrote: > > Available attached or at > > > https://github.com/2ndQuadrant/postgres/tree/dev/logical-decoding-timeline-following > > And pushed this too. > Much appreciated. Marked as committed at

Re: [HACKERS] pg_xlogdump fails to handle WAL file with multi-page XLP_FIRST_IS_CONTRECORD data

On Mon, Mar 28, 2016 at 10:15 PM, Andres Freund wrote: > It's definitely too late for that; they're going to be wrapped in a > couple hours. I have added this patch to the next CF so as we do not lose track of this bug: https://commitfest.postgresql.org/10/593/ -- Michael

Re: [HACKERS] Very small patch for decode.c

On Thu, Mar 31, 2016 at 4:34 AM, Konstantin Knizhnik wrote: > diff --git a/src/backend/replication/logical/decode.c > b/src/backend/replication/logical/decode.c > index 2380ea2..a992662 100644 > --- a/src/backend/replication/logical/decode.c > +++

Re: [HACKERS] Publish autovacuum informations

On Thu, Mar 31, 2016 at 6:09 AM, Julien Rouhaud wrote: > On 19/03/2016 01:11, Jim Nasby wrote: >> On 3/3/16 3:54 AM, Kyotaro HORIGUCHI wrote: >>> I wonder why there haven't been discussions so far on what kind >>> of information we want by this feature. For example I'd

Re: [HACKERS] So, can we stop supporting Windows native now?

On Thu, Mar 31, 2016 at 8:49 AM, Josh berkus wrote: > http://www.zdnet.com/article/microsoft-and-canonical-partner-to-bring-ubuntu-to-windows-10/ > > ... could be good news for us ... Possible. We are years ahead of that for sure. Also the outcome of the partnership, as well

Re: [HACKERS] snapshot too old, configured by time

On Thu, Mar 31, 2016 at 5:09 AM, Kevin Grittner wrote: > On Wed, Mar 30, 2016 at 2:22 PM, Alvaro Herrera > wrote: >> I understand the invasiveness argument, but to me the danger of >> introducing new bugs trumps that. The problem is not the current

[HACKERS] 9.6 Open Item Ownership

The release management team has determined the following: From time to time, individual members of the release management team (RMT) may attribute a PostgreSQL 9.6 open item to a particular git commit and determine whether or not it is a beta1 blocker. The RMT member will send a

[HACKERS] FATAL: could not send end-of-streaming message to primary: no COPY in progress

Hi hackers, If you shut down a primary server, a standby that is streaming from it says54: LOG: replication terminated by primary server DETAIL: End of WAL reached on timeline 1 at 0/14F4B68. FATAL: could not send end-of-streaming message to primary: no COPY in progress Isn't that FATAL

[HACKERS] So, can we stop supporting Windows native now?

http://www.zdnet.com/article/microsoft-and-canonical-partner-to-bring-ubuntu-to-windows-10/ ... could be good news for us ... -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] PATCH: index-only scans with partial indexes

Kevin Grittner writes: > I'm taking my name off as committer and marking it "Ready for > Committer". If someone else wants to comment on the issues where > Tom and Kyotaro-san still seem unsatisfied to the point where I > can get my head around it, I could maybe take it back

Re: [HACKERS] Timeline following for logical slots

Craig Ringer wrote: > It removes the questionable cleanups, fixes the randAccess comment (IMO), I pushed cleanup separately, including the addition of a few comments that were documenting the original code. I actually made a mistake in extracting those, so there's one comment that's actually

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

On 2016-03-28 22:50:49 +0530, Amit Kapila wrote: > On Fri, Sep 11, 2015 at 8:01 PM, Amit Kapila > wrote: > > > > On Thu, Sep 3, 2015 at 5:11 PM, Andres Freund wrote: > > > > > > > Updated comments and the patch (increate_clog_bufs_v2.patch) > >

Re: [HACKERS] [PATCH] Supporting +-Infinity values by to_timestamp(float8)

On 3/29/16, Tom Lane wrote: > Pushed with minor adjustments. > > regards, tom lane > Thank you very much! -- Best regards, Vitaly Burovoy -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

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

On 3/25/16, Dmitry Dolgov <9erthali...@gmail.com> wrote: > Here is a new version of path, I hope I didn't miss anything. Few notes: > >> 4. >> or even create a new constant (there can be better name for it): >> #define JB_PATH_CREATE_OR_INSERT (JB_PATH_INSERT_BEFORE | >> JB_PATH_INSERT_AFTER |

Re: [HACKERS] [CommitFest App] Feature request -- review e-mail additions

* José Luis Tallón (jltal...@adv-solutions.net) wrote: > * Prepend a [review] tag to the e-mail subject > ... so that e-mails sent to -hackers will read " [HACKERS] > [review] " Eh, I'm not against it but not sure it's all that necessary either. > * Auto-CC the patch author on this e-mail >

Re: [HACKERS] Please correct/improve wiki page about abbreviated keys bug

On 03/29/2016 07:43 PM, Peter Geoghegan wrote: > On Tue, Mar 29, 2016 at 7:31 PM, Tom Lane wrote: >> A corrupt index could easily fail to detect uniqueness violations (because >> searches fail to find entries they should find). Not sure I believe that >> it would make false

Re: [HACKERS] Publish autovacuum informations

On 19/03/2016 01:11, Jim Nasby wrote: > On 3/3/16 3:54 AM, Kyotaro HORIGUCHI wrote: >> I wonder why there haven't been discussions so far on what kind >> of information we want by this feature. For example I'd be happy >> to see the time of last autovacuum trial and the cause if it has >> been

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

On Wed, Mar 30, 2016 at 12:31 PM, José Luis Tallón wrote: > On 03/30/2016 06:14 PM, Robert Haas wrote: >> So basically the use of the ENCRYPTED keyword means "if it does already >> seem to be the sort of MD5 blob we're expecting, turn it into that". > > If it does NOT

Re: [HACKERS] snapshot too old, configured by time

On Thu, Mar 24, 2016 at 2:24 AM, Michael Paquier wrote: > I have been looking at 4a, the test module, and things are looking > good IMO. Something that I think would be adapted would be to define > the options for isolation tests in a variable, like ISOLATION_OPTS to >

Re: [HACKERS] snapshot too old, configured by time

Kevin Grittner wrote: > On Wed, Mar 30, 2016 at 2:22 PM, Alvaro Herrera > wrote: > > I said that we should change BufferGetPage into having the snapshot > > check built-in, except in the cases where a flag is passed; and the flag > > would be passed in all cases except

Re: [HACKERS] large regression for parallel COPY

On 03/30/2016 01:10 PM, Andres Freund wrote: On 2016-03-30 15:50:21 -0400, Robert Haas wrote: On Thu, Mar 10, 2016 at 8:29 PM, Andres Freund wrote: Allow to trigger kernel writeback after a configurable number of writes. While testing out Dilip Kumar's relation extension

Re: [HACKERS] large regression for parallel COPY

On 2016-03-30 15:50:21 -0400, Robert Haas wrote: > On Thu, Mar 10, 2016 at 8:29 PM, Andres Freund wrote: > > Allow to trigger kernel writeback after a configurable number of writes. > > While testing out Dilip Kumar's relation extension patch today, I > discovered (with some

Re: [HACKERS] snapshot too old, configured by time

On Wed, Mar 30, 2016 at 2:22 PM, Alvaro Herrera wrote: > I understand the invasiveness argument, but to me the danger of > introducing new bugs trumps that. The problem is not the current code, > but future patches: it is just too easy to make the mistake of not >

Re: [HACKERS] snapshot too old, configured by time

On Wed, Mar 30, 2016 at 2:34 PM, Kevin Grittner wrote: > A connection should not get the > error just because it is using a snapshot that tries to look at > data that might be wrong, and the connection holding the long-lived > snapshot doesn't do that until it awakes from the

[HACKERS] large regression for parallel COPY

On Thu, Mar 10, 2016 at 8:29 PM, Andres Freund wrote: > Allow to trigger kernel writeback after a configurable number of writes. While testing out Dilip Kumar's relation extension patch today, I discovered (with some help from Andres) that this causes nasty regressions when

Re: [HACKERS] snapshot too old, configured by time

On Wed, Mar 30, 2016 at 2:29 PM, Peter Geoghegan wrote: > [Does the patch allow dangling page pointers?] > Again, I don't want to prejudice anyone against your patch, which I > haven't read. I don't believe that the way the patch does its business opens any new vulnerabilities

[HACKERS] Very small patch for decode.c

diff --git a/src/backend/replication/logical/decode.c b/src/backend/replication/logical/decode.c index 2380ea2..a992662 100644 --- a/src/backend/replication/logical/decode.c +++ b/src/backend/replication/logical/decode.c @@ -488,7 +488,7 @@ DecodeCommit(LogicalDecodingContext *ctx,

Re: [HACKERS] snapshot too old, configured by time

On Sat, Mar 19, 2016 at 1:27 AM, Jeff Janes wrote: > I'm not sure if this is operating as expected. > > I set the value to 1min. > > I set up a test like this: > > pgbench -i > > pgbench -c4 -j4 -T 3600 & > > ### watch the size of branches table > while (true) ; do psql -c

Re: [HACKERS] Combining Aggregates

On 31 March 2016 at 00:48, Robert Haas wrote: > On Tue, Mar 29, 2016 at 11:14 PM, David Rowley > wrote: >>> 0005: >>> Haribabu's patch; no change from last time. > > So what's the distinction between 0002 and 0005? And what is the > correct

Re: [HACKERS] snapshot too old, configured by time

On Wed, Mar 30, 2016 at 12:21 PM, Peter Geoghegan wrote: > Well, amcheck is a tool that in essence makes sure that B-Trees look > structurally sound, and respect invariants like having every item on > each page in logical order. That could catch a bug of the kind I just >

Re: [HACKERS] snapshot too old, configured by time

Kevin Grittner wrote: > On Wed, Mar 30, 2016 at 11:37 AM, Tom Lane wrote: > > Alvaro Herrera writes: > >> I think a safer proposition would be to replace all current > >> BufferGetPage() calls (there are about 500) by adding the necessary > >>

Re: [HACKERS] snapshot too old, configured by time

On Wed, Mar 30, 2016 at 11:53 AM, Kevin Grittner wrote: > When the initial "proof of concept" patch was tested by the > customer, it was not effective due to issues related to what you > raise. Autovacuum workers were blocking due to the page pins for > scans using these old

Re: [HACKERS] snapshot too old, configured by time

On Sun, Mar 20, 2016 at 6:25 PM, Peter Geoghegan wrote: > I haven't read the patch, but I wonder: What are the implications here > for B-Tree page recycling by VACUUM? > Offhand, I imagine that there'd be some special considerations. Why is > it okay that an index scan could

Re: [HACKERS] Using quicksort for every external sort run

On Wed, Mar 30, 2016 at 4:22 AM, Greg Stark wrote: > I'm sorry I was intending to run those benchmarks again this past week > but haven't gotten around to it. But my plan was to run them on a good > server I borrowed, an i7 with 8MB cache. I can still go ahead with > that but I can

Re: [HACKERS] snapshot too old, configured by time

On Wed, Mar 30, 2016 at 11:37 AM, Tom Lane wrote: > Alvaro Herrera writes: >> I think a safer proposition would be to replace all current >> BufferGetPage() calls (there are about 500) by adding the necessary >> arguments: buffer, snapshot, rel, and

Re: [HACKERS] Speedup twophase transactions

On 03/30/2016 09:19 AM, Stas Kelvich wrote: > +++ b/src/test/recovery/t/006_twophase.pl > @@ -0,0 +1,226 @@ > +# Checks for recovery_min_apply_delay > +use strict; > This description is wrong, this file has been copied from 005. Yep, done. > > +my $node_master = get_new_node("Candie"); > +my

Re: [HACKERS] pg_dump dump catalog ACLs

On Wed, Mar 30, 2016 at 1:35 PM, Jose Luis Tallon wrote: > DESIGN/DOCUMENTATION > * int4 for the "objsubid" field? and int2 would surely suffice, given that we > only allow up to 1600 columns ... if it's a matter of alignment, it would be > interesting to say so

Re: [HACKERS] [COMMITTERS] pgsql: Introduce SP-GiST operator class over box.

Teodor Sigaev writes: > Introduce SP-GiST operator class over box. All of the Windows buildfarm members are failing on this patch. It looks like the problem is that the test cases suppose that type box will allow "infinity" as a coordinate value. But box_in just uses strtod()

Re: [HACKERS] [CommitFest App] Feature request -- review e-mail additions

José Luis Tallón wrote: > Just wanted to suggest two minor mods to the review e-mails > auto-generated by the app: > > * Prepend a [review] tag to the e-mail subject > ... so that e-mails sent to -hackers will read " [HACKERS] [review] > " Changing the subject of an email causes Gmail

[HACKERS] [CommitFest App] Feature request -- review e-mail additions

Hello, Just wanted to suggest two minor mods to the review e-mails auto-generated by the app: * Prepend a [review] tag to the e-mail subject ... so that e-mails sent to -hackers will read " [HACKERS] [review] " * Auto-CC the patch author on this e-mail I guess this should

Re: [HACKERS] Desirable pgbench features?

On 03/30/2016 08:29 AM, Fabien wrote: > (1) TPC-B test driver must obtain a value from a query (the branch is > the one > of the chosen teller, not any random branch) and reuse it in another > query. Currently the communication is one way, all results are silently > discarded. > >

Re: [HACKERS] [GENERAL] pg_restore casts check constraints differently

On Thu, Mar 31, 2016 at 1:00 AM, Tom Lane wrote: > I wrote: >> Amit Langote writes: >>> destdb=# ALTER TABLE c ADD CONSTRAINT p_a_check CHECK (a IN ('a', 'b', >>> 'c')); >>> destdb=# \d c >>> ... >>> Check constraints: >>> "p_a_check" CHECK (a::text

Re: [HACKERS] [postgresSQL] [bug] Two or more different types of constraints with same name creates ambiguity while drooping.

Alvaro Herrera writes: > Tom Lane wrote: >> What we need is a unique index on pg_constraint. >> The problem with that is that pg_constraint contains both table-related >> and type (domain) related constraints; but it strikes me that we could >> probably create a unique

Re: [HACKERS] snapshot too old, configured by time

Alvaro Herrera writes: > I think a safer proposition would be to replace all current > BufferGetPage() calls (there are about 500) by adding the necessary > arguments: buffer, snapshot, rel, and an integer "flags". All this > without adding the feature. Then a

Re: [HACKERS] WIP: Access method extendability

Alexander Korotkov wrote: > I heard no objections. There is revision of patch where generic WAL > interface description was moved to documentation. This description > contains improvements by Petr Jelinek, Alvaro Herrera and Markus Nullmeier Attached are a

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

On 03/30/2016 06:14 PM, Robert Haas wrote: So basically the use of the ENCRYPTED keyword means "if it does already seem to be the sort of MD5 blob we're expecting, turn it into that". If it does NOT already seem to be... I guess? And we just rely on the format to distinguish between an MD5

Re: [HACKERS] [postgresSQL] [bug] Two or more different types of constraints with same name creates ambiguity while drooping.

Tom Lane wrote: > What we need is a unique index on pg_constraint. > > The problem with that is that pg_constraint contains both table-related > and type (domain) related constraints; but it strikes me that we could > probably create a unique index on (conrelid, contypid, conname). Weren't you

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

On Wed, Mar 30, 2016 at 9:46 AM, Michael Paquier wrote: >> Things I noticed: >> 1. >> when using either >> CREATE ROLE >> ALTER ROLE >> with the parameter >> ENCRYPTED >> md5 encryption is always assumed (I've come to realize that

Re: [HACKERS] [postgresSQL] [bug] Two or more different types of constraints with same name creates ambiguity while drooping.

Andrew Dunstan writes: > On 03/30/2016 10:21 AM, Tom Lane wrote: >> I think that if we want to ensure uniqueness of constraint names, this >> is really approaching it the wrong way, as it still fails to provide >> any guarantees (consider concurrent index creation, for

Re: [HACKERS] snapshot too old, configured by time

Michael Paquier wrote: > page = BufferGetPage(buf); > + TestForOldSnapshot(scan->xs_snapshot, rel, page); > This is a sequence repeated many times in this patch, a new routine, > say BufferGetPageExtended with a uint8 flag, one flag being used to > test old snapshots would be more adapted.

Re: [HACKERS] [GENERAL] pg_restore casts check constraints differently

I wrote: > Amit Langote writes: >> destdb=# ALTER TABLE c ADD CONSTRAINT p_a_check CHECK (a IN ('a', 'b', 'c')); >> destdb=# \d c >> ... >> Check constraints: >> "p_a_check" CHECK (a::text = ANY (ARRAY['a'::character varying, >> 'b'::character varying, 'c'::character

Re: [HACKERS] [PATCH] we have added support for box type in SP-GiST index

Thank you, pushed Emre Hasegeli wrote: I'll try to explain with two-dimensional example over points. ASCII-art: Thank you for the explanation. Should we incorporate this with the patch. added I have worked on the comments of the patch. It is attached. I hope it looks more clear than it

Re: [HACKERS] snapshot too old, configured by time

On Tue, Mar 29, 2016 at 8:58 AM, David Steele wrote: > We're getting to the end of the CF now. Do you know when you'll have an > updated patch ready? I am working on it right now. Hopefully I can get it all sorted today. -- Kevin Grittner EDB:

Re: [HACKERS] PATCH: index-only scans with partial indexes

On Wed, Mar 30, 2016 at 8:40 AM, Tomas Vondra wrote: >> === >> @@ -2697,6 +2697,7 @@ check_partial_indexes(PlannerInfo *root, RelOptInfo >> *rel) >> continue; /* don't repeat >> work if already proven OK */ >> >>

Re: [HACKERS] Sequence Access Method WIP

Hi, Thanks for review. On 30/03/16 15:22, Jose Luis Tallon wrote: [Partial review] Evaluated: 0002-gapless-seq-2016-03-29-2.patch Needs updating code copyright years ... or is this really from 2013? [ contrib/gapless_seq/gapless_seq.c ] Patch applies cleanly to current master

[HACKERS] Desirable pgbench features?

Hello pgdevs, I've been having a look at why pgbench only implements a TPC-B "like" benchmark, and not the full, although obsolete, TPC-B. I'm not particulary interested in running TPC-B per se, although I like the principle of a simple steady-state update-intensive OLTP stress test, but

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

On Wed, Mar 30, 2016 at 11:43 PM, Masahiko Sawada wrote: > On Tue, Mar 29, 2016 at 5:36 PM, Kyotaro HORIGUCHI > wrote: >> I personally don't think it needs such a survive measure. It is >> very small syntax and the parser reads very short

Re: [HACKERS] PoC: Partial sort

Hi, Peter! Thank you for review! On Thu, Mar 24, 2016 at 3:39 AM, Peter Geoghegan wrote: > >> Sort Method > >> > >> > >> Even thought the explain analyze above shows "top-N heapsort" as its > >> sort method, that isn't really true. I actually ran this through

Re: [HACKERS] [postgresSQL] [bug] Two or more different types of constraints with same name creates ambiguity while drooping.

On 03/30/2016 10:21 AM, Tom Lane wrote: Amit Langote writes: On 2016/03/30 15:16, Harshal Dhumal wrote: If we create two different type of constrains (lets say primary key and foreign key) on same table with same name (lets say 'key' ) then its shows same drop

Re: [HACKERS] WIP: Access method extendability

> > http://www.postgresql.org/message-id/56eff347.20...@anastigmatix.net > That discussion is about SQL-level types which could be stored on > disk, not about in-memory structs I must respectfully disagree. That discussion is also about memory sanitizers and using them on buildfarms. Lets say you

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

On Tue, Mar 29, 2016 at 5:36 PM, Kyotaro HORIGUCHI wrote: > I personally don't think it needs such a survive measure. It is > very small syntax and the parser reads very short text. If the > parser failes in such mode, something more serious should have >

Re: [HACKERS] WIP: Access method extendability

as we discussed recently [1] you should avoid leaving "holes" with uninitialized data in structures. Please fix this or provide a comment that describes why things are done here the way they are done. [1] http://www.postgresql.org/message-id/56eff347.20...@anastigmatix.net That discussion is

Re: [HACKERS] [postgresSQL] [bug] Two or more different types of constraints with same name creates ambiguity while drooping.

Amit Langote writes: > On 2016/03/30 15:16, Harshal Dhumal wrote: >> If we create two different type of constrains (lets say primary key and >> foreign key) on same table with same name (lets say 'key' ) then its shows >> same drop query for both constrains. I have

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

On Wed, Mar 30, 2016 at 1:44 AM, Julian Markwort wrote: > [This is a rather informal user-review] > > Here are some thoughts and experiences on using the new features, I focused > on testing the basic funcionality of setting password_encryption to scram >

Re: [HACKERS] PATCH: index-only scans with partial indexes

Hi, On 03/30/2016 06:01 AM, Kyotaro HORIGUCHI wrote: Thank you for polishing this. At Tue, 29 Mar 2016 13:31:19 -0500, Kevin Grittner wrote in I tried to whip this into shape, but there were a few areas

Re: [HACKERS] unexpected result from to_tsvector

On Wed, Mar 30, 2016 at 10:17 AM, Artur Zakirov wrote: > On 29.03.2016 19:17, Shulgin, Oleksandr wrote: > >> >> Hm, indeed. Unfortunately, it is not quite easy to find "the" new RFC, >> there was quite a number of correcting and extending RFCs issued over >> the last

Re: [HACKERS] Sequence Access Method WIP

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested [Partial review] Evaluated: 0002-gapless-seq-2016-03-29-2.patch Needs

Re: [HACKERS] WIP: Access method extendability

GenericXLogStart(Relation relation) { ... if (genericXlogStatus != GXLOG_NOT_STARTED) ereport(ERROR, (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE), errmsg("GenericXLogStart: generic xlog is already started"))); Hmm, seems, generic wal whiil be

Re: [HACKERS] Speedup twophase transactions

On Mar 29, 2016, at 6:04 PM, David Steele wrote:It looks like you should post a new patch or respond to Michael's comments.  Marked as "waiting on author".Yep, here it is.On Mar 22, 2016, at 4:20 PM, Michael Paquier wrote:Looking at this

Re: [HACKERS] WIP: Access method extendability

Referenced by commit commit 473b93287040b20017cc25a157cffdc5b978c254 ("Support CREATE ACCESS METHOD"), commited by alvherre -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] standby_schedule

Simon Riggs wrote: > On 29 March 2016 at 22:44, Alvaro Herrera wrote: > > > I think we're at a point where we can translate the tests in > > src/test/regress/standby_schedule file into a PostgresNode-based test, > > or remove it (probably under src/test/recovery). That

Re: [HACKERS] improving GROUP BY estimation

Hi, On 03/22/2016 03:40 PM, Alexander Korotkov wrote: I think you should send a revision of patch including comments proposed by Deam Rasheed. I'm switching patch status to waiting on author in commitfest. Attached is v4 of the patch - the only difference w.r.t. v3 is that I've used the

Re: [HACKERS] WIP: Access method extendability

Hello I did a brief review of bloom contrib and I don't think I like it much. Here are some issues I believe should be fixed before committing it to PostgreSQL. 1) Most of the code is not commented. Every procedure should at least have a breif description of what it does, what arguments it

Re: [HACKERS] Combining Aggregates

On Tue, Mar 29, 2016 at 11:14 PM, David Rowley wrote: > Many thanks Robert for committing the serialize states portion. yw, sorry I didn't get an email out about that. >> 0005: >> Haribabu's patch; no change from last time. So what's the distinction between 0002

Re: [HACKERS] Default Roles

If this gets into 9.6, we give users another full release cycle to ensure there are no reserved rolenames in use. Then, I reckon that the additional roles/system-role-based fine-grained authorization could go in for 9.7 without much trouble -- this is badly needed, IMHO Thank you, Stephen and

Re: [HACKERS] Using quicksort for every external sort run

On Wed, Mar 30, 2016 at 7:23 AM, Peter Geoghegan wrote: > Anyway, what I liked about Greg's approach to finding regressions at > the low end was that when testing, he used the cheapest possible VM > available on Google's cloud platform. When testing the low end, he had > low end

  1   2   >