Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

On Fri, Mar 25, 2016 at 12:55 PM, Tom Lane wrote: > Michael Paquier writes: >> Not sure if Andres is working on that for now or not, the main >> discussion that I am foreseeing here is how we are going to map elevel >> for the frontend (should

Re: [HACKERS] Odd system-column handling in postgres_fdw join pushdown patch

A much simpler solution, that will work with postgres_fdw, might be to just deparse these columns with whatever random values (except for tableoid) they are expected to have in those places. Often these values can simply be NULL or 0. For tableoid deparse it to 'oid value'::oid. Thus for a user

Re: [HACKERS] Performance degradation in commit 6150a1b0

On Wed, Mar 23, 2016 at 1:59 PM, Ashutosh Sharma wrote: > > Hi All, > > I have been working on this issue for last few days trying to investigate what could be the probable reasons for Performance degradation at commit 6150a1b0. After going through Andres patch for moving

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Michael Paquier writes: > Not sure if Andres is working on that for now or not, the main > discussion that I am foreseeing here is how we are going to map elevel > for the frontend (should FATAL, PANIC exit immediately, etc). Doesn't seem that complicated to me: elevel

Re: [HACKERS] Combining Aggregates

On 25 March 2016 at 06:17, Robert Haas wrote: > On Mon, Mar 21, 2016 at 2:18 PM, David Rowley > wrote: >> I've attached 2 of the patches which are affected by the changes. > > I think the documentation for 0001 needs some work yet. The >

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

On Fri, Mar 25, 2016 at 9:52 AM, Tom Lane wrote: > Michael Paquier writes: >> Preventing the use of elog in the frontend is something that has been >> addressed multiple times with FRONTEND, so that's not likely going to >> be an issue I think.

Re: [HACKERS] Alter or rename enum value

Jim Nasby writes: > I'm certain there's a really good reason adding new values isn't allowed > inside of a transaction. It's probably documented in the code. Yes, see AlterEnum(): * Ordinarily we disallow adding values within transaction blocks, because * we

Re: [HACKERS] Show dropped users' backends in pg_stat_activity

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Robert Haas writes: > > I am not really in favor of half-fixing this. If we can't > > conveniently wait until a dropped role is completely out of the > > system, then I don't see a lot of point in trying to do it in the > > limited

Re: [HACKERS] avg,first,last,median in one query

On 3/24/16 9:00 AM, Konstantin Knizhnik wrote: But unfortunately it is not possible to calculate median is such way because percentile_disc is not compatible with OVER: I don't know if you could use cume_dist()[1] to do this, but even if you can't it probably wouldn't be hard to modify it to

Re: [HACKERS] Alter or rename enum value

On 3/24/16 2:00 PM, Matthias Kurz wrote: ALTER TYPE bogon DROP VALUE 'cat'; -- not implemented in 9.5 but should work in future ROLLBACK; Dropping a value is significantly harder because that value could be in use. I'm certain there's a really good reason adding new values isn't allowed

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Michael Paquier writes: > On Fri, Mar 25, 2016 at 1:11 AM, Alvaro Herrera > wrote: >> I wondered about the list stuff while messing about in pg_dump awhile >> ago. It seems moderately okay, but not terribly generic; maybe we >> should get rid

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Thu, Mar 24, 2016 at 11:20 PM, Robert Haas wrote: > On Thu, Mar 24, 2016 at 2:11 AM, Michael Paquier > wrote: >> - SyncRepWaitForLSN(gxact->prepare_end_lsn); >> + SyncRepWaitForLSN(gxact->prepare_end_lsn, false); >> Isn't it important to

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 2016/03/24 22:01, Robert Haas wrote: > On Thu, Mar 24, 2016 at 8:45 AM, Rahila Syed wrote: >> >> - values[i+3] = >> UInt32GetDatum(beentry->st_progress_param[i]); >> + values[i+3] = >>

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

On 3/24/16 10:21 AM, Alexander Korotkov wrote: 1) It's a great feature many users dream about. Doesn't matter if it starts eating their data... 2) Patch is not very big. 3) Patch doesn't introduce significant infrastructural changes. It just change some well-isolated placed. It doesn't

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

