Re: [HACKERS] Alter or rename enum value

On Friday, March 25, 2016, Andrew Dunstan wrote: > > On 03/25/2016 04:13 AM, Matthias Kurz wrote: > >> >> Hopefully at the commitfest at least the transaction limitation >> will/could be tackled - that would help us a lot already. >> >> > I don't believe anyone knows how to

Re: [HACKERS] Combining Aggregates

On 26 March 2016 at 15:07, David Rowley wrote: > Ok, so on further look at this I've decided to make changes and have > it so the serialisation function can be dumb about memory contexts in > the same way as finalize_aggregate() allows the final function to be >

[HACKERS] If a schema is created as part of an extension, should all user created tables created in that schema be considered part of the extension?

I just discovered something which was a little alarming to me. In the postgis_tiger_geocoder extension, I had switched to having the schema where user data download is stored created as part of create extension script so I wouldn't need to check during load. So I have a statement like this 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: > > > > Even after changing to scale 500, the performance benefits on this, > > older 2 socket, machine were minor; even though contention on

Re: [HACKERS] Alter or rename enum value

On 03/25/2016 03:22 PM, Christophe Pettus wrote: On Mar 25, 2016, at 11:50 AM, Andrew Dunstan wrote: I don't believe anyone knows how to do that safely. The core issue, for me, is that not being able to modify enum values in a transaction breaks a very wide variety of

Re: [HACKERS] Relation extension scalability

On Fri, Mar 25, 2016 at 1:05 PM, Dilip Kumar wrote: > On Fri, Mar 25, 2016 at 3:04 AM, Robert Haas wrote: >> 1. Callers who use GetPageWithFreeSpace() rather than >> GetPageFreeSpaceExtended() will fail to find the new pages if the >> upper map

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

Hi, Dilip! On Fri, Mar 25, 2016 at 8:32 PM, Dilip Kumar wrote: > On Fri, Mar 25, 2016 at 8:09 PM, Alexander Korotkov < > a.korot...@postgrespro.ru> wrote: > >> Could anybody run benchmarks? Feature freeze is soon, but it would be >> *very nice* to fit it into 9.6 release

Re: [HACKERS] multivariate statistics v14

