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

On Thu, Jul 2, 2015 at 3:29 PM, Amit Langote wrote: > On 2015-07-02 PM 03:12, Fujii Masao wrote: >> >> So I'm thinking that we basically need to check the progress on each >> standby to choose new master. >> > > Does HA software determine a standby to promote based on replication progress > or wou

Re: [HACKERS] WAL-related tools and .paritial WAL file

On Thu, Jul 2, 2015 at 2:06 PM, Fujii Masao wrote: > I implemented the patch accordingly. Patch attached. Cool, thanks. I have done some tests with pg_archivecleanup, and it works as expected, aka if I define a backup file, the backup file as well as the segments equal or newer than it remain. It

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

Amit wrote: > Does HA software determine a standby to promote based on replication > progress > or would things be reliable enough for it to infer one from the quorum > setting > specified in GUC (or wherever)? Is part of the job of this patch to make > the > latter possible? Just wondering or

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

On 2015-07-02 PM 03:12, Fujii Masao wrote: > > So I'm thinking that we basically need to check the progress on each > standby to choose new master. > Does HA software determine a standby to promote based on replication progress or would things be reliable enough for it to infer one from the quor

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

On Thu, Jul 2, 2015 at 3:21 AM, Josh Berkus wrote: > All: > > Replying to multiple people below. > > On 07/01/2015 07:15 AM, Fujii Masao wrote: >> On Tue, Jun 30, 2015 at 2:40 AM, Josh Berkus wrote: >>> You're confusing two separate things. The primary manageability problem >>> has nothing to do

Re: [HACKERS] Asynchronous execution on FDW

Ouch! I mistakenly made two CF entries for this patch. Could someone remove this entry for me? https://commitfest.postgresql.org/5/290/ The correct entry is "/5/291/" == Hello. This is the new version of FDW async exection feature. The status of this feature is as follows, as of the last co

[HACKERS] Asynchronous execution on FDW

Hello. This is the new version of FDW async exection feature. The status of this feature is as follows, as of the last commitfest. - Async execution is valuable to have. - But do the first kick in ExecInit phase is wrong. So the design outline of this version is as following, - The patch set co

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

Le 2 juil. 2015 7:28 AM, "Simon Riggs" a écrit : > > On 2 July 2015 at 03:00, Rahila Syed wrote: > >> >> >Yes, I suggest just a single column on pg_stat_activity called pct_complete >> >> Reporting remaining time also can be crucial to make decisions regarding continuing or aborting VACUUM. >> Th

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

