Re: [HACKERS] A couple of postgresql.conf.sample discrepancies

Hi Thomas, > Here's a script that reminds you about GUCs you forgot to put in > postgresql.conf.sample. It probably needs some work. Does this > already happen somewhere else? I guess not, because it found two > discrepancies: > > $ ./src/tools/check_sample_config.pl > enable_gathermerge

Re: [HACKERS] AlterUserStmt anmd RoleSpec rules in grammar.y

Hello, Tom. You wrote: TL> Pavel Golub writes: >> I need someone to throw some light on grammar (gram.y). >> I'm investigating beta2 regression tests, and found new statement >> `ALTER USER ALL SET application_name to 'SLAP';` >> ^^^ TL> You'll notice that

Re: [HACKERS] Increase Vacuum ring buffer.

On Tue, Jul 25, 2017 at 2:27 AM, Claudio Freire wrote: > On Mon, Jul 24, 2017 at 2:20 PM, Claudio Freire > wrote: >> On Mon, Jul 24, 2017 at 2:10 PM, Sokolov Yura >> wrote: >>> On 2017-07-24 19:11, Claudio Freire

Re: [HACKERS] Remove old comments in dependencies.c and README.dependencies

> Agreed. Removed those comments. Thanks for the patch. Thanks! On 2017/07/27 0:44, Alvaro Herrera wrote: atorikoshi wrote: Attached patch removes the comments about min_group_size. Agreed. Removed those comments. Thanks for the patch. -- Atsushi Torikoshi NIPPON TELEGRAPH AND

Re: [HACKERS] AlterUserStmt anmd RoleSpec rules in grammar.y

Hello, Tom. You wrote: TL> Pavel Golub writes: >> I need someone to throw some light on grammar (gram.y). >> I'm investigating beta2 regression tests, and found new statement >> `ALTER USER ALL SET application_name to 'SLAP';` >> ^^^ TL> You'll notice that

Re: [HACKERS] Increase Vacuum ring buffer.

On 2017-07-26 20:28, Sokolov Yura wrote: On 2017-07-26 19:46, Claudio Freire wrote: On Wed, Jul 26, 2017 at 1:39 PM, Sokolov Yura wrote: On 2017-07-24 12:41, Sokolov Yura wrote: test_master_1/pretty.log ... time activity tps latency stddev min

Re: [HACKERS] Transactions involving multiple postgres foreign servers

> On 27 Jul 2017, at 04:28, Robert Haas wrote: > > However, you would not > be guaranteed that all of those commits or rollbacks happen at > anything like the same time. So, you would have a sort of eventual > consistency. As far as I understand any solution that

Re: [HACKERS] Increase Vacuum ring buffer.

On Thu, Jul 27, 2017 at 5:48 PM, Sokolov Yura wrote: > On 2017-07-27 11:30, Masahiko Sawada wrote: >> >> On Tue, Jul 25, 2017 at 2:27 AM, Claudio Freire >> wrote: >>> >>> On Mon, Jul 24, 2017 at 2:20 PM, Claudio Freire

Re: [HACKERS] Increase Vacuum ring buffer.

On 2017-07-27 11:30, Masahiko Sawada wrote: On Tue, Jul 25, 2017 at 2:27 AM, Claudio Freire wrote: On Mon, Jul 24, 2017 at 2:20 PM, Claudio Freire wrote: On Mon, Jul 24, 2017 at 2:10 PM, Sokolov Yura wrote: On

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

On Thu, Jul 27, 2017 at 3:31 AM, Mark Rofail wrote: > I have written some benchmark test. > > With two tables a PK table with 5 rows and an FK table with growing row > count. > > Once triggering an RI check > at 10 rows, > 100 rows, > 1,000 rows, > 10,000 rows, > 100,000

Re: [HACKERS] [POC] hash partitioning

Attaching newer patches rebased against the latest master head. Thanks ! Regards, Amul 0001-Cleanup_v6.patch Description: Binary data 0002-hash-partitioning_another_design-v16.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

On Thu, Jul 27, 2017 at 12:54 PM, Alexander Korotkov wrote: > > How many rows of FK table were referencing the PK table row you're > updating/deleting. > I wonder how may RI trigger work so fast if it has to do some job besides > index search with no results? > The problem

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Thu, Jul 27, 2017 at 6:58 AM, Robert Haas wrote: > > On a technical level, I am pretty sure that it is not OK to call > AtEOXact_FDWXacts() from the sections of CommitTransaction, > AbortTransaction, and PrepareTransaction that are described as > "non-critical resource