On Fri, Mar 25, 2016 at 1:11 AM, Alvaro Herrera wrote: > Tom Lane wrote: > >> What I propose doing is leaving the above-listed items in >> pg_dump/dumputils.h/.c, and moving the rest of what's in those files >> to new files src/include/fe_utils/string_utils.h and >>

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

On Sun, Mar 20, 2016 at 11:01 PM, Peter Geoghegan wrote: > Allowing 0 tuple runs in rare cases seems like the simplest solution. > After all, mergeprereadone() is expressly prepared for 0 tuple runs. > It says "ensure that we have at least one tuple, if any are to be > had".

Re: [HACKERS] NOT EXIST for PREPARE

On 03/24/2016 11:21 PM, Merlin Moncure wrote: Personally I think the right solution would be to add support for prepared statements in pgbouncer, and have pgbouncer run PREPARE as necessary, either after opening a new connection to the database or at the first use of a given prepared statement

Re: [HACKERS] NOT EXIST for PREPARE

On Thu, Mar 24, 2016 at 2:52 PM, Andreas Karlsson wrote: > On 03/23/2016 09:10 PM, Stephen Frost wrote: >> >> * Merlin Moncure (mmonc...@gmail.com) wrote: >>> >>> No one is arguing that that you should send it any every time (at >>> least -- I hope not). >> >> >> I'm not sure I

Re: [HACKERS] btree_gin and btree_gist for enums

On 03/24/2016 12:40 PM, Matt Wilmas wrote: It would be *really* nice to have this in 9.6. It seems it's simply filling out functionality that should already be there, right? An oversight/bug fix so it works "as advertised?" :-) I think that would be stretching the process a bit far.

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

On Thu, Mar 24, 2016 at 7:17 AM, Robert Haas wrote: > I really like this idea, and the performance results seem impressive, > but I think we should push this out to 9.7. A btree patch that didn't > have WAL support until two and a half weeks into the final CommitFest >

Re: [HACKERS] Relation extension scalability

On Thu, Mar 24, 2016 at 7:17 AM, Dilip Kumar wrote: >> Yet another possibility could be to call it as >> GetPageWithFreeSpaceExtended and call it from GetPageWithFreeSpace with >> value of oldPage as InvalidBlockNumber. > > Yes I like this.. Changed the same. After

Re: [BUGS] Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used

Christian Ullrich wrote: > To be honest, I'm not sure what can and cannot be done in auth code. I > took inspiration from the existing SSPI code and nearly every error > check in pg_SSPI_recvauth() ends up doing ereport(ERROR) already, > directly or via pg_SSPI_error(). If this could cause

Re: [BUGS] Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used

* From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com] > Christian Ullrich wrote: > > * Christian Ullrich wrote: > > > > >* From: Magnus Hagander [mailto:mag...@hagander.net] > > > >>Code uses a mix of malloc() and palloc() (through sprintf). Is there > > >>a reason for that? > > > > > >I

Re: [HACKERS] NOT EXIST for PREPARE

On 03/23/2016 09:10 PM, Stephen Frost wrote: * Merlin Moncure (mmonc...@gmail.com) wrote: No one is arguing that that you should send it any every time (at least -- I hope not). I'm not sure I follow how you can avoid that though? pgbouncer in transaction pooling mode may let a particular

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

On Wed, Mar 23, 2016 at 3:18 PM, Stephen Frost wrote: > I have to side with what I believe is Tom's position on this one. I do > like the notion of throwing an error in cases where someone sent us > something that we're pretty sure is wrong, but I don't agree that we > should

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Aleksey Demakov writes: > Hi there, >> On 23 Mar 2016, at 22:38, Tom Lane wrote: >> Anybody want to bikeshed the directory name src/feutils? Maybe fe-utils >> would be more readable. And where to put the corresponding header files? >>

Re: [HACKERS] Alter or rename enum value

> > ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes: > > > > > I was bored and thought "how hard could it be?", and a few hours' > > hacking later, I have something that seems to work. It doesn't do IF > > NOT EXISTS yet, and the error messaging could do with some improvement, > > and there

Re: [HACKERS] Combining Aggregates

On Thu, Mar 24, 2016 at 1:17 PM, Robert Haas wrote: > I'm going to read through the code again now. OK, I noticed another documentation problem: you need to update catalogs.sgml for these new columns. +* Validate the serial function, if present. We must ensure