On Wed, Jul 1, 2015 at 11:58 PM, Sawada Masahiko wrote: > On Tue, Jun 30, 2015 at 2:40 AM, Josh Berkus wrote: >> >> BTW, ALTER SYSTEM is a strong reason to use JSON for the synch rep GUC >> (assuming it's one parameter) instead of some custom syntax. If it's >> JSON, we can validate it in psql, wh

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

On 2 July 2015 at 03:00, Rahila Syed wrote: > >Yes, I suggest just a single column on pg_stat_activity called > pct_complete > > Reporting remaining time also can be crucial to make decisions regarding > continuing or aborting VACUUM. > The same has been suggested in the thread below, > > http

Re: ctidscan as an example of custom-scan (Re: [HACKERS] [v9.5] Custom Plan API)

Folks, > Moved this patch to next CF 2015-02 because of lack of review(ers). > Do we still need this patch as contrib module? It was originally required it as example of custom-scan interface last summer, however, here was no strong requirement after that, then, it was bumped to v9.6 development c

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

Hello, >Thank you for suggestion. The design with hooks and a separate view was mainly to keep most of the >code outside core as the feature proposed is specific to VACUUM command. Also, having a separate view >can give more flexibility in terms of displaying various progress parameters. >FWIW ,the

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On Sat, Jun 27, 2015 at 12:54 AM, Robert Haas wrote: > > On Mon, Jun 15, 2015 at 2:52 PM, Amit Kapila wrote: > > Attached patch provides a fix as per above discussion. > > I think we should emit some LOG messages here. When we detect the > file is there: > > LOG: ignoring tablespace_map file bec

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

On Wed, Jul 1, 2015 at 11:45 PM, Peter Eisentraut wrote: > On 6/26/15 1:46 AM, Michael Paquier wrote: >> - k(elt1,elt2,eltN) means that we need for the k elements in the set >> to return true (aka commit confirmation). >> - k[elt1,elt2,eltN] means that we need for the first k elements in the >> se

Re: [HACKERS] WAL-related tools and .paritial WAL file

On Wed, Jul 1, 2015 at 5:14 PM, Simon Riggs wrote: > On 1 July 2015 at 07:52, Michael Paquier wrote: >> >> On Wed, Jul 1, 2015 at 12:39 PM, Fujii Masao >> wrote: >> > WAL-related tools, i.e., pg_archivecleanup, pg_resetxlog and >> > pg_xlogdump don't seem to properly handle .paritial WAL file. >

Re: [HACKERS] pg_file_settings view vs. Windows

On Sat, Jun 27, 2015 at 07:20:43PM -0400, Tom Lane wrote: > Tatsuo Ishii writes: > >> I noticed that in EXEC_BACKEND builds (ie, Windows) the pg_file_settings > >> view doesn't act as its author presumably intended. Specifically, it > >> reads as empty until/unless the current session processes a

[HACKERS] Re: Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)

On Sat, Jun 27, 2015 at 06:13:36PM +0200, Andres Freund wrote: > On 2015-06-27 12:10:49 -0400, Tom Lane wrote: > > Andres Freund writes: > > > On 2015-06-27 15:07:05 +0900, Michael Paquier wrote: > > >> +1 for removing on master and just disabling on back-branches. > > > > > The problem with that

Re: [HACKERS] assessing parallel-safety

On Thu, May 21, 2015 at 10:19 PM, Robert Haas wrote: > > On Sat, Mar 21, 2015 at 2:30 PM, Thom Brown wrote: > > Looks like one of the patches I applied is newer than the one in your list: > > > > HEAD Commit-id: 13a10c0ccd984643ef88997ac177da7c4b7e46a6 > > parallel-mode-v9.patch > > assess-parall

Re: [HACKERS] error message diff with Perl 5.22.0

On Thu, Jul 2, 2015 at 11:56 AM, Tom Lane wrote: > Alex Hunsaker writes: >> (What about the back branches? :D) > > Indeed. dangomushi is complaining about this in the back branches now. Yep, perl 5.22 is used there. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql

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

On 2015-07-02 AM 11:41, Rahila Syed wrote: > Hello, > >> I though about the possibilities of progress visualization - and one > possibility is one or two special column in pg_stat_activity table - this > info can be interesting for VACUUM >started by autovacuum too. > > Thank you for suggestion.

Re: [HACKERS] error message diff with Perl 5.22.0

Alex Hunsaker writes: > (What about the back branches? :D) Indeed. dangomushi is complaining about this in the back branches now. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.p

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

Hello, >I though about the possibilities of progress visualization - and one possibility is one or two special column in pg_stat_activity table - this info can be interesting for VACUUM >started by autovacuum too. Thank you for suggestion. The design with hooks and a separate view was mainly to k

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

Hello, Thank you for suggestions. >Yes, I suggest just a single column on pg_stat_activity called pct_complete Reporting remaining time also can be crucial to make decisions regarding continuing or aborting VACUUM. The same has been suggested in the thread below, http://www.postgresql.org/mes

Re: [HACKERS] Expending the use of xlog_internal.h's macros

On Thu, Jul 2, 2015 at 10:37 AM, Fujii Masao wrote: > On Wed, Jul 1, 2015 at 9:53 PM, Fujii Masao wrote: > > +/* Length of XLog file name */ > +#define XLOG_DATA_FNAME_LEN 24 > > Shorten the name of this macro variable, to XLOG_FNAME_LEN, > for more code readability. >>>