Re: [HACKERS] asynchronous execution

On Wed, Jul 26, 2017 at 5:43 PM, Tom Lane wrote: > I have not been paying any attention to this thread whatsoever, > but I wonder if you can address your problem by building on top of > the ExecProcNode replacement that Andres is working on, >

Re: [HACKERS] pl/perl extension fails on Windows

Hi All, On Wed, Jul 26, 2017 at 7:56 PM, Ashutosh Sharma wrote: > On Wed, Jul 26, 2017 at 8:51 AM, Tom Lane wrote: >> Robert Haas writes: >>> Based on discussion downthread, it seems like what we actually need to >>> do is

Re: [HACKERS] A couple of postgresql.conf.sample discrepancies

On Thu, Jul 27, 2017 at 10:27 AM, Aleksander Alekseev wrote: >> Here's a script that reminds you about GUCs you forgot to put in >> postgresql.conf.sample. It probably needs some work. Does this >> already happen somewhere else? I guess not, because it found two >>

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Thu, Jul 27, 2017 at 5:08 AM, Stas Kelvich wrote: > As far as I understand any solution that provides proper isolation for > distributed > transactions in postgres will require distributed 2PC somewhere under the > hood. > That is just consequence of parallelism

Re: [HACKERS] [patch] pg_dump/pg_restore zerror() and strerror() mishap

Hello, Alvaro, thanks for the suggestions, attached version #3 with all of your requirements met. -- С уважением, Владимир Кунщиков Ведущий программист Отдел разработки систем обнаружения и предотвращения компьютерных атак Компания "ИнфоТеКС"

Re: [HACKERS] expand_dbname in postgres_fdw

On Thu, Jul 27, 2017 at 12:21 AM, Tom Lane wrote: > The main problem to my mind is that a connection string could possibly > override items meant to be specified elsewhere. In particular it ought > not be allowed to specify the remote username or password, because those > are

Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" in child table must be marked NOT NULL

On Wed, Jul 26, 2017 at 4:50 PM, Michael Paquier wrote: > On Wed, Jul 26, 2017 at 4:02 PM, Tom Lane wrote: >> Not sure what's involved there code-wise, though, nor whether we'd want >> to back-patch. > > I'll try to look at the code around that to

[HACKERS] tab completion for "create user mapping for"

If you have "CREATE USE" tab completion will recommend both USER and USER MAPPING FOR. But once you have the full "CREATE USER " or "CREATE USER M" it will not complete the rest of the "MAPPING FOR". Attached patch fixes that. Cheers, Jeff user_mapping_tab_complete_v1.patch Description:

Re: [HACKERS] pl/perl extension fails on Windows

On Thu, Jul 27, 2017 at 7:51 PM, Tom Lane wrote: > Ashutosh Sharma writes: >> Anyways, attached is the patch that corrects this issue. The patch now >> imports all the switches used by perl into plperl module but, after >> doing so, i am seeing some

Re: [HACKERS] pl/perl extension fails on Windows

Ashutosh Sharma writes: > Anyways, attached is the patch that corrects this issue. The patch now > imports all the switches used by perl into plperl module but, after > doing so, i am seeing some compilation errors on Windows. Following is > the error observed, > SPI.obj :

Re: [HACKERS] Missing comment for max_logical_replication_workers in postgresql.conf.sample

On Thu, 27 Jul 2017 14:38:29 +0900 Masahiko Sawada wrote: > On Thu, Jul 27, 2017 at 10:14 AM, Yugo Nagata wrote: > > Hi, > > > > I found that postgresql.conf.sample is missing a comment > > to note that changing max_logical_replication_workers

Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standby server

Noah, all, * Noah Misch (n...@leadboat.com) wrote: > This PostgreSQL 10 open item is past due for your status update. Kindly send > a status update within 24 hours, and include a date for your subsequent status > update. Refer to the policy on open item ownership: Based on the ongoing

Re: [HACKERS] expand_dbname in postgres_fdw

