Re: [HACKERS] Parallel worker error

On Thu, Aug 31, 2017 at 03:11:10PM -0400, Robert Haas wrote: > On Wed, Aug 30, 2017 at 11:19 AM, Robert Haas wrote: > > But since that's an established design fl^H^Hprinciple, maybe that > > means we should go with the approach of teaching SerializeGUCState() > > to ignore role altogether and inst

Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump

On Sat, Sep 2, 2017 at 1:53 AM, Robert Haas wrote: > On Mon, Aug 21, 2017 at 5:30 PM, Simon Riggs wrote: >> Thinking ahead, are we going to add a new --no-objecttype switch every >> time someone wants it? > > I'd personally be fine with --no-whatever for any whatever that might > be a subsidiary

Re: [HACKERS] Function to move the position of a replication slot

On Sat, Sep 2, 2017 at 12:37 PM, Tom Lane wrote: > Peter Eisentraut writes: >> On 8/31/17 08:19, Magnus Hagander wrote: >>> I think that, in the end, covered all the comments? > >> I didn't see any explanation of what this would actually be useful for. >> I suppose you could skip over some change

Re: [HACKERS] configure issue - warnings sort: No such file or directory

2017-09-02 6:27 GMT+02:00 Pavel Stehule : > > > 2017-09-02 6:15 GMT+02:00 Tom Lane : > >> Pavel Stehule writes: >> > ./configure: line 15762: sort: No such file or directory >> > ./configure: line 15759: sed: No such file or directory >> >> /bin not in your PATH, perhaps? >> > > I have not, but s

Re: [HACKERS] configure issue - warnings sort: No such file or directory

2017-09-02 6:15 GMT+02:00 Tom Lane : > Pavel Stehule writes: > > ./configure: line 15762: sort: No such file or directory > > ./configure: line 15759: sed: No such file or directory > > /bin not in your PATH, perhaps? > I have not, but sed/sort I can use and export PATH="/bin:$PATH" doesn't h

Re: [HACKERS] configure issue - warnings sort: No such file or directory

Pavel Stehule writes: > ./configure: line 15762: sort: No such file or directory > ./configure: line 15759: sed: No such file or directory /bin not in your PATH, perhaps? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make ch

[HACKERS] configure issue - warnings sort: No such file or directory

configure: using compiler=gcc (GCC) 7.1.1 20170622 (Red Hat 7.1.1-3) configure: using CFLAGS=-Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -O2 configure

Re: [HACKERS] Restricting maximum keep segments by repslots

I'm still concerned about how the critical situation is handled. Your patch just prints a warning to the log and then goes on -- doing what? The warning rolls off the log, and then you have no idea what happened, or how to recover. I would like a flag in pg_replication_slots, and possibly also a

Re: [HACKERS] Secondary index access optimizations

On Wed, Aug 16, 2017 at 9:23 PM, Konstantin Knizhnik wrote: > postgres=# explain select * from bt where k between 1 and 2 and v = 100; > QUERY PLAN > -- > Append (cost=0.29..15.63 rows=2 width=8

Re: [HACKERS] Function to move the position of a replication slot

Peter Eisentraut writes: > On 8/31/17 08:19, Magnus Hagander wrote: >> I think that, in the end, covered all the comments? > I didn't see any explanation of what this would actually be useful for. > I suppose you could skip over some changes you don't want replicated, > but how do you find to wha

Re: [HACKERS] Function to move the position of a replication slot

On 8/31/17 08:19, Magnus Hagander wrote: > Rebased. Now named pg_advance_replication_slot. ERROR on logical slots. > Forward only. > > I think that, in the end, covered all the comments? I didn't see any explanation of what this would actually be useful for. I suppose you could skip over some ch

Re: [HACKERS] memory fields from getrusage()

On Sat, Sep 02, 2017 at 02:00:44PM +1200, Thomas Munro wrote: > On Sat, Sep 2, 2017 at 7:46 AM, Peter Eisentraut > wrote: > > On 6/15/17 10:58, Justin Pryzby wrote: > >> On Thu, Jun 15, 2017 at 10:29:21AM -0400, Robert Haas wrote: > >>> On Wed, Jun 14, 2017 at 6:28 PM, Justin Pryzby > >>> wrote:

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

On Fri, Sep 1, 2017 at 9:17 PM, Robert Haas wrote: > On Fri, Sep 1, 2017 at 10:03 AM, Dilip Kumar wrote: >>> Sure will do so. In the meantime, I have rebased the patch. >> >> I have repeated some of the tests we have performed earlier. > Thanks for repeating the performance tests. > OK, these