Re: [HACKERS] Expending the use of xlog_internal.h's macros

On Wed, Jul 1, 2015 at 9:53 PM, Fujii Masao wrote: > On Wed, Jul 1, 2015 at 8:58 PM, Michael Paquier > wrote: >> On Wed, Jul 1, 2015 at 8:18 PM, Fujii Masao wrote: >>> On Wed, Jul 1, 2015 at 8:16 PM, Fujii Masao wrote: I updated the patch as follows. Patch attached. +#define XLogFi

Re: [HACKERS] error message diff with Perl 5.22.0

On Sat, Jun 6, 2015 at 7:03 PM, Peter Eisentraut wrote: > With the recently released Perl 5.22.0, the tests fail thus: > > -ERROR: Global symbol "$global" requires explicit package name at line 3. > -Global symbol "$other_global" requires explicit package name at line 4. > +ERROR: Global symbol

Re: [HACKERS] drop/truncate table sucks for large values of shared buffers

On Wed, Jul 1, 2015 at 8:26 PM, Simon Riggs wrote: > > On 1 July 2015 at 15:39, Amit Kapila wrote: > >> >> Okay. I think we can maintain the list in similar way as we do for >> UNLINK_RELATION_REQUEST in RememberFsyncRequest(), but >> why to wait till 64 tables? > > > I meant once per checkpoint

Re: [HACKERS] More logging for autovacuum

On Fri, Aug 17, 2007 at 3:14 PM, Alvaro Herrera wrote: > Gregory Stark wrote: > > > > I'm having trouble following what's going on with autovacuum and I'm > finding > > the existing logging insufficient. In particular that it's only logging > vacuum > > runs *after* the vacuum finishes makes it h

Re: [HACKERS] Raising our compiler requirements for 9.6

On 2015-07-01 19:05:08 -0400, Tom Lane wrote: > Andres Freund writes: > > Since, buildfarm/quiet inline test issues aside, pademelon is the only > > animal not supporting inlines and varargs, I think we should just go > > ahead and start to use both. > > I'm good with using inlines, since as I po

Re: [HACKERS] Raising our compiler requirements for 9.6

Andres Freund writes: > Since, buildfarm/quiet inline test issues aside, pademelon is the only > animal not supporting inlines and varargs, I think we should just go > ahead and start to use both. I'm good with using inlines, since as I pointed out upthread, that won't actually break anything. I

Re: [HACKERS] Raising our compiler requirements for 9.6

On 2015-07-02 00:15:14 +0200, Andres Freund wrote: > animal OS compiler inline quiet inline > varargs > brolga cygwin gcc-4.3 yy 4.3 obviously supports varargs. Human error. > pademelonHP-UX 10.2 HP C Comp

Re: [HACKERS] Raising our compiler requirements for 9.6

On 2015-07-01 23:39:06 +0200, Andres Freund wrote: > On 2015-07-01 16:33:24 -0400, Tom Lane wrote: > > Andres Freund writes: > > > At the very least I think we should start to rely on 'static inline's > > > working. There is not, and hasn't been for a while, any buildfarm animal > > > that does no

Re: [HACKERS] Raising our compiler requirements for 9.6

On 2015-07-01 16:33:24 -0400, Tom Lane wrote: > Andres Freund writes: > > At the very least I think we should start to rely on 'static inline's > > working. There is not, and hasn't been for a while, any buildfarm animal > > that does not support it > > pademelon doesn't. Oh. I'd gone through al

Re: [HACKERS] Raising our compiler requirements for 9.6

"Joshua D. Drake" writes: > On 07/01/2015 01:33 PM, Tom Lane wrote: >> Andres Freund writes: >>> At the very least I think we should start to rely on 'static inline's >>> working. There is not, and hasn't been for a while, any buildfarm animal >>> that does not support it >> pademelon doesn't.