Arseny Sher writes: > Attached patch allows dbname expansion and makes sure that it doesn't > contain any invalid options. I'm pretty much against this in principle. It complicates both the code and the conceptual API, for no serious gain, even if you take it on faith

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Wed, Jul 26, 2017 at 6:26 PM, Robert Haas wrote: > On Tue, Apr 18, 2017 at 4:25 AM, Pavan Deolasee > wrote: > > I'll include the fix in the next set of patches. > > I haven't see a new set of patches. Are you intending to continue > working

Re: [HACKERS] Increase Vacuum ring buffer.

On Thu, Jul 27, 2017 at 2:10 PM, Alvaro Herrera wrote: > Claudio Freire wrote: >> On Thu, Jul 27, 2017 at 1:46 PM, Alvaro Herrera >> wrote: >> > Claudio Freire wrote: >> > >> >> > The vacuuming the very large table with no index could also take

Re: [HACKERS] More race conditions in logical replication

Alvaro Herrera wrote: > Alvaro Herrera wrote: > > > Hmm, yeah, that's not good. However, I didn't like the idea of putting > > it inside the locked area, as it's too much code. Instead I added just > > before acquiring the spinlock. We cancel the sleep unconditionally > > later on if we didn't

Re: [HACKERS] Increase Vacuum ring buffer.

Claudio Freire wrote: > On Thu, Jul 27, 2017 at 1:46 PM, Alvaro Herrera > wrote: > > Claudio Freire wrote: > > > >> > The vacuuming the very large table with no index could also take a > >> > long time, and it scans and vacuums blocks one by one. So I imagined > >> >

Re: [HACKERS] psql's \d and \dt are sending their complaints to different output files

Daniel Gustafsson writes: >> On 19 Jun 2017, at 17:32, Tom Lane wrote: >> So, if we're getting into enforcing consistency in describe.c, there's >> lots to do. > Addressed in attached patch, see list of patches below. I've pushed most of this. There are a

Re: [HACKERS] tab completion for "create user mapping for"

Jeff Janes writes: > If you have "CREATE USE" tab completion will recommend both USER and USER > MAPPING FOR. > But once you have the full "CREATE USER " or "CREATE USER M" it will not > complete the rest of the "MAPPING FOR". > Attached patch fixes that. Pushed, thanks.

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

On 2017-07-27 02:31, Mark Rofail wrote: I have written some benchmark test. It would help (me at least) if you could be more explicit about what exactly each instance is. Apparently there is an 'original patch': is this the original patch by Marco Nenciarini? Or is it something you

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

On Thu, Jul 27, 2017 at 3:07 PM, Mark Rofail wrote: > On Thu, Jul 27, 2017 at 12:54 PM, Alexander Korotkov > wrote: >> >> How many rows of FK table were referencing the PK table row you're >> updating/deleting. >> I wonder how may RI trigger work

Re: [HACKERS] Increase Vacuum ring buffer.

Claudio Freire wrote: > > The vacuuming the very large table with no index could also take a > > long time, and it scans and vacuums blocks one by one. So I imagined > > that we can vacuum the FSM once vacuumed a certain amount of blocks. > > And that can avoid bloating table during the long-time

Re: [HACKERS] Increase Vacuum ring buffer.

On Thu, Jul 27, 2017 at 6:16 AM, Masahiko Sawada wrote: > On Thu, Jul 27, 2017 at 5:48 PM, Sokolov Yura > wrote: >> On 2017-07-27 11:30, Masahiko Sawada wrote: >>> >>> On Tue, Jul 25, 2017 at 2:27 AM, Claudio Freire >>>

Re: [HACKERS] Increase Vacuum ring buffer.

On Thu, Jul 27, 2017 at 1:46 PM, Alvaro Herrera wrote: > Claudio Freire wrote: > >> > The vacuuming the very large table with no index could also take a >> > long time, and it scans and vacuums blocks one by one. So I imagined >> > that we can vacuum the FSM once

Re: [HACKERS] pl/perl extension fails on Windows

Andrew Dunstan writes: > On 07/27/2017 04:33 PM, Tom Lane wrote: >> So I was trying to figure a way to not include XSUB.h except in a very >> limited part of plperl, like ideally just the .xs files. It's looking >> like that would take nontrivial refactoring

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

Pavan Deolasee wrote: > I'll be happy if someone wants to continue hacking the patch further and > get it in a committable shape. I can stay actively involved. But TBH the > amount of time I can invest is far as compared to what I could during the > last cycle. That's