Re: [HACKERS] Alter or rename enum value

ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes: > > I was bored and thought "how hard could it be?", and a few hours' > hacking later, I have something that seems to work. It doesn't do IF > NOT EXISTS yet, and the error messaging could do with some improvement, > and there are no docs.

Re: [HACKERS] Alter or rename enum value

Matthias Kurz writes: [altering and dropping enum values] >>> Andrew Dunstan writes: >>> > On 03/09/2016 11:07 AM, Tom Lane wrote: >>> >> I have a vague recollection that we discussed this at the time the enum >>> >> stuff went in, and there are

Re: [BUGS] Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used

Christian Ullrich wrote: > * Christian Ullrich wrote: > > >* From: Magnus Hagander [mailto:mag...@hagander.net] > >>Code uses a mix of malloc() and palloc() (through sprintf). Is there a > >>reason for that? > > > >I wasn't sure which to prefer, so I looked around in auth.c, and other than >

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

+ * boxtype_spgist.c The names on the file header need to be changed, too. Oops. fixed 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 + cmp_double(const double a, const double b)

Re: [HACKERS] multivariate statistics v14

Tomas Vondra wrote: > >+values[Anum_pg_mv_statistic_stamcv - 1] = PointerGetDatum(data); > > > >Why the double space (that's actually in several places in several of > >the patches). > > To align the whole block like this: > > nulls[Anum_pg_mv_statistic_stadeps -1] = true; >

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Hi there, > On 23 Mar 2016, at 22:38, Tom Lane wrote: > Anybody want to bikeshed the directory name src/feutils? Maybe fe-utils > would be more readable. And where to put the corresponding header files? > src/include/fe-utils? For me “utils" sounds like something of

Re: [HACKERS] dealing with extension dependencies that aren't quite 'e'

At 2016-03-24 12:31:16 -0300, alvhe...@2ndquadrant.com wrote: > > In other words I think the conclusion here is that we must use > qualified_name in the new production rather than switching the old > production to any_name. Makes sense. > I think I would like to see code implement both

Re: [HACKERS] Combining Aggregates

On Mon, Mar 21, 2016 at 2:18 PM, David Rowley wrote: > I've attached 2 of the patches which are affected by the changes. I think the documentation for 0001 needs some work yet. The additional paragraph that you've added... (1) doesn't seem to appear at a very

Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used

Christian Ullrich writes: > Updated patch attached. Okay, I am happy now. Thanks! signature.asc Description: PGP signature

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 24/03/16 17:28, Robert Haas wrote: On Wed, Mar 23, 2016 at 3:17 AM, Michael Paquier wrote: - 0001 fixes the global declarations of TIMEZONE_GLOBAL and TZNAME_GLOBAL to be WIN32-compliant. I got bitten by that in the ECPG compilation. So this isn't going to break

Re: [HACKERS] Combining Aggregates

On Thu, Mar 24, 2016 at 5:22 AM, David Rowley wrote: > On 21 January 2016 at 08:06, Robert Haas wrote: >> I re-reviewed this and have committed most of it with only minor >> kibitizing. A few notes: > > I realised today that the combinefunc

Re: [HACKERS] btree_gin and btree_gist for enums

Hi Andrew, all, First message here! I didn't get around to sending an intro/"thank you all" e-mail yet, and a small performance (?) patch+idea(s)... (CPU stuff, since I don't otherwise know much about PG internals.) Anyway... - Original Message - From: "Andrew Dunstan" Sent:

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Alvaro Herrera writes: > Tom Lane wrote: >> This name is a bit arbitrary, but most of what's there is string >> processing of some flavor or other, with some list processing thrown >> in for good measure. If anyone's got a different color to paint this >> bikeshed,

Re: [HACKERS] VS 2015 support in src/tools/msvc

On Wed, Mar 23, 2016 at 3:17 AM, Michael Paquier wrote: > - 0001 fixes the global declarations of TIMEZONE_GLOBAL and > TZNAME_GLOBAL to be WIN32-compliant. I got bitten by that in the ECPG > compilation. So this isn't going to break other Windows builds? I mean, if

Re: [HACKERS] NOT EXIST for PREPARE