Re: [HACKERS] 9.6 commitfest schedule

On Wed, Jul 1, 2015 at 3:19 PM, Alvaro Herrera wrote: > Also, I'm pleased to announce that Heikki Linnakangas has agreed to be > our beloved commitfest manager for CF1; he will be starting on it > sometime in the next couple dozen hours or so. Beware, as by now he has > gotten extremely good at s

Re: [HACKERS] Raising our compiler requirements for 9.6

01.07.2015, 23:33, Tom Lane kirjoitti: > Andres Freund writes: >> At the very least I think we should start to rely on 'static inline's >> working. There is not, and hasn't been for a while, any buildfarm animal >> that does not support it > > pademelon doesn't. HP-UX 10.20 was released in 1996,

Re: [HACKERS] Raising our compiler requirements for 9.6

On 07/01/2015 01:33 PM, Tom Lane wrote: Andres Freund writes: At the very least I think we should start to rely on 'static inline's working. There is not, and hasn't been for a while, any buildfarm animal that does not support it pademelon doesn't. Other reasoning aside, pademelon is runni

Re: [HACKERS] Raising our compiler requirements for 9.6

Peter Geoghegan writes: > On Wed, Jul 1, 2015 at 9:14 AM, Andres Freund wrote: >> The list of features, in the order of perceived importance, that might >> be worthwhile thinking about are: >> * static inline >> * variadic macros >> * designated initializers (e.g. somestruct foo = { .bar = 3 } )

Re: [HACKERS] Raising our compiler requirements for 9.6

Andres Freund writes: > At the very least I think we should start to rely on 'static inline's > working. There is not, and hasn't been for a while, any buildfarm animal > that does not support it pademelon doesn't. Also, I think there are some other non-gcc animals that nominally allow "static i

Re: [HACKERS] NULL passed as an argument to memcmp() in parse_func.c

Andres Freund writes: > On 2015-07-01 10:51:49 -0400, Tom Lane wrote: >> The problem is that there are multiple risks to manage here. If I were to >> back-patch that patch, it would actively break any third-party extensions >> that might be using the formerly-considered-valid technique of passing

Re: [HACKERS] Parallel Seq Scan