Re: [HACKERS] memory fields from getrusage()

On Sat, Sep 2, 2017 at 7:46 AM, Peter Eisentraut wrote: > On 6/15/17 10:58, Justin Pryzby wrote: >> On Thu, Jun 15, 2017 at 10:29:21AM -0400, Robert Haas wrote: >>> On Wed, Jun 14, 2017 at 6:28 PM, Justin Pryzby wrote: On Tue, Jun 13, 2017 at 12:16:00PM -0400, Robert Haas wrote: > It mig

Re: [HACKERS] Adding support for Default partition in partitioning

On Fri, Sep 1, 2017 at 3:19 PM, Robert Haas wrote: > On Thu, Aug 31, 2017 at 8:53 AM, Jeevan Ladhe > wrote: >> 0001: >> This patch refactors RelationBuildPartitionDesc(), basically this is patch >> 0001 of default range partition[1]. > > I spent a while studying this; it seems to be simpler and t

Re: [HACKERS] Parallel Hash take II

On Fri, Sep 1, 2017 at 7:42 PM, Thomas Munro wrote: >> I'm thinking about something like this: >> >> Gather >> -> Nested Loop >> -> Parallel Seq Scan >> -> Hash Join >> -> Seq Scan >> -> Parallel Hash >> -> Parallel Seq Scan >> >> The hash join has to be rescanned for every itera

Re: [HACKERS] Optional message to user when terminating/cancelling backend

On Fri, Jun 23, 2017 at 1:48 AM, Daniel Gustafsson wrote: > Good point. I’ve attached a new version which issues a NOTICE on truncation > and also addresses all other comments so far in this thread. Thanks a lot for > the early patch reviews! FYI this no longer builds because commit 81c5e46c490

Re: [HACKERS] Protect syscache from bloating with negative cache entries

On Mon, Aug 28, 2017 at 9:24 PM, Kyotaro HORIGUCHI wrote: > This patch have had interferences from several commits after the > last submission. I amended this patch to follow them (up to > f97c55c), removed an unnecessary branch and edited some comments. Hi Kyotaro-san, This applies but several

Re: [HACKERS] More replication race conditions

On Sat, Sep 2, 2017 at 12:03 AM, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Mon, Aug 28, 2017 at 8:25 AM, Michael Paquier >> wrote: >> > Today's run has finished with the same failure: >> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dangomushi&dt=2017-08-27%2018%3A00%3A13 >

Re: [HACKERS] Rename RECOVERYXLOG to RECOVERYWAL?

On Sat, Sep 2, 2017 at 3:06 AM, Robert Haas wrote: > I don't think this really buys us anything. If we'd applied it to v10 > maybe, but what do we get out of whacking it around now? > > "Consistency", I hear you cry! Fair point. But we never had a goal > of eliminating all internal references t

Re: [HACKERS] Upcoming commit fest will begin soon

On Sat, Sep 2, 2017 at 1:46 AM, Andres Freund wrote: > On 2017-09-01 16:14:25 +0200, Daniel Gustafsson wrote: >> > On 01 Sep 2017, at 05:33, Michael Paquier >> > wrote: >> > >> > Another question is: who would like to become the CF manager for this >> > time? This commit fest is very large, so i

Re: [HACKERS] Adding -E switch to pg_dumpall

On Sat, Sep 2, 2017 at 1:32 AM, Robert Haas wrote: > On Fri, Jul 21, 2017 at 9:21 AM, Michael Paquier > wrote: >> On Thu, Jul 20, 2017 at 11:17 AM, Fabien COELHO wrote: >>> Ok for me. I switched the status to "Ready for committers". >> >> Thanks for the review, Fabien. > > LGTM. Committed. Tha

Re: [HACKERS] Parallel Hash take II

On Sat, Sep 2, 2017 at 10:45 AM, Robert Haas wrote: > On Fri, Sep 1, 2017 at 6:32 PM, Thomas Munro > wrote: >> On Sat, Sep 2, 2017 at 5:13 AM, Robert Haas wrote: >>> On Thu, Aug 31, 2017 at 8:53 AM, Thomas Munro >>> wrote: Check out ExecReScanGather(): it shuts down and waits for all worke

Re: [HACKERS] Parallel Hash take II