Tom Lane wrote: because it would break applications I still do not agree with this. The app expects that there can be no mistakes and it does not happen. I can not invent a situation when it is breaks. Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Tom Lane wrote: > What I propose doing is leaving the above-listed items in > pg_dump/dumputils.h/.c, and moving the rest of what's in those files > to new files src/include/fe_utils/string_utils.h and > src/fe_utils/string_utils.c. Seems reasonable. > This name is a bit arbitrary, but most of

Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used

* From: Christian Ullrich > * From: Robbie Harwood [mailto:rharw...@redhat.com] > > > Christian Ullrich writes: > > > + /* Replace domainname with realm name. */ > > > + if (upnamerealmsize > domainnamesize) > > > + { > > > +

Re: [HACKERS] NOT EXIST for PREPARE

Tom> Not to mention that the whole idea of that being a semantically Tom> significant property of a name is a monstrous kluge. You are right here. Just in case, Marko Kreen says (see [1]) pgbouncer has all the information required to remap statement names, so he says pgbouncer needs no

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

On Wed, Mar 23, 2016 at 4:00 PM, Alvaro Herrera wrote: >> Anybody want to bikeshed the directory name src/feutils? Maybe fe-utils >> would be more readable. > > Yes, +1 for either a - or _ in there. I vote for an underscore, since that's what we mostly do. [rhaas

Re: [HACKERS] Show dropped users' backends in pg_stat_activity

Robert Haas writes: > I am not really in favor of half-fixing this. If we can't > conveniently wait until a dropped role is completely out of the > system, then I don't see a lot of point in trying to do it in the > limited cases where we can. If LEFT JOIN is the way to

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

I wrote: > I have a modest proposal for improving this: let's move all the code > that's currently shared by two or more src/bin/ subdirectories into a > new directory, say src/feutils, and build it into a ".a" library in > the same way that src/common/ is handled. Moving along on this project:

Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used

On 2016-03-24 16:35, Christian Ullrich wrote: * From: Robbie Harwood [mailto:rharw...@redhat.com] Christian Ullrich writes: pg_SSPI_recvauth(Port *port) { int mtype; + int status; The section of this

Re: [HACKERS] NOT EXIST for PREPARE

Vladimir Sitnikov writes: > Tom>If you think that's not a protocol change, you are mistaken. It > Tom>changes a behavior that's specified in the protocol documentation. > Even if it requires documentation, this particular change will work seamlessly > across

Re: [HACKERS] NOT EXIST for PREPARE

Tom>If you think that's not a protocol change, you are mistaken. It Tom>changes a behavior that's specified in the protocol documentation. Even if it requires documentation, this particular change will work seamlessly across existing implementations of v3 protocol. For instance, it would not

Re: [HACKERS] Show dropped users' backends in pg_stat_activity

On Tue, Mar 22, 2016 at 11:35 PM, Kyotaro HORIGUCHI wrote: > Even if blocking DROPs is not perfect for all cases, > unconditionally allowing to DROP a role still doesn't seem proper > behavior, especially for replication roles. And session logins > seem to me to

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Robert Haas writes: > On Wed, Mar 23, 2016 at 4:00 PM, Alvaro Herrera > wrote: >> Yes, +1 for either a - or _ in there. > I vote for an underscore, since that's what we mostly do. Yup, I had just counted and come to the same conclusion.

Re: [HACKERS] NOT EXIST for PREPARE

Vladimir Sitnikov wrote: Just to be clear: I'm not fond of encoding the answer to the universe into statement name. However, I find that "name convention" a smart invention. I forgot one more decision: add GUC variable. A little fatty for this but not touch the protocol and easy to implement.

Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used

* From: Robbie Harwood [mailto:rharw...@redhat.com] > Christian Ullrich writes: > > > Updated patch attached. > > I unfortunately don't have windows machines to test this on, but I > thought it might be helpful to review this anyway since I'm touching > code in the same

Re: [HACKERS] Small patch: fix code duplication in heapam.c

> All that code is hotspot stuff, and turning it into a pile of nested > procedures doesn't seem like it improves either performance or > readability. Your concern regarding performance is understandable. But I should note that any standard compiler supports inlining these days (probably this

Re: [HACKERS] dealing with extension dependencies that aren't quite 'e'

Robert Haas wrote: > On Wed, Mar 23, 2016 at 1:00 PM, Abhijit Menon-Sen > wrote: > > Now, the first part of this works fine. But with the second part, I get > > a reduce/reduce conflict if I use any_name. Here's an excerpt from the > > verbose bison output: > > > > State

Re: [BUGS] [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used

On Thu, Mar 24, 2016 at 11:07 AM, Robbie Harwood wrote: > Christian Ullrich writes: > >> Updated patch attached. > > I unfortunately don't have windows machines to test this on, but I > thought it might be helpful to review this anyway since I'm

Re: [HACKERS] dealing with extension dependencies that aren't quite 'e'

On Wed, Mar 23, 2016 at 1:00 PM, Abhijit Menon-Sen wrote: > Now, the first part of this works fine. But with the second part, I get > a reduce/reduce conflict if I use any_name. Here's an excerpt from the > verbose bison output: > > State 2920 > > 1181

Re: [HACKERS] Reworks of CustomScan serialization/deserialization

On Wed, Mar 23, 2016 at 1:36 PM, Petr Jelinek wrote: > Ok, I am happy with it, marked it as ready for committer (it was marked as > committed although it wasn't committed). Thanks for fixing the status. I had forgotten about this thread. I can't really endorse the naming

Re: [HACKERS] NOT EXIST for PREPARE

Vladimir Sitnikov writes: > Craig>I really, really doubt you can change this before we do a > protocol version bump. > Technically speaking, the idea of using first bytes of statement name > to convey extra information does not require protocol version bump. It > can

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

On Thu, Mar 24, 2016 at 5:17 PM, Robert Haas wrote: > On Fri, Mar 18, 2016 at 1:19 PM, Anastasia Lubennikova > wrote: > > Please, find the new version of the patch attached. Now it has WAL > > functionality. > > > > Detailed description of

Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used

Christian Ullrich writes: > Updated patch attached. I unfortunately don't have windows machines to test this on, but I thought it might be helpful to review this anyway since I'm touching code in the same general area (GSSAPI). And as far as I can tell, you don't break

Re: [HACKERS] WIP: Access method extendability

Alvaro Herrera wrote: > Teodor Sigaev wrote: > > > So, per patch status: > > create-am > > ready > > Teodor agreed to me committing this one instead of him; thanks. I just > pushed it after some mostly cosmetic adjustments. This was maybe too laconic. I actually changed the code a good

Re: [HACKERS] NOT EXIST for PREPARE

Craig>I really, really doubt you can change this before we do a protocol version bump. Technically speaking, the idea of using first bytes of statement name to convey extra information does not require protocol version bump. It can be backward and forward compatible. For instance: if statement

Re: [HACKERS] NOT EXIST for PREPARE

On 24 March 2016 at 20:03, Yury Zhuravlev wrote: > I have a big question. What need to do with message protocol? > If we write name in Parse message we store prepared statement. I see some > solutions for this problem but all not ideal: > 1. We can add second char

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

> + * boxtype_spgist.c The names on the file header need to be changed, too. > I'll try to explain with two-dimensional example over points. ASCII-art: >| >| > 1 | 2 >| > ---+- >|P > 3 | 4 >

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

On Thu, Mar 24, 2016 at 7:28 AM, Alexander Korotkov wrote: > Since, patch for exposing current wait event information in PGPROC was > committed, it becomes possible to collect wait event statistics using > sampling. Despite I'm not fan of this approach, it is still

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

Robert Haas writes: > On Wed, Mar 23, 2016 at 6:34 PM, Tom Lane wrote: >> A possibly larger problem is that it causes the SRFs to be evaluated >> before sorting/ordering/limiting. > I'm not sure I understand quite what the problem is here. If you have

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Thu, Mar 24, 2016 at 2:11 AM, Michael Paquier wrote: > On Wed, Mar 23, 2016 at 11:32 PM, Robert Haas wrote: >> Well, I wouldn't go that far. It seems pretty clear that remote_apply >> by itself is useful - I can't imagine anybody seriously

Re: [HACKERS] 2PC support for pglogical

> On 24 Mar 2016, at 17:03, Robert Haas wrote: > > On Wed, Mar 23, 2016 at 1:44 AM, Craig Ringer wrote: >> On 10 March 2016 at 22:50, Stas Kelvich wrote: >>> Hi. >>> >>> Here is proof-of-concept version of two phase

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

On Fri, Mar 18, 2016 at 1:19 PM, Anastasia Lubennikova wrote: > Please, find the new version of the patch attached. Now it has WAL > functionality. > > Detailed description of the feature you can find in README draft > https://goo.gl/50O8Q0 > > This patch is pretty

Re: [HACKERS] Small patch: fix code duplication in heapam.c

Aleksander Alekseev writes: > I discovered that there is a lot of code duplication in heapam.c. > In particular relation_openrv and relation_openrv_extended procedures > and also heap_openrv and heap_openrv_extended procedures are almost the > same. Here is a patch that

Re: [HACKERS] 2PC support for pglogical

On Wed, Mar 23, 2016 at 1:44 AM, Craig Ringer wrote: > On 10 March 2016 at 22:50, Stas Kelvich wrote: >> Hi. >> >> Here is proof-of-concept version of two phase commit support for logical >> replication. > > I missed this when you posted it, so

[HACKERS] avg,first,last,median in one query

Hi, hackers. I need advice from SQL experts: is there any way in PostgreSQL to calculate avg,first,last,median aggregates in one query? Assume that we have the following table: create table Securities ("Symbol" varchar, "Date" date, "Time" time, "Price" real); We can simulate median using

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

On Wed, Mar 23, 2016 at 6:34 PM, Tom Lane wrote: > I wrote: >> ... I'd love to >> toss the entire SRF-in-tlist feature overboard one of these years, >> both because of semantic issues like these and because a fair amount >> of code and overhead could be ripped out if it were

[HACKERS] Small patch: Change calling convention for ShmemInitHash (and fix possible bug)

Hello I would like to continue discussion regarding changing calling convention for ShmemInitHash procedure: http://www.postgresql.org/message-id/CA+TgmoZm=uowt8a_xasfoogwufeelj861ntadiceopyfehv...@mail.gmail.com Currently this procedure has two arguments --- init_size and max_size. But since

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

On Thu, Mar 24, 2016 at 2:26 PM, Kyotaro HORIGUCHI wrote: > Hello, > > At Thu, 24 Mar 2016 13:04:49 +0900, Masahiko Sawada > wrote in

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

On Thu, Mar 24, 2016 at 8:08 AM, Amit Kapila wrote: > > On Thu, Mar 24, 2016 at 5:40 AM, Andres Freund wrote: > > > > Have you, in your evaluation of the performance of this patch, done > > profiles over time? I.e. whether the performance benefits are

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On Thu, Mar 24, 2016 at 9:01 AM, Robert Haas wrote: > On Thu, Mar 24, 2016 at 8:45 AM, Rahila Syed wrote: >> Server crash was reported on running vacuum progress checker view on 32-bit >> machine. >> Please find attached a fix for the same. >> >>

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On Thu, Mar 24, 2016 at 8:45 AM, Rahila Syed wrote: > Server crash was reported on running vacuum progress checker view on 32-bit > machine. > Please find attached a fix for the same. > > Crash was because 32 bit machine considers int8 as being passed by reference > while

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hello, Server crash was reported on running vacuum progress checker view on 32-bit machine. Please find attached a fix for the same. Crash was because 32 bit machine considers int8 as being passed by reference while creating the tuple descriptor. At the time of filling the tuple store, the code

Re: [HACKERS] WIP: Access method extendability

Teodor Sigaev wrote: > So, per patch status: > create-am > ready Teodor agreed to me committing this one instead of him; thanks. I just pushed it after some mostly cosmetic adjustments. I pass the baton back to Teodor for the remaining patches in this series. Thanks, -- Álvaro Herrera

Re: [HACKERS] NOT EXIST for PREPARE

I have a big question. What need to do with message protocol? If we write name in Parse message we store prepared statement. I see some solutions for this problem but all not ideal: 1. We can add second char token for parse message. But too serious change. 2. We can try add parameter to tail of

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

Hi! Since, patch for exposing current wait event information in PGPROC was committed, it becomes possible to collect wait event statistics using sampling. Despite I'm not fan of this approach, it is still useful and definitely better than nothing. In PostgresPro, we actually already had it.

Re: [HACKERS] Alter or rename enum value

On 9 March 2016 at 20:19, Matthias Kurz wrote: > Besides not being able to rename enum values there are two other > limitations regarding enums which would be nice to get finally fixed: > > 1) There is also no possibility to drop a value. > > 2) Quoting the docs ( >

Re: [HACKERS] Relation extension scalability

On Thu, Mar 24, 2016 at 6:13 PM, Amit Kapila wrote: > > 1. > +GetPageWithFreeSpaceUsingOldPage(Relation rel, BlockNumber oldPage, > + Size spaceNeeded) > { > .. > + /* > + * If fsm_set_and_search found a suitable new block, return that. > + * Otherwise, search as usual.

Re: [HACKERS] Relation extension scalability

On Thu, Mar 24, 2016 at 1:48 PM, Petr Jelinek wrote: > > On 24/03/16 07:04, Dilip Kumar wrote: >> >> >> On Thu, Mar 24, 2016 at 10:44 AM, Robert Haas > > wrote: >> >> On Wed, Mar 23, 2016 at 9:43 PM, Amit Kapila >>

Re: [HACKERS] NOT EXIST for PREPARE

Michael Meskes wrote: While ecpg may not be the choice for new applications, there are a lot of legacy applications out there that need ecpg to be migrated to PostgreSQL. 2016 is a good time to rewrite them. ;) I think Postgres will be more likely if it would be a little less concerned about

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

On Thu, Mar 24, 2016 at 2:26 PM, Kyotaro HORIGUCHI wrote: > Hello, > > At Thu, 24 Mar 2016 13:04:49 +0900, Masahiko Sawada > wrote in

Re: [HACKERS] Odd system-column handling in postgres_fdw join pushdown patch

On Thu, Mar 24, 2016 at 9:31 AM, Etsuro Fujita wrote: > On 2016/03/23 13:44, Ashutosh Bapat wrote: > >> An FDW can choose not to use those functions, so I don't see a >> connection between scan list having simple Vars and existence of those >> functions (actually a

Re: [HACKERS] Postgres_fdw join pushdown - getting server crash in left outer join of three table

> > Thanks for the report and the testing. I have committed the patch. > > Thanks. > Cool, I have refreshed the wiki page for open items accordingly. > Thanks. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company

Re: [HACKERS] Combining Aggregates

On 21 January 2016 at 08:06, Robert Haas wrote: > I re-reviewed this and have committed most of it with only minor > kibitizing. A few notes: I realised today that the combinefunc is rather undocumented. I've attached a patch which aims to fix this. Comments are welcome.

[HACKERS] Small patch: fix code duplication in heapam.c

Hello I discovered that there is a lot of code duplication in heapam.c. In particular relation_openrv and relation_openrv_extended procedures and also heap_openrv and heap_openrv_extended procedures are almost the same. Here is a patch that fixes this. -- Best regards, Aleksander Alekseev

Re: [HACKERS] Relation extension scalability

On 24/03/16 07:04, Dilip Kumar wrote: On Thu, Mar 24, 2016 at 10:44 AM, Robert Haas > wrote: On Wed, Mar 23, 2016 at 9:43 PM, Amit Kapila > wrote: >

Re: [HACKERS] NOT EXIST for PREPARE

> I want to understand the situation. You may want to make the build > ecpg  > optional. Personally, I want to. You lost me here, sorry. What exactly do you want to do?  While ecpg may not be the choice for new applications, there are a lot of legacy applications out there that need ecpg to be

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

On Tue, Mar 22, 2016 at 5:05 AM, Kevin Grittner wrote: > Thanks to all for the feedback; I will try to respond later this > week. First I'm trying to get my reviews for other patches posted. I have been looking at 4a, the test module, and things are looking good IMO.

[HACKERS] MSVC scripts missing some isolation/regression tests

Hi all, While looking at the buildfarm and reviewing the old snapshot patch, I noticed that isolation tests cannot run with MSVC scripts all the time. Take for example that: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=currawong=2016-03-24%2004%3A55%3A21 Which leads to the following

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Wed, Mar 23, 2016 at 11:32 PM, Robert Haas wrote: > Well, I wouldn't go that far. It seems pretty clear that remote_apply > by itself is useful - I can't imagine anybody seriously arguing the > contrary, whatever they think of this implementation. My view, > though, is

  1   2   >