On 01/07/15 17:37, Amit Kapila wrote: On Tue, Jun 30, 2015 at 4:00 AM, Jeff Davis > wrote: > > [Jumping in without catching up on entire thread. [...] . > 2. Where is the speedup coming from? How much of it is CPU and IO > overlapping (i.e. not leaving disk or CPU id

[HACKERS] 9.6 commitfest schedule

Fellow hackers, As discussed at PGCon's developer meeting, this is the schedule for the upcoming commitfests: CF1: July 1 to July 31 2015 CF2: September 1 to September 30 2015 CF3: November 1 to November 30 2015 CF4: Januart 2 to January 31 2016 CF5: March 1 to March 31 2016 Feature Freeze: April

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

All: Replying to multiple people below. On 07/01/2015 07:15 AM, Fujii Masao wrote: > On Tue, Jun 30, 2015 at 2:40 AM, Josh Berkus wrote: >> You're confusing two separate things. The primary manageability problem >> has nothing to do with altering the parameter. The main problem is: if >> there

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Wed, Jul 1, 2015 at 10:45 AM, Peter Geoghegan wrote: > On Tue, Jun 30, 2015 at 11:19 AM, Heikki Linnakangas wrote: >> I agree it would be cleaner to have a separate CHECK_UNIQUE_XXX code for >> speculative insertions. You've defined CHECK_UNIQUE_SPECULATIVE as "like >> CHECK_UNIQUE_PARTIAL, bu

Re: [HACKERS] Raising our compiler requirements for 9.6

On Wed, Jul 1, 2015 at 9:14 AM, Andres Freund wrote: > At the very least I think we should start to rely on 'static inline's > working. There is not, and hasn't been for a while, any buildfarm animal > that does not support it and we go through some ugly lengths to avoid > relying on inline functi

Re: [HACKERS] NULL passed as an argument to memcmp() in parse_func.c

On 2015-07-01 10:51:49 -0400, Tom Lane wrote: > The problem is that there are multiple risks to manage here. If I were to > back-patch that patch, it would actively break any third-party extensions > that might be using the formerly-considered-valid technique of passing a > NULL array pointer to t

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Wed, Jul 1, 2015 at 10:45 AM, Peter Geoghegan wrote: > You can construct a theoretical case where lock starvation occurs with > unique constraint enforcement. I think it helps with nbtree here that > someone will reliably *not* see a conflict when concurrently > inserting, because unique index

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Tue, Jun 30, 2015 at 11:19 AM, Heikki Linnakangas wrote: > I agree it would be cleaner to have a separate CHECK_UNIQUE_XXX code for > speculative insertions. You've defined CHECK_UNIQUE_SPECULATIVE as "like > CHECK_UNIQUE_PARTIAL, but you don't have to insert the index tuple if > there's a conf

[HACKERS] Raising our compiler requirements for 9.6

Hi, During the 9.5 cycle, and earlier, the topic of increasing our minimum bar for compilers came up a bunch of times. Specifically whether we still should continue to use C90 as a baseline. I think the time has come to rely at least on some newer features. At the very least I think we should st

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

On Thu, Jul 2, 2015 at 12:13 AM, Sawada Masahiko wrote: > On Thu, May 28, 2015 at 11:34 AM, Sawada Masahiko > wrote: >> On Thu, Apr 30, 2015 at 8:07 PM, Sawada Masahiko >> wrote: >>> On Fri, Apr 24, 2015 at 11:21 AM, Sawada Masahiko >>> wrote: On Fri, Apr 24, 2015 at 1:31 AM, Jim Nasby

Re: [HACKERS] Macro nesting hell

Tom Lane wrote: > Last night my ancient HP compiler spit up on HEAD: > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=pademelon&dt=2015-07-01%2001%3A30%3A18 > complaining thus: > cpp: "brin_pageops.c", line 626: error 4018: Macro param too large after > substitution - use -H option. > I wa

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

On 30 April 2015 at 12:07, Sawada Masahiko wrote: > This patch lack some point: documentation, comment in source code, > etc, so it's WIP patch yet, > but I think that it's enough to discuss about this. > Code comments exist to indicate the intention of sections of code. They are essential for

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

On Thu, May 28, 2015 at 11:34 AM, Sawada Masahiko wrote: > On Thu, Apr 30, 2015 at 8:07 PM, Sawada Masahiko > wrote: >> On Fri, Apr 24, 2015 at 11:21 AM, Sawada Masahiko >> wrote: >>> On Fri, Apr 24, 2015 at 1:31 AM, Jim Nasby wrote: On 4/23/15 11:06 AM, Petr Jelinek wrote: > > O

[HACKERS] Macro nesting hell

Last night my ancient HP compiler spit up on HEAD: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=pademelon&dt=2015-07-01%2001%3A30%3A18 complaining thus: cpp: "brin_pageops.c", line 626: error 4018: Macro param too large after substitution - use -H option. I was able to revive pademelon b

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

On Tue, Jun 30, 2015 at 2:40 AM, Josh Berkus wrote: > On 06/29/2015 01:01 AM, Michael Paquier wrote: > > You're confusing two separate things. The primary manageability problem > has nothing to do with altering the parameter. The main problem is: if > there is more than one synch candidate, how

Re: [HACKERS] drop/truncate table sucks for large values of shared buffers

On 1 July 2015 at 15:39, Amit Kapila wrote: > Okay. I think we can maintain the list in similar way as we do for > UNLINK_RELATION_REQUEST in RememberFsyncRequest(), but > why to wait till 64 tables? > I meant once per checkpoint cycle OR every N tables, whichever is sooner. N would need to var

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

On 6/26/15 1:12 PM, Josh Berkus wrote: > If we're going to do quorum, multi-set synchrep, then we need to have a > real management interface. Like, we really ought to have a system > catalog and some built in functions to manage this instead, e.g. > > pg_add_synch_set(set_name NAME, quorum INT, s

Re: [HACKERS] NULL passed as an argument to memcmp() in parse_func.c

Piotr Stefaniak writes: > On 06/27/2015 11:47 PM, Tom Lane wrote: >> Given the utter lack of any evidence that this actually causes any >> problems in the field, I don't feel a need to back-patch this change. > I'm under the impression that you don't care about not avoiding > undefined behavior

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

On 7/1/15 10:15 AM, Fujii Masao wrote: > One approach to address this problem is to introduce something like unlogged > system catalog. I'm not sure if that causes another big problem, though... Yeah, like the data disappearing after a crash. ;-) -- Sent via pgsql-hackers mailing list (pgsql-h

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

On 6/26/15 2:53 PM, Josh Berkus wrote: > I would also suggest that if I lose this battle and > we decide to go with a single stringy GUC, that we at least use JSON > instead of defining our out, proprietary, syntax? Does JSON have a natural syntax for a set without order? -- Sent via pgsql-hac

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

On 6/26/15 1:46 AM, Michael Paquier wrote: > - k(elt1,elt2,eltN) means that we need for the k elements in the set > to return true (aka commit confirmation). > - k[elt1,elt2,eltN] means that we need for the first k elements in the > set to return true. I think the difference between (...) and [...

Re: [HACKERS] drop/truncate table sucks for large values of shared buffers

On Tue, Jun 30, 2015 at 12:10 PM, Simon Riggs wrote: > > On 30 June 2015 at 07:34, Amit Kapila wrote: >> >> On Tue, Jun 30, 2015 at 11:00 AM, Simon Riggs wrote: >> > >> > On 30 June 2015 at 05:02, Amit Kapila wrote: >> >> >> >> On Mon, Jun 29, 2015 at 7:18 PM, Simon Riggs wrote: >> >> > >> >>

Re: [HACKERS] pg_basebackup and replication slots

On 7/1/15 8:37 AM, Michael Paquier wrote: > On Wed, Jul 1, 2015 at 10:33 AM, Peter Eisentraut wrote: >> (If you're looking at the patch and wondering why there is no code to >> actually do anything with the replication slot, that's because the code >> that does the WAL streaming is already aware of

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

On Tue, Jun 30, 2015 at 2:40 AM, Josh Berkus wrote: > On 06/29/2015 01:01 AM, Michael Paquier wrote: >> On Mon, Jun 29, 2015 at 4:20 AM, Josh Berkus wrote: > >>> Right. Well, another reason we should be using a system catalog and not >>> a single GUC ... The problem by using system catalog to c

Re: [HACKERS] Expending the use of xlog_internal.h's macros

On Wed, Jul 1, 2015 at 8:58 PM, Michael Paquier wrote: > On Wed, Jul 1, 2015 at 8:18 PM, Fujii Masao wrote: >> On Wed, Jul 1, 2015 at 8:16 PM, Fujii Masao wrote: >>> I updated the patch as follows. Patch attached. >>> >>> +#define XLogFileNameExtended(fname, tli, log, seg) >>> >>> Move this macro

Re: [HACKERS] pg_basebackup and replication slots

On Wed, Jul 1, 2015 at 10:33 AM, Peter Eisentraut wrote: > (If you're looking at the patch and wondering why there is no code to > actually do anything with the replication slot, that's because the code > that does the WAL streaming is already aware of replication slots > because of the pg_receivex

Re: [HACKERS] pg_rewind failure by file deletion in source server

On Wed, Jul 1, 2015 at 2:21 AM, Heikki Linnakangas wrote: > On 06/29/2015 09:44 AM, Michael Paquier wrote: >> >> On Mon, Jun 29, 2015 at 4:55 AM, Heikki Linnakangas wrote: >>> >>> But we'll still need to handle the pg_xlog symlink case somehow. Perhaps >>> it >>> would be enough to special-case pg

Re: [HACKERS] Unneeded NULL-pointer check in FreeSpaceMapTruncateRel

On Tue, Jun 30, 2015 at 9:57 PM, Andres Freund wrote: > On 2015-06-30 21:53:07 +0900, Michael Paquier wrote: >> In the category of nitpicky-code-style-issues, FreeSpaceMapTruncateRel >> is doing a NULL-pointer check for something that has been dereferenced >> on all the code paths leading to this

Re: [HACKERS] Expending the use of xlog_internal.h's macros

On Wed, Jul 1, 2015 at 8:18 PM, Fujii Masao wrote: > On Wed, Jul 1, 2015 at 8:16 PM, Fujii Masao wrote: >> I updated the patch as follows. Patch attached. >> >> +#define XLogFileNameExtended(fname, tli, log, seg) >> >> Move this macro to xlog_internal.h because it's used both in >> pg_standby and p

Re: [HACKERS] Expending the use of xlog_internal.h's macros

On Wed, Jul 1, 2015 at 8:16 PM, Fujii Masao wrote: > On Wed, Jun 10, 2015 at 2:41 PM, Michael Paquier > wrote: >> Hi all, >> >> While looking at the code of pg_archivecleanup.c, I noticed that there >> is some code present to detect if a given string has the format of a >> WAL segment file name o

Re: [HACKERS] Expending the use of xlog_internal.h's macros

On Wed, Jun 10, 2015 at 2:41 PM, Michael Paquier wrote: > Hi all, > > While looking at the code of pg_archivecleanup.c, I noticed that there > is some code present to detect if a given string has the format of a > WAL segment file name or of a backup file. > The recent commit 179cdd09 has introduc

Re: [HACKERS] Reducing ClogControlLock contention

On 2015-07-01 11:19:40 +0100, Simon Riggs wrote: > What "tricks" are being used?? > > Please explain why taking 2 locks is bad here, yet works fine elsewhere. I didn't say anything about 'bad'. It's more complicated than one lock. Suddenly you have to care about lock ordering and such. The algori

Re: [HACKERS] Reducing ClogControlLock contention

On 1 July 2015 at 11:14, Andres Freund wrote: > On 2015-07-01 09:08:11 +0100, Simon Riggs wrote: > > On 1 July 2015 at 09:00, Amit Kapila wrote: > > > > > On Tue, Jun 30, 2015 at 12:32 PM, Simon Riggs > > > a. the semantics of new LWLock (CommitLock) introduced > > > by patch seems to be diffe

Re: [HACKERS] Reducing ClogControlLock contention

On 1 July 2015 at 11:11, Amit Kapila wrote: > On Wed, Jul 1, 2015 at 1:38 PM, Simon Riggs wrote: > > > > On 1 July 2015 at 09:00, Amit Kapila wrote: > >> > >> > >> I think it will be better to partition it or use it in some other way > to avoid > >> two concurrent writers block at it, however i

Re: [HACKERS] Reducing ClogControlLock contention

On 2015-07-01 09:08:11 +0100, Simon Riggs wrote: > On 1 July 2015 at 09:00, Amit Kapila wrote: > > > On Tue, Jun 30, 2015 at 12:32 PM, Simon Riggs > > a. the semantics of new LWLock (CommitLock) introduced > > by patch seems to be different in the sense that it is just taken in > > Exclusive mo

Re: [HACKERS] Reducing ClogControlLock contention

On Wed, Jul 1, 2015 at 1:38 PM, Simon Riggs wrote: > > On 1 July 2015 at 09:00, Amit Kapila wrote: >> >> >> I think it will be better to partition it or use it in some other way to avoid >> two concurrent writers block at it, however if you want to first see the >> test results with this, then th

Re: [HACKERS] Parallel Seq Scan

On Wed, Jul 1, 2015 at 1:21 PM, Jeff Davis wrote: > > On Wed, 2015-07-01 at 11:07 +0530, Amit Kapila wrote: > > > For what you are asking to change name for? > > There are still some places, at least in the comments, that call it a > parallel sequential scan. > In the initial version of patch, th

Re: [HACKERS] Parallel Seq Scan

> > a. Infrastructure for parallel execution, like some of the stuff in > > execparallel.c, heapam.c,tqueue.c, etc and all other generic > > (non-nodes specific) code. > > Did you consider passing tuples through the tqueue by reference rather > than copying? The page should be pinned by the worker

[HACKERS] hola-importante

Espero que esto te llegue a tiempo, hice un viaje a Manchester, Inglaterra. Y se me fue robado el bolso con mi Pasaporte Internacional, Tarjetas de Crédito dentro. La Embajada está deseando ayudarme con dejarme tomar un vuelo sin mi Pasaporte, solo que tengo que pagar por el billete y cubrir las cu

Re: [HACKERS] WAL-related tools and .paritial WAL file

On 1 July 2015 at 07:52, Michael Paquier wrote: > On Wed, Jul 1, 2015 at 12:39 PM, Fujii Masao > wrote: > > WAL-related tools, i.e., pg_archivecleanup, pg_resetxlog and > > pg_xlogdump don't seem to properly handle .paritial WAL file. > > I think that we should fix at least pg_archivecleanup, ot

Re: [HACKERS] Reducing ClogControlLock contention

On 1 July 2015 at 09:00, Amit Kapila wrote: > On Tue, Jun 30, 2015 at 12:32 PM, Simon Riggs > wrote: > > > > ClogControlLock contention is high at commit time. This appears to be > due to the fact that ClogControlLock is acquired in Exclusive mode prior to > marking commit, which then gets starv

Re: [HACKERS] Reducing ClogControlLock contention

On Tue, Jun 30, 2015 at 12:32 PM, Simon Riggs wrote: > > ClogControlLock contention is high at commit time. This appears to be due to the fact that ClogControlLock is acquired in Exclusive mode prior to marking commit, which then gets starved by backends running TransactionIdGetStatus(). > > Propo

Re: [HACKERS] Parallel Seq Scan

On Wed, 2015-07-01 at 11:07 +0530, Amit Kapila wrote: > For what you are asking to change name for? There are still some places, at least in the comments, that call it a parallel sequential scan. > a. Infrastructure for parallel execution, like some of the stuff in > execparallel.c, heapam.c,tq

Re: [HACKERS] pg_rewind failure by file deletion in source server

On Wed, Jul 1, 2015 at 2:21 AM, Heikki Linnakangas wrote: > Hmm. I'm starting to think that pg_rewind should ignore pg_xlog entirely. In > any non-trivial scenarios, just copying all the files from pg_xlog isn't > enough anyway, and you need to set up a recovery.conf after running > pg_rewind that

Re: [HACKERS] Solaris testers wanted for strxfrm() behavior

On Tue, Jun 30, 2015 at 09:45:08AM -0400, Tom Lane wrote: > Noah Misch writes: > > On Sun, Jun 28, 2015 at 07:00:14PM -0400, Tom Lane wrote: > >> Another idea would be to make a test during postmaster start to see > >> if this bug exists, and fail if so. I'm generally on board with the > >> thoug

Re: [HACKERS] WAL-related tools and .paritial WAL file

On Wed, Jul 1, 2015 at 2:52 PM, Amit Kapila wrote: > On Wed, Jul 1, 2015 at 9:09 AM, Fujii Masao wrote: >> >> Also regarding pg_xlogdump, we can just document, for example, >> "please get rid of .paritial suffix from the WAL file name if >> you want to dump it by pg_xlogdump". >> > > Can't we ski