[HACKERS] Notice message of ALTER SUBSCRIPTION ... RERESH PUBLICATIION

Hi, When we run ALTER SUBSCRIPTION ... REFRESH PUBLICATION and there is an unkown table at local, it says; NOTICE: added subscription for table public.tbl I feel this a bit misleading because it says a subscription is added but actually new subscription object is not created. Of cause, I can

[HACKERS] A suspicious code in pgoutput_startup().

Hi, I found a suspicious code in pgoutput_startup(). 175 /* Check if we support requested protocol */ 176 if (data->protocol_version != LOGICALREP_PROTO_VERSION_NUM) 177 ereport(ERROR, 178 (errcode(ERRCODE_FEATURE_NOT_SUPPORTED), 179

Re: LP_DEAD hinting and not holding on to a buffer pin on leaf page (Was: [HACKERS] [WIP] Zipfian distribution in pgbench)

On Tue, Jul 25, 2017 at 11:02 PM, Peter Geoghegan wrote: > While the benchmark Alik came up with is non-trivial to reproduce, I > can show a consistent regression for a simple case with only one > active backend. That's not good. > We now see that no update ever kills items within

Re: [HACKERS] pl/perl extension fails on Windows

Andrew Dunstan writes: > What is the minimal set of extra defines required to sort out the > handshake fingerprint issue? Also, exactly what defines do you end up importing in your test build? regards, tom lane -- Sent via pgsql-hackers

Re: [HACKERS] postgres_fdw super user checks

On Thu, Dec 1, 2016 at 7:11 PM, Haribabu Kommi wrote: > On Tue, Oct 18, 2016 at 10:38 AM, Michael Paquier < > michael.paqu...@gmail.com> wrote: > >> On Mon, Oct 17, 2016 at 10:51 PM, Robert Haas >> wrote: >> > On Mon, Oct 17, 2016 at 2:18 AM,

Re: [HACKERS] Change in "policy" on dump ordering?

Robert Haas writes: > On Wed, Jul 26, 2017 at 2:41 PM, Tom Lane wrote: >> The bigger issue is whether there's some failure case this would cause >> that I'm missing altogether. Thoughts? > I think dependencies are fundamentally the right model for

Re: [HACKERS] A couple of postgresql.conf.sample discrepancies

On Thu, Jul 27, 2017 at 4:27 AM, Aleksander Alekseev wrote: > I like the idea. However maybe it worth considering to turn it into a > TAP test? Otherwise there is a good chance everybody will forget to run > it. For similar reason I would advise to add this patch to the

Re: [HACKERS] pl/perl extension fails on Windows

On 07/27/2017 12:34 PM, Ashutosh Sharma wrote: > On Thu, Jul 27, 2017 at 7:51 PM, Tom Lane > wrote: > > Ashutosh Sharma > writes: > >> Anyways, attached is the patch that corrects this issue.

Re: [HACKERS] Change in "policy" on dump ordering?

On Wed, Jul 26, 2017 at 2:41 PM, Tom Lane wrote: > The bigger issue is whether there's some failure case this would cause > that I'm missing altogether. Thoughts? I think dependencies are fundamentally the right model for this sort of problem. I can't imagine what could go

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

On Thu, Jul 27, 2017 at 7:15 PM, Erik Rijkers wrote: > It would help (me at least) if you could be more explicit about what > exactly each instance is. > I apologize, I thought it was clear through the context. I meant by the original patch is all the work done before my GSoC

Re: [HACKERS] expand_dbname in postgres_fdw

Tom Lane writes: > I really don't see anything wrong with the FDW's documentation. To claim > that it's not clear, you have to suppose that a connstring's dbname field > is allowed to recursively contain a connstring. However, if you've got a > concrete suggestion about

Re: [HACKERS] pl/perl extension fails on Windows

On Thu, Jul 27, 2017 at 10:21 AM, Tom Lane wrote: > Ashutosh Sharma writes: >> Anyways, attached is the patch that corrects this issue. The patch now >> imports all the switches used by perl into plperl module but, after >> doing so, i am seeing some

Re: [HACKERS] pl/perl extension fails on Windows

Robert Haas writes: > How about we fix it like this? That seems pretty invasive; I'm not excited about breaking a lot of unrelated code (particularly third-party extensions) for plperl's benefit. Even if we wanted to do that in HEAD, it seems like a nonstarter for released

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

On Thu, Jul 27, 2017 at 7:30 PM, Alexander Korotkov wrote: > Oh, ok. I missed that. >> > Could you remind me why don't we have DELETE CASCADE? I understand that > UPDATE CASCADE is problematic because it's unclear which way should we > delete elements from array. But

Re: [HACKERS] GSoC 2017: weekly progress reports (week 8)

Hi. I am attaching a patch for predicate locking in SP-Gist index Regards, Shubham Sent with Mailtrack On 26 July 2017 at 20:50, Shubham Barai wrote: > Project:

Re: [HACKERS] map_partition_varattnos() and whole-row vars

On 2017/07/26 16:58, Amit Langote wrote: > Rajkumar Raghuwanshi reported [1] on the "UPDATE partition key" thread > that whole-row vars don't play nicely with partitioned table operations. > > For example, when used to convert WITH CHECK OPTION constraint expressions > and RETURNING target list

Re: [HACKERS] segfault in HEAD when too many nested functions call

On Thu, Jul 27, 2017 at 09:49:18PM -0700, Andres Freund wrote: > On 2017-07-27 21:46:57 -0700, Noah Misch wrote: > > On Thu, Jul 27, 2017 at 02:29:32AM +, Noah Misch wrote: > > > On Mon, Jul 24, 2017 at 08:04:30AM +0100, Andres Freund wrote: > > > > > > > > > > > > On July 24, 2017 7:10:19

Re: [HACKERS] segfault in HEAD when too many nested functions call

On Thu, Jul 27, 2017 at 02:29:32AM +, Noah Misch wrote: > On Mon, Jul 24, 2017 at 08:04:30AM +0100, Andres Freund wrote: > > > > > > On July 24, 2017 7:10:19 AM GMT+01:00, Noah Misch wrote: > > >On Tue, Jul 18, 2017 at 01:04:10PM -0700, Andres Freund wrote: > > >> Ok,

Re: [HACKERS] segfault in HEAD when too many nested functions call

On 2017-07-27 22:04:59 -0700, Noah Misch wrote: > On Thu, Jul 27, 2017 at 09:49:18PM -0700, Andres Freund wrote: > > On 2017-07-27 21:46:57 -0700, Noah Misch wrote: > > > On Thu, Jul 27, 2017 at 02:29:32AM +, Noah Misch wrote: > > > > On Mon, Jul 24, 2017 at 08:04:30AM +0100, Andres Freund

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Thu, Jul 27, 2017 at 8:02 PM, Robert Haas wrote: > On Thu, Jul 27, 2017 at 5:08 AM, Stas Kelvich > wrote: >> As far as I understand any solution that provides proper isolation for >> distributed >> transactions in postgres will require

Re: [HACKERS] segfault in HEAD when too many nested functions call

On 2017-07-27 21:46:57 -0700, Noah Misch wrote: > On Thu, Jul 27, 2017 at 02:29:32AM +, Noah Misch wrote: > > On Mon, Jul 24, 2017 at 08:04:30AM +0100, Andres Freund wrote: > > > > > > > > > On July 24, 2017 7:10:19 AM GMT+01:00, Noah Misch > > > wrote: > > > >On Tue,

Re: [HACKERS] map_partition_varattnos() and whole-row vars

On Wed, Jul 26, 2017 at 04:58:08PM +0900, Amit Langote wrote: > Rajkumar Raghuwanshi reported [1] on the "UPDATE partition key" thread > that whole-row vars don't play nicely with partitioned table operations. > > For example, when used to convert WITH CHECK OPTION constraint expressions > and

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Thu, Apr 06, 2017 at 08:55:37AM +0200, Petr Jelinek wrote: > On 06/04/17 03:51, Noah Misch wrote: > > On Thu, Apr 06, 2017 at 12:48:56AM +0900, Fujii Masao wrote: > >> On Wed, Apr 5, 2017 at 3:45 PM, Noah Misch wrote: > >>> On Mon, Dec 19, 2016 at 09:49:58PM +0900, Fujii

[HACKERS] Re: [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

On Fri, May 19, 2017 at 11:08:41AM +0900, Michael Paquier wrote: > On Fri, May 19, 2017 at 11:01 AM, Tsunakawa, Takayuki > wrote: > > From: pgsql-hackers-ow...@postgresql.org > >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Eisentraut > >> The

Re: [HACKERS] On Complex Source Code Reading Strategy

Peter Geoghegan writes: > 2. Start somewhere. I have no idea where that should be, but it has to > be some particular place that seems interesting to you. Don't forget to start with the available documentation, ie https://www.postgresql.org/docs/devel/static/internals.html You

Re: [HACKERS] On Complex Source Code Reading Strategy

On 07/27/2017 04:45 PM, Tom Lane wrote: Peter Geoghegan writes: 2. Start somewhere. I have no idea where that should be, but it has to be some particular place that seems interesting to you. Don't forget to start with the available documentation, ie

Re: LP_DEAD hinting and not holding on to a buffer pin on leaf page (Was: [HACKERS] [WIP] Zipfian distribution in pgbench)

Robert Haas wrote: We now see that no update ever kills items within _bt_killitems(), because our own update to the index leaf page itself nullifies our ability to kill anything, by changing the page LSN from the one stashed in the index scan state variable. Fortunately,

[HACKERS] PL_stashcache, or, what's our minimum Perl version?

I wanted to do some portability testing on the recently-proposed plperl changes, so I tried to build against a 5.8.0 Perl that I had laying about. It blew up real good: plperl.c: In function `plperl_trusted_init': plperl.c:1017: `PL_stashcache' undeclared (first use in this function)

Re: LP_DEAD hinting and not holding on to a buffer pin on leaf page (Was: [HACKERS] [WIP] Zipfian distribution in pgbench)

Peter Geoghegan wrote: In Alik's workload, there are two queries: One UPDATE, one SELECT. Even though the bloated index was a unique index, and so still gets _bt_check_unique() item killing, the regression is still going to block LP_DEAD cleanup by the SELECTs, which seems like

Re: [HACKERS] Incorrect comment of XLByteToSeg() and XLByteToPrevSeg()

> I found a type in the comment for XLByteToSeg() and XLByteToPrevSeg(). > This says "Compute ID and segment from an XLogRecPtr", but these > macros compute only segment numbers. I think "Compute a segment number > from an XLogRecPtr" is correct. > > The definition of these macros were modified

Re: [HACKERS] On Complex Source Code Reading Strategy

On 28 July 2017 at 07:45, Tom Lane wrote: > Peter Geoghegan writes: > > 2. Start somewhere. I have no idea where that should be, but it has to > > be some particular place that seems interesting to you. > > Don't forget to start with the available

Re: [HACKERS] pl/perl extension fails on Windows

On 07/27/2017 04:33 PM, Tom Lane wrote: > Robert Haas writes: >> How about we fix it like this? > That seems pretty invasive; I'm not excited about breaking a lot of > unrelated code (particularly third-party extensions) for plperl's benefit. > Even if we wanted to do

Re: [HACKERS] segfault in HEAD when too many nested functions call

On 2017-07-26 16:28:38 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-07-26 15:03:37 -0400, Tom Lane wrote: > >> Hm, that seems kinda backwards to me; I was envisioning the checks > >> moving to the callees not the callers. I think it'd end up being > >> about the

Re: [HACKERS] On Complex Source Code Reading Strategy

On Tue, Jul 25, 2017 at 11:54 PM, Zeray Kalayu wrote: > I want to be PG hacker but it seems a complex beast to find my way out in it. > So, can anyone suggest me from his experience/style the general > approaches/techniques/strategies on how to read complex source code in >

Re: [HACKERS] PL_stashcache, or, what's our minimum Perl version?

I wrote: > So the question is, does anyone care? I wouldn't except that our > documentation appears to claim that we work with Perl "5.8 or later". BTW, what actually says that is installation.sgml: Perl 5.8 or later is needed to build from a Git checkout, or if you changed the

Re: [HACKERS] Refreshing subscription relation state inside a transaction block

On Thu, Jul 27, 2017 at 9:31 AM, Masahiko Sawada wrote: > On Wed, Jul 26, 2017 at 10:29 PM, Robert Haas wrote: >> On Mon, Jun 19, 2017 at 4:30 AM, Masahiko Sawada >> wrote: I think that either of the options you

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Fri, Jul 28, 2017 at 5:57 AM, Peter Geoghegan wrote: > Pavan Deolasee wrote: > > I'll be happy if someone wants to continue hacking the patch further and > > get it in a committable shape. I can stay actively involved. But TBH the > > amount of time I