Tomas Vondra writes: > I could do that, but isn't that a bit pointless? I thought pgindent is > run regularly on the whole codebase, not for individual patches. Sure, > it'll tweak the formatting on a few places in the patch (including the > code discussed above,

Re: [HACKERS] Improve error handling in pltcl

On 3/25/16 3:11 PM, Tom Lane wrote: Jim Nasby writes: the data, we're making it unnecessarily hard. All we need is one more field in there, and you can simplify that to Ahh, nice. I think actually it's a simple point: there won't ever be a case where cursorpos is

Re: [HACKERS] [PATCH] Phrase search ported to 9.6

On 3/25/16 3:54 PM, Artur Zakirov wrote: > On 25.03.2016 21:42, Dmitry Ivanov wrote: >> Sorry for the delay, I desperately needed some time to finish a bunch of >> dangling tasks. >> >> I've added some new comments and clarified the ones that were obscure. >> Moreover, I felt an urge to recheck

[HACKERS] Can we amend gitattributes so git postgresql works with git on windows using Msys/Mingw64

Typo in my last subject line - meant gitattributes. So should have lines added like below *.sheol=lf *.ineol=lf *.h.in eol=lf *.h eol=lf Thanks, Regina -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

[HACKERS] Can we amend gitignore so git postgresql works with git on windows using Msys/Mingw64

Tom et. al, Thanks for fixing the SRF function order by thing. That test now passes now, but there is one other test failing I was going to troubleshoot. The problem is I can't compile from git postgresql, and the issue is I think because my git when it pulls down the files they come in as CRLF

Re: [HACKERS] Improve error handling in pltcl

Jim Nasby writes: > On 3/17/16 5:46 PM, Tom Lane wrote: >> I started to look at this patch. It seems to me that the format of the >> errorCode output is not terribly well designed. > Getting the errorCode into an array is as easy as > array set errorData [lrange

Re: [HACKERS] [PATCH] Phrase search ported to 9.6

On 25.03.2016 21:42, Dmitry Ivanov wrote: Sorry for the delay, I desperately needed some time to finish a bunch of dangling tasks. I've added some new comments and clarified the ones that were obscure. Moreover, I felt an urge to recheck most parts of the code since apparently nobody (besides

Re: [HACKERS] Alter or rename enum value

On 3/25/16 2:22 PM, Gavin Flower wrote: I've certainly heard people avoiding ENUMs because of their limitations, so it'd be nice if there was a way to lift them. Well, I use Enums extensively in Java. However, I totally avoid using ENUMs in pg, due to their inflexibility! Possibly related

Re: [HACKERS] [PATCH] Phrase search ported to 9.6

On 3/25/16 2:42 PM, Dmitry Ivanov wrote: > Sorry for the delay, I desperately needed some time to finish a bunch of > dangling tasks. > > I've added some new comments and clarified the ones that were obscure. > Moreover, I felt an urge to recheck most parts of the code since apparently >

Re: [HACKERS] Alter or rename enum value

Andrew Dunstan writes: > On 03/25/2016 04:13 AM, Matthias Kurz wrote: >> >> Hopefully at the commitfest at least the transaction limitation >> will/could be tackled - that would help us a lot already. > > I don't believe anyone knows how to do that safely. Enums pose special

Re: [HACKERS] Alter or rename enum value

On Mar 25, 2016, at 11:50 AM, Andrew Dunstan wrote: > I don't believe anyone knows how to do that safely. The core issue, for me, is that not being able to modify enum values in a transaction breaks a very wide variety of database migration tools. Even a very brutal

Re: [HACKERS] Alter or rename enum value

On 26/03/16 08:17, Jim Nasby wrote: On 3/24/16 10:27 PM, Tom Lane wrote: It's conceivable that we could do something like adding an "isdead" column to pg_enum and making enum_in reject new values that're marked isdead. But I can't see that we'd ever be able to support true removal of an enum

Re: [HACKERS] Alter or rename enum value

On 3/24/16 10:27 PM, Tom Lane wrote: It's conceivable that we could do something like adding an "isdead" column to pg_enum and making enum_in reject new values that're marked isdead. But I can't see that we'd ever be able to support true removal of an enum value at reasonable cost. And I'm not

Re: [HACKERS] btree_gin and btree_gist for enums

On 03/24/2016 12:40 PM, Matt Wilmas wrote: (I notice the btree_gin docs don't mention "numeric," but it works.) Numeric does work - we have regression tests to prove it, do we should fix the docs. But I'm also curious to know why apparently we don't have distance operator support for

Re: [HACKERS] Alter or rename enum value

On 03/25/2016 04:13 AM, Matthias Kurz wrote: Hopefully at the commitfest at least the transaction limitation will/could be tackled - that would help us a lot already. I don't believe anyone knows how to do that safely. Enums pose special problems here exactly because unlike all other

Re: [HACKERS] [PATCH] Phrase search ported to 9.6

Sorry for the delay, I desperately needed some time to finish a bunch of dangling tasks. I've added some new comments and clarified the ones that were obscure. Moreover, I felt an urge to recheck most parts of the code since apparently nobody (besides myself) has gone so far yet. On 25.03.16

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

> 25 марта 2016 г., в 19:11, David Steele написал(а): > > Hi Vladimir, > > On 3/14/16 2:15 PM, Vladimir Borodin wrote: > >> JFYI, I’m preparing the stand to reproduce the initial problem and I >> hope to finish testing this week. > > Do you know when you'll have the

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

At 2016-03-24 22:48:51 +0530, a...@2ndquadrant.com wrote: > > > I think I would like to see code implement both alternatives to see > > which one is least ugly. Maybe a third idea will manifest itself > > upon seeing those. > > Here's the first one. ExecAlterObjectDependsStmt() looks like this:

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

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 | JB_PATH_CREATE) Good idea, thanks. > 5. > > if (op_type !=

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Fri, Mar 25, 2016 at 8:09 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > Could anybody run benchmarks? Feature freeze is soon, but it would be > *very nice* to fit it into 9.6 release cycle, because it greatly improves > scalability on large machines. Without this patch

Re: [HACKERS] Relation extension scalability

On Fri, Mar 25, 2016 at 3:04 AM, Robert Haas wrote: > 1. Callers who use GetPageWithFreeSpace() rather than > GetPageFreeSpaceExtended() will fail to find the new pages if the > upper map levels haven't been updated by VACUUM. > > 2. Even callers who use

Re: [HACKERS] [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator

On Fri, Mar 25, 2016 at 12:39 PM, Tom Lane wrote: > I wrote: >> Robert Haas writes: >>> On Wed, Mar 23, 2016 at 12:27 PM, Tom Lane wrote: We could resolve both of these issues by changing the semantics of OprUpdate so that

Re: [HACKERS] [COMMITTERS] pgsql: Move each SLRU's lwlocks to a separate tranche.

Robert Haas writes: > On Fri, Mar 25, 2016 at 9:48 AM, Tom Lane wrote: >> Robert Haas writes: >>> It's stupid that we keep spending time and energy figuring out which >>> shared memory data structures require alignment and which

Re: [HACKERS] [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator

I wrote: > Robert Haas writes: >> On Wed, Mar 23, 2016 at 12:27 PM, Tom Lane wrote: >>> We could resolve both of these issues by changing the semantics of >>> OprUpdate so that it unconditionally does a CommandCounterIncrement >>> after each update that

Re: [HACKERS] unexpected result from to_tsvector

On 25.03.2016 19:15, David Steele wrote: On 3/25/16 12:14 PM, Artur Zakirov wrote: On 25.03.2016 18:19, David Steele wrote: Hi Artur, On 3/20/16 10:42 AM, Tom Lane wrote: "Shulgin, Oleksandr" writes: On Mar 20, 2016 01:09, "Dmitrii Golub"

Re: [HACKERS] unexpected result from to_tsvector

On 3/25/16 12:14 PM, Artur Zakirov wrote: On 25.03.2016 18:19, David Steele wrote: Hi Artur, On 3/20/16 10:42 AM, Tom Lane wrote: "Shulgin, Oleksandr" writes: On Mar 20, 2016 01:09, "Dmitrii Golub" wrote: Alex, actually subdomain can

Re: [HACKERS] unexpected result from to_tsvector

On 25.03.2016 18:19, David Steele wrote: Hi Artur, On 3/20/16 10:42 AM, Tom Lane wrote: "Shulgin, Oleksandr" writes: On Mar 20, 2016 01:09, "Dmitrii Golub" wrote: Alex, actually subdomain can start with digit, Not according to the

Re: [HACKERS] PATCH: use foreign keys to improve join estimates v1

Hi Simon, On 3/14/16 3:42 PM, Tomas Vondra wrote: Attached is v3 of the patch, and also three SQL scripts demonstrating the impact of the patch on simple examples. Do you know when you'll have a chance to review Tomas' latest patch? Thanks, -- -David da...@pgmasters.net -- Sent via

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

Hi Vladimir, On 3/14/16 2:15 PM, Vladimir Borodin wrote: JFYI, I’m preparing the stand to reproduce the initial problem and I hope to finish testing this week. Do you know when you'll have the results from the testing you were going to do? It seems this patch is currently waiting on that

Re: [HACKERS] [PATCH] Phrase search ported to 9.6

On Fri, Mar 25, 2016 at 6:42 PM, David Steele wrote: > On 3/16/16 12:38 PM, Dmitry Ivanov wrote: > > I've made an attempt to fix some of the issues you've listed, although >> there's >> still much work to be done. I'll add some comments later. >> > > Do you know when you'll

Re: [HACKERS] Batch update of indexes

On 3/14/16 10:37 AM, David Steele wrote: On 3/14/16 10:28 AM, Konstantin Knizhnik wrote: Rebased patch is attached. Thanks for the quick turnaround! Marko, you are signed up to review this patch. Do you have an idea of when you'll be able to do that? Bump. Since it looks like Marko has

[HACKERS] Re: WIP: Detecting SSI conflicts before reporting constraint violations

Hi Thomas, On 3/13/16 8:20 PM, Thomas Munro wrote: <...> I will have another look at this in a few days but for now I need to do some other things, so I'm posting these observations in case they are in some way helpful... It's not clear to me what state this patch should be in but the

Re: [HACKERS] [PATCH] Phrase search ported to 9.6

Hi Dmitry, On 3/16/16 12:38 PM, Dmitry Ivanov wrote: I've made an attempt to fix some of the issues you've listed, although there's still much work to be done. I'll add some comments later. Do you know when you'll have a chance to respond to reviews and provide a new patch? Time is short

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

> In short: the error in Aleksander's argument is the assumption that > shared hashtables have fixed size. That's simply false. Well this is a bit embarrassing but I have to admit that you are right. Dynahash code is a bit non-trivial to say the least (let me guess - there is no point of

Re: [HACKERS] multivariate statistics v14

On 03/24/2016 06:45 PM, Alvaro Herrera wrote: 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:

Re: [HACKERS] unexpected result from to_tsvector

Hi Artur, On 3/20/16 10:42 AM, Tom Lane wrote: "Shulgin, Oleksandr" writes: On Mar 20, 2016 01:09, "Dmitrii Golub" wrote: Alex, actually subdomain can start with digit, Not according to the RFC you have linked to. The

Re: [HACKERS] [COMMITTERS] pgsql: Move each SLRU's lwlocks to a separate tranche.

On Fri, Mar 25, 2016 at 9:48 AM, Tom Lane wrote: > Robert Haas writes: >> It's stupid that we keep spending time and energy figuring out which >> shared memory data structures require alignment and which ones don't. >> Let's just align them *all* and be

Re: [HACKERS] POC, WIP: OR-clause support for indexes

Hi Teador, On 3/19/16 8:44 PM, Tomas Vondra wrote: Sadly the v4 does not work for me - I do get assertion failures. Time is growing short and there seem to be some serious concerns with this patch. Can you provide a new patch soon? If not, I think it might be be time to mark this

[HACKERS] A question on systable_beginscan()

Hi hackers, As it's documented in the source code, systable_beginscan() could be used to on non-system tables as well. My question is that, is it possible to write a C code with systable_beginscan(), systable_getnext() and ScanKeys which is equivalent to the following query: (Assume that the

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Tue, Mar 22, 2016 at 1:08 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Tue, Mar 22, 2016 at 7:57 AM, Dilip Kumar > wrote: > >> >> On Tue, Mar 22, 2016 at 12:31 PM, Dilip Kumar >> wrote: >> >>> ! pg_atomic_write_u32(>state,

Re: [HACKERS] WIP: Access method extendability

On Thu, Mar 24, 2016 at 6:19 PM, Alvaro Herrera wrote: > .. Oh crap. I just noticed I forgot to update a comment in pg_dump's > getAccessMethods. And we're missing psql tab-complete support for the > new commands. Attached patches fix both these issues. --

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

Michael Paquier writes: > On Fri, Mar 25, 2016 at 9:17 PM, Robert Haas wrote: >> On Thu, Mar 24, 2016 at 9:50 AM, Aleksander Alekseev >> wrote: >>> Currently this procedure has two arguments --- init_size and max_size.

Re: [HACKERS] [COMMITTERS] pgsql: Move each SLRU's lwlocks to a separate tranche.

On March 25, 2016 2:48:00 PM GMT+01:00, Robert Haas wrote: >On Fri, Mar 25, 2016 at 9:11 AM, Andres Freund >wrote: >> On March 25, 2016 1:04:13 PM GMT+01:00, Robert Haas > wrote: >>>On Fri, Mar 25, 2016 at 3:05 AM, Andres

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

On Fri, Mar 25, 2016 at 4:51 PM, Thomas Munro wrote: > On Thu, Mar 24, 2016 at 12:34 AM, Thomas Munro > wrote: >> On Wed, Mar 23, 2016 at 12:37 PM, Robert Haas wrote: >>> +static void WalRcvUnblockSigUsr2(void)

Re: [HACKERS] [COMMITTERS] pgsql: Move each SLRU's lwlocks to a separate tranche.

Robert Haas writes: > It's stupid that we keep spending time and energy figuring out which > shared memory data structures require alignment and which ones don't. > Let's just align them *all* and be done with it. The memory cost > shouldn't be more than a few kB. I think

Re: [HACKERS] [COMMITTERS] pgsql: Move each SLRU's lwlocks to a separate tranche.

On Fri, Mar 25, 2016 at 9:11 AM, Andres Freund wrote: > On March 25, 2016 1:04:13 PM GMT+01:00, Robert Haas > wrote: >>On Fri, Mar 25, 2016 at 3:05 AM, Andres Freund >>wrote: >>> On 2015-11-12 19:59:54 +, Robert Haas wrote:

Re: [HACKERS] NOT EXIST for PREPARE

On Wed, Mar 23, 2016 at 3:10 PM, Stephen Frost wrote: > Merlin, > > * 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

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

On Fri, Mar 25, 2016 at 10:10 PM, David Steele wrote: > Excellent, Robbie! I've run this patch through my test cases and > everything works. > > Now that it's working I'll be writing up an actual review so expect that > by Monday. (I haven't given up on this patch yet,

Re: [HACKERS] [COMMITTERS] pgsql: Move each SLRU's lwlocks to a separate tranche.

On March 25, 2016 1:04:13 PM GMT+01:00, Robert Haas wrote: >On Fri, Mar 25, 2016 at 3:05 AM, Andres Freund >wrote: >> On 2015-11-12 19:59:54 +, Robert Haas wrote: >>> Move each SLRU's lwlocks to a separate tranche. >>> >>> This makes it

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

On 3/20/16 12:09 AM, Robbie Harwood wrote: > Hello friends, > > 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/gssencrypt8 Excellent, Robbie! I've run this patch through my test cases

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

On Fri, Mar 25, 2016 at 9:48 PM, Andrew Dunstan wrote: > OK, sounds good. I don't have a spare machine on which to install VS2015, > nor time to set one up, so I'm going to have to trust the two of you > (Michael and Petr) that this works. With Virtual Box, you could set up

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

On Fri, Mar 25, 2016 at 9:55 PM, Robert Haas wrote: > On Fri, Mar 25, 2016 at 8:31 AM, Michael Paquier > wrote: > The relationship between doc/src/sgml/install-windows.sgml, the > section of doc/src/sgml/installation.sgml entitled "MinGW/Native >

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

> I think this is a waste of time. These functions are already very > short; making them shorter will not significantly improve readability. > It'll just force people who think they know what that code does to > look at it again to see if it still does the same thing. > > Let's spend our time

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

On Fri, Mar 25, 2016 at 8:31 AM, Michael Paquier wrote: > On Fri, Mar 25, 2016 at 9:09 PM, Robert Haas wrote: >> On Thu, Mar 24, 2016 at 1:07 PM, Petr Jelinek wrote: >>> On 24/03/16 17:28, Robert Haas wrote: On Wed,

Re: [HACKERS] 2PC support for pglogical

On 24 March 2016 at 22:20, Stas Kelvich wrote: > > I think all the locking already handled properly by creating dummy backend > in PGPROC, as it done in usual postgres 2pc implementation. > > On the downstream, yes. But what about the decoding, reorder buffer and

Re: [HACKERS] NOT EXIST for PREPARE

On 24 March 2016 at 23:13, Vladimir Sitnikov wrote: > > >doesn't have any kind of capabilities negotiation > > Do you think capability negotiation should indeed be at the protocol level? > What's wrong with say "select * from backend_capabilities" at the > connection

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

On 03/25/2016 08:31 AM, Michael Paquier wrote: On Fri, Mar 25, 2016 at 9:09 PM, Robert Haas wrote: On Thu, Mar 24, 2016 at 1:07 PM, Petr Jelinek wrote: On 24/03/16 17:28, Robert Haas wrote: On Wed, Mar 23, 2016 at 3:17 AM, Michael Paquier

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

On Fri, Mar 25, 2016 at 9:17 PM, Robert Haas wrote: > On Thu, Mar 24, 2016 at 9:50 AM, Aleksander Alekseev > wrote: >> Currently this procedure has two arguments --- init_size and max_size. >> But since shared hash tables have fixed size there is

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

> No, I think we left it that way on purpose. I don't remember the > discussion exactly, but I don't think it's hurting anything. This was a part of original dynahash optimization patch. Since that patch was about performance improvement and this concrete change is about refactoring, not

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

On Fri, Mar 25, 2016 at 9:09 PM, Robert Haas wrote: > On Thu, Mar 24, 2016 at 1:07 PM, Petr Jelinek wrote: >> On 24/03/16 17:28, Robert Haas wrote: >>> On Wed, Mar 23, 2016 at 3:17 AM, Michael Paquier >>> wrote: -

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

On Thu, Mar 24, 2016 at 9:29 AM, Masahiko Sawada wrote: > Also I felt a sense of discomfort regarding using [ and ] as a special > character for priority method. > Because (, ) and [, ] are a little similar each other, so it would > easily make many syntax errors when

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

On Thu, Mar 24, 2016 at 9:50 AM, Aleksander Alekseev wrote: > I would like to continue discussion regarding changing calling > convention for ShmemInitHash procedure: > >

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

On Thu, Mar 24, 2016 at 11:35 AM, Aleksander Alekseev wrote: > In the same time I'm deeply convinced that this patch will make code > more readable at least because it makes code much shorter: I think this is a waste of time. These functions are already very short;

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

On Thu, Mar 24, 2016 at 1:07 PM, Petr Jelinek wrote: > 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

Re: [HACKERS] [COMMITTERS] pgsql: Move each SLRU's lwlocks to a separate tranche.

On Fri, Mar 25, 2016 at 3:05 AM, Andres Freund wrote: > On 2015-11-12 19:59:54 +, Robert Haas wrote: >> Move each SLRU's lwlocks to a separate tranche. >> >> This makes it significantly easier to identify these lwlocks in >> LWLOCK_STATS or Trace_lwlocks output. It's also

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

>Oops. I forgot to credit you in the commit message. Sorry about that. :-( No problem :). Thanks for the commit. Thank you, Rahila Syed

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

On 2016/03/25 13:37, Ashutosh Bapat wrote: 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

Re: [HACKERS] Alter or rename enum value

> > It's conceivable that we could do something like adding an "isdead" > column to pg_enum and making enum_in reject new values that're marked > isdead. But I can't see that we'd ever be able to support true > removal of an enum value at reasonable cost. And I'm not really sure > where the

Re: [HACKERS] Performance degradation in commit 6150a1b0

On 2016-03-25 09:29:34 +0530, Amit Kapila wrote: > > 2. Secondly, i can see that the BufferDesc structure padding is 64 bytes > however the PG CACHE LINE ALIGNMENT is 128 bytes. Also, after changing the > BufferDesc structure padding size to 128 bytes along with the changes > mentioned in above

[HACKERS] Re: [COMMITTERS] pgsql: Move each SLRU's lwlocks to a separate tranche.

On 2015-11-12 19:59:54 +, Robert Haas wrote: > Move each SLRU's lwlocks to a separate tranche. > > This makes it significantly easier to identify these lwlocks in > LWLOCK_STATS or Trace_lwlocks output. It's also arguably better > from a modularity standpoint, since lwlock.c no longer needs

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

On Fri, Mar 25, 2016 at 3:10 PM, Michael Paquier wrote: > On Thu, Mar 24, 2016 at 1:02 PM, Etsuro Fujita > wrote: >> Thanks for the report, Thom! Thanks for the advice, Michael! > > I am adding that to the list of open items of 9.6 to not

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

On Thu, Mar 24, 2016 at 1:02 PM, 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