On Fri, Sep 1, 2017 at 6:32 PM, Thomas Munro wrote: > On Sat, Sep 2, 2017 at 5:13 AM, Robert Haas wrote: >> On Thu, Aug 31, 2017 at 8:53 AM, Thomas Munro >> wrote: >>> Check out ExecReScanGather(): it shuts down and waits for all workers >>> to complete, which makes the assumptions in ExecReScan

Re: [HACKERS] Parallel Hash take II

On Sat, Sep 2, 2017 at 5:13 AM, Robert Haas wrote: > On Thu, Aug 31, 2017 at 8:53 AM, Thomas Munro > wrote: >> Check out ExecReScanGather(): it shuts down and waits for all workers >> to complete, which makes the assumptions in ExecReScanHashJoin() true. >> If a node below Gather but above Hash J

Re: [HACKERS] pg_basebackup throttling doesn't throttle as promised

On Fri, Sep 1, 2017 at 1:32 PM, Jeff Janes wrote: > The "-r" option to pg_basebackup is supposed to throttle the rate of the > backup. But it only works properly if the server is mostly idle. > > Every non-trivial call to XLogFlush or XLogBackgroundFlush will wake up > the wal sender (the one wh

Re: [HACKERS] tupconvert.c API change in v10 release notes

On Wed, Jul 19, 2017 at 12:39:07PM -0400, Tom Lane wrote: > Justin Pryzby writes: > > FYI, I happened across this commit comment: > > 3f902354b08ac788600f0ae54fcbfc1d4e3ea765 > > | So, let's accept the removal of the guarantee about > > | the output tuple's rowtype marking, recognizing that th

[HACKERS] pg_basebackup throttling doesn't throttle as promised

The "-r" option to pg_basebackup is supposed to throttle the rate of the backup. But it only works properly if the server is mostly idle. Every non-trivial call to XLogFlush or XLogBackgroundFlush will wake up the wal sender (the one which is not really sending wal, but base files), and the throt

Re: [HACKERS] memory fields from getrusage()

On 6/15/17 10:58, Justin Pryzby wrote: > On Thu, Jun 15, 2017 at 10:29:21AM -0400, Robert Haas wrote: >> On Wed, Jun 14, 2017 at 6:28 PM, Justin Pryzby wrote: >>> On Tue, Jun 13, 2017 at 12:16:00PM -0400, Robert Haas wrote: It might be worth adding platform-specific code for common platforms.

Re: [HACKERS] Adding support for Default partition in partitioning

On Thu, Aug 31, 2017 at 8:53 AM, Jeevan Ladhe wrote: > 0001: > This patch refactors RelationBuildPartitionDesc(), basically this is patch > 0001 of default range partition[1]. I spent a while studying this; it seems to be simpler and there's no real downside. So, committed. -- Robert Haas Ente

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

PFA the patches rebased on the latest sources. There are also fixes for some of the crashes and bugs reported. I haven't yet included the testcase patch in the main patchset. On Mon, Aug 28, 2017 at 12:44 PM, Rajkumar Raghuwanshi wrote: > On Mon, Aug 21, 2017 at 12:43 PM, Ashutosh Bapat > wrote:

Re: [HACKERS] Rename RECOVERYXLOG to RECOVERYWAL?

On 9/1/17 2:06 PM, Robert Haas wrote: > On Fri, Sep 1, 2017 at 12:57 PM, David Steele wrote: >> I searched the various threads on the xlog -> wal rename and I couldn't >> find any specific mention of why this was not renamed. >> >> I have attached a patch in case it was an oversight rather than le

Re: [HACKERS] Missing SIZE_MAX

I wrote: > Robert Haas writes: >> It might be worth the effort to clean all of this up, just because the >> next person who gets bitten by it may not be as smart as you are. > Yeah. I was just thinking that maybe the appropriate investment of > effort is to make [U]INT64CONST smarter, so that it

Re: [HACKERS] GnuTLS support

> On 01 Sep 2017, at 20:00, Robert Haas wrote: > > On Fri, Sep 1, 2017 at 1:10 PM, Tom Lane wrote: >> Robert Haas writes: >>> On Thu, Aug 31, 2017 at 1:52 PM, Andreas Karlsson wrote: I have seen discussions from time to time about OpenSSL and its licensing issues so I decided to see

Re: [HACKERS] Rename RECOVERYXLOG to RECOVERYWAL?

On Fri, Sep 1, 2017 at 12:57 PM, David Steele wrote: > I searched the various threads on the xlog -> wal rename and I couldn't > find any specific mention of why this was not renamed. > > I have attached a patch in case it was an oversight rather than left > as-is on purpose. I don't think this r

Re: [HACKERS] OpenFile() Permissions Refactor

On 9/1/17 1:15 PM, Peter Eisentraut wrote: > On 8/29/17 12:15, David Steele wrote: > > I wonder whether we even need that much flexibility. We already set a > global umask, so we could just open all files with 0666 and let the > umask sort it out. Then we don't need all the *Perm() variants. We

Re: [HACKERS] GnuTLS support

On Fri, Sep 1, 2017 at 1:10 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Aug 31, 2017 at 1:52 PM, Andreas Karlsson wrote: >>> I have seen discussions from time to time about OpenSSL and its licensing >>> issues so I decided to see how much work it would be to add support for >>> another

Re: [HACKERS] path toward faster partition pruning

On Thu, Aug 31, 2017 at 2:02 AM, Amit Langote wrote: > Attached is now also the set of patches that implement the actual > partition-pruning logic, viz. the last 3 patches (0004, 0005, and 0006) of > the attached. It strikes me that this patch set is doing two things but maybe in the opposite ord

Re: [HACKERS] CurrentUserId may be invalid during the rest of a session

On Thu, Aug 31, 2017 at 6:02 AM, Richard Guo wrote: > Is this expected behavior? I don't think so. My impression after brief research is that this is a bug introduced here: Author: Tom Lane Branch: master Release: REL8_3_0 [eedb068c0] 2008-01-03 21:23:15 + Branch: REL8_2_STABLE Release: RE

Re: [HACKERS] OpenFile() Permissions Refactor

Peter Eisentraut writes: > I wonder whether we even need that much flexibility. We already set a > global umask, so we could just open all files with 0666 and let the > umask sort it out. Then we don't need all the *Perm() variants. -1. What that would mean is that if somebody had a need for a

Re: [HACKERS] Patch: add --if-exists to pg_recvlogical

On 8/26/17 15:40, Rosser Schwarz wrote: > On Fri, Aug 25, 2017 at 12:34 PM, Robert Haas > wrote: > > On Sun, May 21, 2017 at 3:04 PM, Rosser Schwarz > mailto:rosser.schw...@gmail.com>> wrote: > > While doing some scripting around pg_recvlogical at $work,

Re: [HACKERS] GnuTLS support

> On 01 Sep 2017, at 19:10, Tom Lane wrote: > > Robert Haas writes: >> On Thu, Aug 31, 2017 at 1:52 PM, Andreas Karlsson wrote: > >>> There are currently two failing SSL tests which at least to me seems more >>> like they test specific OpenSSL behaviors rather than something which need >>> to

Re: [HACKERS] OpenFile() Permissions Refactor

On 8/29/17 12:15, David Steele wrote: > While working on the patch to allow group reads of $PGDATA I refactored > the various OpenFile() functions to use default/global permissions > rather than permissions defined in each call. > > I think the patch stands on its own regardless of whether we acce

Re: [HACKERS] Parallel Hash take II

On Thu, Aug 31, 2017 at 8:53 AM, Thomas Munro wrote: > Solution 2: Teach tuple queues to spill to disk instead of blocking > when full. I think this behaviour should probably only be activated > while the leader is running the plan rather than draining tuple > queues; the current block-when-full

Re: [HACKERS] GnuTLS support

Robert Haas writes: > On Thu, Aug 31, 2017 at 1:52 PM, Andreas Karlsson wrote: >> I have seen discussions from time to time about OpenSSL and its licensing >> issues so I decided to see how much work it would be to add support for >> another TLS library, and I went with GnuTLS since it is the li

Re: [HACKERS] signed logging format for pid in log_line_prefix?

Alvaro Herrera writes: > I wonder if we could just adopt pid_t for PIDs. We could (if somebody is willing to find and change all the relevant declarations). But that doesn't do anything at all to clarify which printf format code to use for them. Note that the POSIX snippet you quote doesn't act

Re: [HACKERS] [PATCH] Document the order of changing certain settings when using hot-standby servers

On Thu, Apr 13, 2017 at 8:29 AM, Yorick Peterse wrote: > Good point, right now it can give you the idea that applying it to just > 1 standby (instead of all of them) is good enough, when instead you > need to apply it to all of them. > > Attached is an adjusted version of my changes to better refl

[HACKERS] Rename RECOVERYXLOG to RECOVERYWAL?

I searched the various threads on the xlog -> wal rename and I couldn't find any specific mention of why this was not renamed. I have attached a patch in case it was an oversight rather than left as-is on purpose. Thanks, -- -David da...@pgmasters.net diff --git a/src/backend/access/transam/xlog

Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump

On Mon, Aug 21, 2017 at 5:30 PM, Simon Riggs wrote: > Thinking ahead, are we going to add a new --no-objecttype switch every > time someone wants it? I'd personally be fine with --no-whatever for any whatever that might be a subsidiary property of database objects. We've got --no-security-labels

Re: [HACKERS] Missing SIZE_MAX

Robert Haas writes: > On Fri, Sep 1, 2017 at 12:22 PM, Tom Lane wrote: >> [ warning: more than you really wanted to know ahead ] > It might be worth the effort to clean all of this up, just because the > next person who gets bitten by it may not be as smart as you are. Yeah. I was just thinkin

Re: [HACKERS] log_destination=file

On Fri, Sep 1, 2017 at 6:44 PM, Tom Lane wrote: > Magnus Hagander writes: > > On Fri, Sep 1, 2017 at 6:00 PM, Greg Stark wrote: > >> So what happens now with these messages? My understanding is that > >> they're missing from the CSV logs and are simply inserted into the > >> text logs without a

Re: [HACKERS] Upcoming commit fest will begin soon

On 2017-09-01 16:14:25 +0200, Daniel Gustafsson wrote: > > On 01 Sep 2017, at 05:33, Michael Paquier wrote: > > > > Another question is: who would like to become the CF manager for this > > time? This commit fest is very large, so it is going to be difficult > > for one person to do the whole thi

Re: [HACKERS] log_destination=file

Magnus Hagander writes: > On Fri, Sep 1, 2017 at 6:00 PM, Greg Stark wrote: >> So what happens now with these messages? My understanding is that >> they're missing from the CSV logs and are simply inserted into the >> text logs without any log_line_prefix? The logging collector doesn't >> recogni

Re: [HACKERS] [bug fix] Savepoint-related statements terminates connection

Simon Riggs writes: > On 1 September 2017 at 15:19, Tom Lane wrote: >> This patch makes me itch. Why is it correct for these three checks, >> and only these three checks out of the couple dozen uses of isTopLevel >> in standard_ProcessUtility, to instead do something else? > No problem, it was

Re: [HACKERS] Missing SIZE_MAX

On Fri, Sep 1, 2017 at 12:22 PM, Tom Lane wrote: > [ warning: more than you really wanted to know ahead ] It might be worth the effort to clean all of this up, just because the next person who gets bitten by it may not be as smart as you are. -- Robert Haas EnterpriseDB: http://www.enterprisedb

Re: [HACKERS] [PATCH] Assert that the correct locks are held when calling PageGetLSN()

On Fri, Sep 1, 2017 at 12:24 PM, Jacob Champion wrote: > On Fri, Sep 1, 2017 at 9:12 AM, Robert Haas wrote: >> It's a good idea to add patches to commitfest.postgresql.org > > Hi Robert, I added it yesterday as > https://commitfest.postgresql.org/14/1279/ . Let me know if I need to > touch anythi

Re: [HACKERS] Adding -E switch to pg_dumpall

On Fri, Jul 21, 2017 at 9:21 AM, Michael Paquier wrote: > On Thu, Jul 20, 2017 at 11:17 AM, Fabien COELHO wrote: >> Ok for me. I switched the status to "Ready for committers". > > Thanks for the review, Fabien. LGTM. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Ente

Re: [HACKERS] [PATCH] Assert that the correct locks are held when calling PageGetLSN()

On Fri, Sep 1, 2017 at 9:12 AM, Robert Haas wrote: > It's a good idea to add patches to commitfest.postgresql.org Hi Robert, I added it yesterday as https://commitfest.postgresql.org/14/1279/ . Let me know if I need to touch anything up there. Thanks! --Jacob -- Sent via pgsql-hackers mailing

Re: [HACKERS] log_destination=file

On Fri, Sep 1, 2017 at 6:00 PM, Greg Stark wrote: > On 31 August 2017 at 13:49, Tom Lane wrote: > > Magnus Hagander writes: > >> On Thu, Aug 31, 2017 at 2:34 PM, Tom Lane wrote: > > Yes, it's pretty important, because of assorted stuff not-under-our- > > control that doesn't know about ereport

Re: [HACKERS] Missing SIZE_MAX

[ warning: more than you really wanted to know ahead ] Alvaro Herrera writes: > Tom Lane wrote: >> We have a workaround for that symbol in timezone/private.h: >> #ifndef SIZE_MAX >> #define SIZE_MAX ((size_t) -1) >> #endif >> and a bit of grepping finds other places that are using the (size_t) -1

Re: [HACKERS] [PATCH] Assert that the correct locks are held when calling PageGetLSN()

On Thu, Aug 31, 2017 at 2:53 PM, Jacob Champion wrote: > While working on checksum support for GPDB, we noticed that several > callers of PageGetLSN() didn't follow the correct locking procedure. > To try to help ferret out present and future mistakes, we added an > assertion to PageGetLSN() that

Re: [HACKERS] GnuTLS support

On Thu, Aug 31, 2017 at 1:52 PM, Andreas Karlsson wrote: > I have seen discussions from time to time about OpenSSL and its licensing > issues so I decided to see how much work it would be to add support for > another TLS library, and I went with GnuTLS since it is the library I know > best after

Re: [HACKERS] [bug fix] Savepoint-related statements terminates connection

On 1 September 2017 at 15:19, Tom Lane wrote: > Simon Riggs writes: >> I've added tests to the recent patch to show it works. > > I don't think those test cases prove anything (ie, they work fine > on an unpatched server). With a backslash maybe they would. > >> Any objection to me backpatching

Re: [HACKERS] log_destination=file

On 31 August 2017 at 13:49, Tom Lane wrote: > Magnus Hagander writes: >> On Thu, Aug 31, 2017 at 2:34 PM, Tom Lane wrote: > Yes, it's pretty important, because of assorted stuff not-under-our- > control that doesn't know about ereport and will just print to stderr > anyway. Some examples: dynam

Re: [HACKERS] Missing SIZE_MAX

Tom Lane wrote: > We have a workaround for that symbol in timezone/private.h: > > #ifndef SIZE_MAX > #define SIZE_MAX ((size_t) -1) > #endif > > and a bit of grepping finds other places that are using the (size_t) -1 > trick explicitly. So what I'm tempted to do is move the above stanza > into

Re: [HACKERS] signed logging format for pid in log_line_prefix?

Greg Stark wrote: > Both the text and csv logging seem to use %d on for logging the server pid: > > appendStringInfo(buf, "%d", MyProcPid); > > Am I missing something or wouldn't this mean we print pids with large > values as negative numbers? Isn't that strange? Wouldn't we rather use > %u here?

Re: [HACKERS] Missing SIZE_MAX

On Fri, Sep 1, 2017 at 11:09 AM, Tom Lane wrote: > Commit 2e70d6b5e added a dependency on SIZE_MAX to libpq/fe_exec.c. > According to C99 and recent POSIX, that symbol should be provided > by , but SUS v2 (POSIX 2001) doesn't require > to exist at all ... and I now notice that gaur/pademelon does

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

On Fri, Sep 1, 2017 at 10:03 AM, Dilip Kumar wrote: >> Sure will do so. In the meantime, I have rebased the patch. > > I have repeated some of the tests we have performed earlier. OK, these tests seem to show that this is still working. Committed, again. Let's hope this attempt goes better tha

Re: [HACKERS] signed logging format for pid in log_line_prefix?

Greg Stark writes: > Both the text and csv logging seem to use %d on for logging the server pid: > appendStringInfo(buf, "%d", MyProcPid); > Am I missing something or wouldn't this mean we print pids with large > values as negative numbers? Isn't that strange? Wouldn't we rather use > %u here? p

[HACKERS] Missing SIZE_MAX

Commit 2e70d6b5e added a dependency on SIZE_MAX to libpq/fe_exec.c. According to C99 and recent POSIX, that symbol should be provided by , but SUS v2 (POSIX 2001) doesn't require to exist at all ... and I now notice that gaur/pademelon doesn't have it, and unsurprisingly is failing to compile fe_e

[HACKERS] signed logging format for pid in log_line_prefix?

Both the text and csv logging seem to use %d on for logging the server pid: appendStringInfo(buf, "%d", MyProcPid); Am I missing something or wouldn't this mean we print pids with large values as negative numbers? Isn't that strange? Wouldn't we rather use %u here? -- greg -- Sent via pgsql

Re: [HACKERS] More replication race conditions

Michael Paquier wrote: > On Mon, Aug 28, 2017 at 8:25 AM, Michael Paquier > wrote: > > Today's run has finished with the same failure: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dangomushi&dt=2017-08-27%2018%3A00%3A13 > > Attached is a patch to make this code path wait that the tr

Re: [HACKERS] [PATCH] Fix drop replication slot blocking instead of returning error

On Fri, Sep 1, 2017 at 4:31 PM, Alvaro Herrera wrote: > > Both patches pushed, which should close the open item. Hi Alvaro, thanks a lot! Cheers, Simone. > > -- > Álvaro Herrerahttps://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: [HACKERS] [PATCH] Fix drop replication slot blocking instead of returning error

Both patches pushed, which should close the open item. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

I'm wondering whether this truncation should be yet another available command? Hmmm... maybe not. Currently TRUNCATE pgbench_accounts command is executed within a transaction started immediately before it. If we move it out of the transaction, the table data will be truncated even if the copyi

Re: [HACKERS] [bug fix] Savepoint-related statements terminates connection

Simon Riggs writes: > I've added tests to the recent patch to show it works. I don't think those test cases prove anything (ie, they work fine on an unpatched server). With a backslash maybe they would. > Any objection to me backpatching this, please say. This patch makes me itch. Why is it c

Re: [HACKERS] Upcoming commit fest will begin soon

> On 01 Sep 2017, at 05:33, Michael Paquier wrote: > > Another question is: who would like to become the CF manager for this > time? This commit fest is very large, so it is going to be difficult > for one person to do the whole thing, hence at least 2 people would be > welcome. Please note that

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

On Wed, Aug 30, 2017 at 12:54 PM, Amit Kapila wrote: > > That would have been better. In any case, will do the tests on some > higher end machine and will share the results. > >> Given that we've changed the approach here somewhat, I think we need >> to validate that we're still seeing a substanti

Re: [HACKERS] More replication race conditions

On 31 August 2017 at 12:54, Simon Riggs wrote: >> The above-described topic is currently a PostgreSQL 10 open item. Simon, >> since you committed the patch believed to have created it, you own this open >> item. If some other commit is more relevant or if this does not belong as a >> v10 open i

Re: [HACKERS] [bug fix] Savepoint-related statements terminates connection

On 1 September 2017 at 08:09, Michael Paquier wrote: > On Fri, Sep 1, 2017 at 3:05 PM, Simon Riggs wrote: >> I'm not sure I see the use case for anyone using SAVEPOINTs in this >> context, so simply throwing a good error message is enough. >> >> Clearly nobody is using this, so lets just lock the

Re: [HACKERS] adding the commit to a patch's thread

On Fri, Sep 1, 2017 at 4:26 AM, Alvaro Herrera wrote: > Erik Rijkers wrote: >> Would it be possible to change the commitfest a bit and make it possible to >> add the commit (or commit-message, or hash) to the thread in the >> commitfest-app. > > +1 to add one or more commit hashes to CF entry meta

Re: [HACKERS] [PATCH] Improve geometric types

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested Hi Emre, I'm afraid these patches conflict with current master branch. The

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

Ashutosh Bapat wrote: > I originally thought to provide it along-with the changes to > expand_inherited_rtentry(), but that thread is taking longer. Jeevan > Chalke needs rebased patches for his work on aggregate pushdown and > Thomas might need them for further review. So, here they are. Since

Re: [HACKERS] [PATCH] Off-by-one error in logical slot resource retention

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested Hi Craig, I'm afraid patches 0002 and 0003 don't apply anymore. Could you pl

Re: [HACKERS] Visual Studio 2017 Build Support

On Fri, Sep 1, 2017 at 11:06 AM, Tanay Varma wrote: > > > Hello, > > > > This is with respect to the original thread on “visual studio 2017 build > support” created by Haribabu Kommi (kommi.harib...@gmail.com). > > >

Re: [HACKERS] WIP Patch: Precalculate stable functions, infrastructure v1

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested Hi Marina, I'm sorry to inform you that the v5 path set become a little outd

Re: [HACKERS] Upcoming commit fest will begin soon

On Fri, Sep 1, 2017 at 12:33 PM, Michael Paquier wrote: > Another question is: who would like to become the CF manager for this > time? This commit fest is very large, so it is going to be difficult > for one person to do the whole thing, hence at least 2 people would be > welcome. Please note tha

Re: [HACKERS] Statement-level rollback

On 14 August 2017 at 23:58, Peter Eisentraut wrote: > On 2/28/17 02:39, Tsunakawa, Takayuki wrote: >> The code for stored functions is not written yet, but I'd like your feedback >> for the specification and design based on the current patch. I'll add this >> patch to CommitFest 2017-3. > > Thi

Re: [HACKERS] pg_serial early wraparound

On Wed, Jun 28, 2017 at 1:11 PM, Thomas Munro wrote: > On Sat, Mar 25, 2017 at 7:27 AM, Thomas Munro > wrote: >> On Sat, Mar 25, 2017 at 3:11 AM, Anastasia Lubennikova >> wrote: >>> You claim that SLRUs now support five digit segment name, while in slru.h >>> at current master I see the followin

Re: [HACKERS] Crash on promotion when recovery.conf is renamed

On Sat, Aug 26, 2017 at 7:32 AM, Robert Haas wrote: > On Sat, Apr 8, 2017 at 10:05 AM, David Steele wrote: >> On 3/28/17 1:21 AM, Tsunakawa, Takayuki wrote: >>> Thanks, marked as ready for committer, as the code is good and Alexander >>> reported the test success. >> >> This bug has been moved t

Re: [HACKERS] Minor code improvement to postgresGetForeignPlan

On 2017/04/07 13:12, Tatsuro Yamada wrote:> The declaration of postgresGetForeignPlan uses baserel, but the actual definition uses foreignrel. It would be better to sync. Agreed. Please find attached a patch. The patch looks good to me, so I'll mark this as Ready for Committer. (I'm not s

Re: [HACKERS] Update comment in ExecPartitionCheck

On 2017/08/26 2:28, Robert Haas wrote: On Tue, Jul 4, 2017 at 4:55 AM, Etsuro Fujita wrote: This comment in an error handling in ExecPartitionCheck(): if (!ExecCheck(resultRelInfo->ri_PartitionCheckExpr, econtext)) { char *val_desc; Relationorig_rel = rel;

Re: [HACKERS] CLUSTER command progress monitor

On Fri, Sep 1, 2017 at 3:38 PM, Tatsuro Yamada wrote: > Hi Thomas, > >>> Any comments or suggestion are welcome. >> >> >> Although this patch updates src/test/regress/expected/rules.out I >> think perhaps you included the wrong version? That regression test >> fails for me > > > Thanks for the co

Re: [HACKERS] Surjective functional indexes

On 01.09.2017 09:25, Simon Riggs wrote: On 1 September 2017 at 05:40, Thomas Munro wrote: On Fri, Jun 9, 2017 at 8:08 PM, Konstantin Knizhnik wrote: Attached please find rebased version of the patch. Now "projection" attribute is used instead of surjective/injective. Hi Konstantin, This st

Re: [HACKERS] pgjdbc logical replication client throwing exception

Hi, I am also facing the same issue. Have you solved the problem? Could you please guide me how to deal with it. Thanks, Dipesh -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make chan

Re: [HACKERS] PG 10 release notes

Hi all, On Tue, Aug 1, 2017 at 5:53 AM, Thomas Munro wrote: > On Tue, Apr 25, 2017 at 1:31 PM, Bruce Momjian wrote: >> I have committed the first draft of the Postgres 10 release notes. They >> are current as of two days ago, and I will keep them current. Please >> give me any feedback you hav

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

On Fri, Sep 1, 2017 at 4:42 PM, Fabien COELHO wrote: > > Hello Masahiko-san, > > Patch applies and compiles. > > One bug found, and some minor points again. Sorry for this hopefully last > iteration... I'm kind of an iterative person... > > I've generated the doc to look a it. > > Short option "-I

Re: [HACKERS] adding the commit to a patch's thread

Erik Rijkers wrote: > Would it be possible to change the commitfest a bit and make it possible to > add the commit (or commit-message, or hash) to the thread in the > commitfest-app. +1 to add one or more commit hashes to CF entry metadata. (Back-filling for old entries welcome) -- Álvaro Herr

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

Hello Masahiko-san, Patch applies and compiles. One bug found, and some minor points again. Sorry for this hopefully last iteration... I'm kind of an iterative person... I've generated the doc to look a it. Short option "-I" does not use a "=", it should be "-I custom_init_commands". Als

Re: [HACKERS] [bug fix] Savepoint-related statements terminates connection

On Fri, Sep 1, 2017 at 3:05 PM, Simon Riggs wrote: > I'm not sure I see the use case for anyone using SAVEPOINTs in this > context, so simply throwing a good error message is enough. > > Clearly nobody is using this, so lets just lock the door. I don't > think fiddling with the transaction block s

  1   2   >