Re: [HACKERS] Transaction control in procedures

On 31 October 2017 at 15:38, Peter Eisentraut wrote: > Here is a patch that implements transaction control in PL/Python > procedures. (This patch goes on top of "SQL procedures" patch v1.) The patch is incredibly short for such a feature, which is probably a

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

Hi Michael On Mon, Nov 6, 2017 at 6:18 PM, Michael Paquier wrote: > > Did you really test WAL replay? This still ignores that PageGetLSN is > as well taken in some code paths, like recovery, where actions on the > page are guaranteed to be serialized, like during

Re: [HACKERS] taking stdbool.h into use

On Thu, Nov 9, 2017 at 1:46 AM, Peter Eisentraut wrote: > On 10/29/17 08:50, Michael Paquier wrote: >> I spotted a couple of other things while looking at your patches and >> the code tree. >> >> - return (ginCompareItemPointers(>itemptr, iptr) > 0) ? TRUE :

Re: [HACKERS] Pg V10: Patch for bug in bonjour support

# dpkg -S !$ dpkg -S /usr/lib/x86_64-linux-gnu/libdns_sd.so.1.0.0 libavahi-compat-libdnssd1:amd64: /usr/lib/x86_64-linux-gnu/libdns_sd.so.1.0.0 Also:   ii libavahi-compat-libdnssd1:amd640.6.32-1ubuntu1 amd64Avahi Apple Bonjour

Re: [HACKERS] Pg V10: Patch for bug in bonjour support

Hi Tom – works for me on Linux (Ubuntu)… - Luke *** /home/llonergan/archive/configure.in2017-11-08 14:17:56.804891827 -0800 --- configure.in2017-11-08 14:15:58.961186149 -0800 *** *** 1293,1298 --- 1293,1299 if test

Re: [HACKERS] Pg V10: Patch for bug in bonjour support

Luke Lonergan writes: > Hi Tom – works for me on Linux (Ubuntu)… BTW, when I try this on Fedora 25, it builds cleanly but the feature doesn't seem to work --- I get this at postmaster start: *** WARNING *** The program 'postgres' uses the Apple Bonjour compatibility layer

Re: [HACKERS] Pg V10: Patch for bug in bonjour support

Luke Lonergan writes: > Hi Tom – works for me on Linux (Ubuntu)… > + AC_SEARCH_LIBS([DNSServiceRefSockFD],[dns_sd]) Pushed with an error message added. I also took the trouble to standardize the syntax of our various AC_SEARCH_LIBS calls --- they weren't very consistent

Re: [HACKERS] Exclude pg_internal.init from base backup

On Thu, Nov 9, 2017 at 1:03 AM, Peter Eisentraut wrote: > On 11/7/17 19:58, Michael Paquier wrote: >> On Wed, Nov 8, 2017 at 9:50 AM, Haribabu Kommi >> wrote: >>> Thanks for the correction. I was not much aware of SGML markup usage.

Re: [HACKERS] [PATCH] fix wrong create table statement in documentation

jotpe writes: > In the current documentation [1] this create table statement is listed: > CREATE TABLE measurement_y2008m01 PARTITION OF measurement > FOR VALUES FROM ('2008-01-01') TO ('2008-02-01') > TABLESPACE fasttablespace > WITH (parallel_workers = 4); Yup,

Re: [HACKERS] Small improvement to compactify_tuples

On Wed, Nov 8, 2017 at 12:59 PM, Andres Freund wrote: > I complained about multiple related things, I'm not exactly sure what > exactly you're referring to here: > - The fact that HeapTupleHeaderData's are commonly iterated over in > reverse order is bad for performance. For

Re: [HACKERS] Early locking option to parallel backup

On 11/06/2017 12:30 PM, Stephen Frost wrote: * Lucas (luca...@gmail.com) wrote: pg_dump was taking more than 24 hours to complete in one of my databases. I begin to research alternatives. Parallel backup reduced the backup time to little less than a hour, but it failed almost every time because

Re: [HACKERS] Pg V10: Patch for bug in bonjour support

Thomas Munro writes: > On Thu, Nov 9, 2017 at 10:05 AM, Luke Lonergan wrote: >> + AC_CHECK_LIB(dns_sd, DNSServiceRefSockFD, [], [AC_MSG_ERROR([library >> 'dns_sd' is required for Bonjour])]) > It lives in libSystem.dylib (implicitly linked)

Re: [HACKERS] OpenTemporaryFile() vs resowner.c

Thomas Munro writes: > Andres, Robert and Peter G rightly complained[1] that my shared > temporary file patch opens a file, then calls > ResourceOwnerEnlargeFiles() which can fail due to lack of memory, and > then registers the file handle to make sure we don't leak

Re: [HACKERS] Pg V10: Patch for bug in bonjour support

On Thu, Nov 9, 2017 at 10:05 AM, Luke Lonergan wrote: > if test "$with_bonjour" = yes ; then > > AC_CHECK_HEADER(dns_sd.h, [], [AC_MSG_ERROR([header file is > required for Bonjour])]) > > + AC_CHECK_LIB(dns_sd, DNSServiceRefSockFD, [], [AC_MSG_ERROR([library >

[HACKERS] Pg V10: Patch for bug in bonjour support

Hi all – I’m doing some geo analysis and was excited to see all the new features in V10 – particularly the declarative partitioning support! Found a tiny bug in the build for Bonjour – patch below: *** configure.in  2017-10-02 14:09:15.0 -0700 ---

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

Michael Paquier writes: > On Tue, Sep 26, 2017 at 11:42 AM, Vaishnavi Prabakaran > wrote: >> I moved the cf entry to "ready for committer", and though my vote is for >> keeping the existing API behavior with write implying read, I let the

Re: [HACKERS] Small improvement to compactify_tuples

On 2017-11-08 12:02:40 -0500, Tom Lane wrote: > BTW, it strikes me that in considering the rebuild-the-page approach, > we should not have blinders on and just measure the speed of > PageRepairFragmentation. Rather, we should take a look at what happens > subsequently given a physically-ordered

Re: [HACKERS] Small improvement to compactify_tuples

2017-11-08 20:02 GMT+03:00 Tom Lane : > > Claudio Freire writes: > > What's perhaps not clear is whether there are better ideas. Like > > rebuilding the page as Tom proposes, which doesn't seem like a bad > > idea. Bucket sort already is O(bytes), just

[HACKERS] [PATCH] fix wrong create table statement in documentation

In the current documentation [1] this create table statement is listed: CREATE TABLE measurement_y2008m01 PARTITION OF measurement FOR VALUES FROM ('2008-01-01') TO ('2008-02-01') TABLESPACE fasttablespace WITH (parallel_workers = 4); But that did not work: 2017-11-06 22:26:11.757

Re: [HACKERS] Parallel Hash take II

Hi, @@ -747,7 +747,7 @@ try_hashjoin_path(PlannerInfo *root, * never have any output pathkeys, per comments in create_hashjoin_path. */ initial_cost_hashjoin(root, , jointype, hashclauses, - outer_path, inner_path, extra);

Re: [HACKERS] need info about extensibility in other databases

On Wed, Nov 8, 2017 at 2:37 PM, Li Song wrote: > Hi, > > When is the English version of "GiST programming tutorial" available? Well, I wrote it many years ago, so it needs to be updated. For now, you can use google translate, which seems works fine

Re: [HACKERS] [PATCH] A hook for session start

On Wed, Nov 8, 2017 at 12:47 AM, Michael Paquier wrote: > > + /* Hook just normal backends */ > + if (session_end_hook && MyBackendId != InvalidBackendId) > + (*session_end_hook) (); > I have been wondering about the necessity of this restriction. > Couldn't

Re: [HACKERS] SQL procedures

On Wed, Nov 8, 2017 at 11:03 AM, Peter Eisentraut wrote: > On 11/8/17 11:11, Merlin Moncure wrote: >> On Wed, Nov 8, 2017 at 9:13 AM, Peter Eisentraut >> wrote: >>> I have already submitted a separate patch that addresses these

Re: [HACKERS] SQL procedures

On 11/8/17 11:11, Merlin Moncure wrote: > On Wed, Nov 8, 2017 at 9:13 AM, Peter Eisentraut > wrote: >> I have already submitted a separate patch that addresses these questions. > > Maybe I'm obtuse, but I'm not seeing it? In very interested in the > general

Re: [HACKERS] Small improvement to compactify_tuples

Claudio Freire writes: > What's perhaps not clear is whether there are better ideas. Like > rebuilding the page as Tom proposes, which doesn't seem like a bad > idea. Bucket sort already is O(bytes), just as memcopy, only it has a > lower constant factor (it's bytes/256 in

Re: [HACKERS] taking stdbool.h into use

On 10/29/17 08:50, Michael Paquier wrote: > I had a look at this patch series. Patches 1, 2 (macos headers indeed > show that NSUNLINKMODULE_OPTION_NONE is set to 0x0), 3 to 7 look fine > to me. Committed 4 and 5 together. > I spotted a couple of other things while looking at your patches and >

Re: [HACKERS] Small improvement to compactify_tuples

On Wed, Nov 8, 2017 at 12:33 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Nov 7, 2017 at 4:39 PM, Tom Lane wrote: >>> What I'm getting from the standard pgbench measurements, on both machines, >>> is that this patch might be

Re: [HACKERS] Small improvement to compactify_tuples

On Wed, Nov 8, 2017 at 8:19 AM, Robert Haas wrote: > I don't remember any more just how much faster qsort_tuple() and > qsort_ssup() are than plain qsort(), but it was significant enough to > convince me to commit 337b6f5ecf05b21b5e997986884d097d60e4e3d0... IIRC,

Re: [HACKERS] [PATCH] Generic type subscripting

Thank you for fixing. On Tue, Nov 07, 2017 at 09:00:43PM +0100, Dmitry Dolgov wrote: > > > +Datum > > > +custom_subscripting_parse(PG_FUNCTION_ARGS) > > > +{ > > > + boolisAssignment = PG_GETARG_BOOL(0); > > > > Here isAssignment is unused variable, so it could be

Re: [HACKERS] Small improvement to compactify_tuples

Robert Haas writes: > Just to throw a random idea out here, we currently have > gen_qsort_tuple.pl producing qsort_tuple() and qsort_ssup(). Maybe it > could be modified to also produce a specialized qsort_itemids(). That > might be noticeably faster that our

Re: [HACKERS] Small improvement to compactify_tuples

On Wed, Nov 8, 2017 at 10:33 AM, Tom Lane wrote: > I do not think there is any change here that can be proven to always be a > win. Certainly the original patch, which proposes to replace an O(n log n) > sort algorithm with an O(n^2) one, should not be thought to be that. >

Re: [HACKERS] SQL procedures

On Wed, Nov 8, 2017 at 9:13 AM, Peter Eisentraut wrote: > I have already submitted a separate patch that addresses these questions. Maybe I'm obtuse, but I'm not seeing it? In very interested in the general approach to transaction management; if you've described

Re: [HACKERS] Exclude pg_internal.init from base backup

On 11/7/17 19:58, Michael Paquier wrote: > On Wed, Nov 8, 2017 at 9:50 AM, Haribabu Kommi > wrote: >> Thanks for the correction. I was not much aware of SGML markup usage. >> While building the documentation, it raises an warning message of "empty >> end-tag". >> So I

Re: [HACKERS] Horrible CREATE DATABASE Performance in High Sierra

Peter Eisentraut writes: > On 10/7/17 16:46, Tom Lane wrote: >> Accordingly I propose the attached patch. If anyone's interested in >> experimenting on other platforms, we might be able to refine/complicate >> the FLUSH_DISTANCE selection further, but I think

Re: [HACKERS] Small improvement to compactify_tuples

Robert Haas writes: > On Tue, Nov 7, 2017 at 4:39 PM, Tom Lane wrote: >> What I'm getting from the standard pgbench measurements, on both machines, >> is that this patch might be a couple percent slower than HEAD, but that is >> barely above the noise

Re: [HACKERS] Horrible CREATE DATABASE Performance in High Sierra

On November 8, 2017 7:31:17 AM PST, Peter Eisentraut wrote: >On 10/7/17 16:46, Tom Lane wrote: >> I wrote: >>> Current status is that I've filed a bug report with Apple and am >waiting >>> to see their response before deciding what to do next. If they fix

Re: [HACKERS] Horrible CREATE DATABASE Performance in High Sierra

On 10/7/17 16:46, Tom Lane wrote: > I wrote: >> Current status is that I've filed a bug report with Apple and am waiting >> to see their response before deciding what to do next. If they fix the >> issue promptly then there's little need for us to do anything. > Accordingly I propose the

Re: [HACKERS] SQL procedures

On 11/8/17 09:23, Merlin Moncure wrote: > I do wonder how transaction control could be added later. > > The last time I (lightly) looked at this, I was starting to think that > working transaction control into the SPI interface was the wrong > approach; pl/pgsql would have to adopt a very

Re: [HACKERS] SQL procedures

On 11/8/17 09:33, Pavel Stehule wrote: > We can create auto session variable STATUS. This variable can be 0 > if procedure was returned without explicit RETURN value. Or it can > hold different value specified by RETURN expr. > > This value can be read by GET DIAGNOSTICS xxx =

Re: [HACKERS] SQL procedures

On 11/6/17 16:27, Simon Riggs wrote: > You mention PARALLEL SAFE is not used for procedures. Isn't it an > architectural restriction that procedures would not be able to execute > in parallel? (At least this year) I'm not sure what you are referring to here. I don't think the functionality I'm

Re: [HACKERS] SQL procedures

Peter Eisentraut writes: > On 10/31/17 14:23, Tom Lane wrote: >> Why not use VOIDOID for the prorettype value? > We need a way to distinguish functions that are callable by SELECT and > procedures that are callable by CALL. Do procedures of this ilk belong in

Re: [HACKERS] SQL procedures

On 08.11.2017 17:23, Merlin Moncure wrote: On Tue, Oct 31, 2017 at 12:23 PM, Peter Eisentraut wrote: - Transaction control in procedure bodies This feature is really key, since it enables via SQL lots of things that are not possible without external coding,

[HACKERS] Proposal: ALTER EXTENSION SET OPTION

Hi all; One of the annoyances we currently deal with regarding analytics extensions in a PG environment with mixed versions is there is no facility right now to conditionally support certain modifications to functions that might be required to make certain features work properly. The case that

Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

On Wed, Nov 8, 2017 at 5:41 AM, Robert Haas wrote: > On Mon, Nov 6, 2017 at 4:42 AM, Masahiko Sawada wrote: I suggest that a good thing to do more or less immediately, regardless of when this patch ends up being ready, would be to insert an

Re: [HACKERS] SQL procedures

2017-11-08 15:31 GMT+01:00 Pavel Stehule : > > > 2017-11-08 15:23 GMT+01:00 Peter Eisentraut com>: > >> On 10/31/17 16:50, Pavel Stehule wrote: >> > Not sure if disabling RETURN is good idea. I can imagine so optional >> > returning

Re: [HACKERS] SQL procedures

2017-11-08 15:23 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > On 10/31/17 16:50, Pavel Stehule wrote: > > Not sure if disabling RETURN is good idea. I can imagine so optional > > returning something like int status can be good idea. Cheaper than > > raising a exception. > >

Re: [HACKERS] SQL procedures

On Tue, Oct 31, 2017 at 12:23 PM, Peter Eisentraut wrote: > - Transaction control in procedure bodies This feature is really key, since it enables via SQL lots of things that are not possible without external coding, including: *) very long running processes in

Re: [HACKERS] SQL procedures

On 10/31/17 16:50, Pavel Stehule wrote: > Not sure if disabling RETURN is good idea. I can imagine so optional > returning something like int status can be good idea. Cheaper than > raising a exception. We could allow a RETURN without argument in PL/pgSQL, if you just want to exit early. That

Re: [HACKERS] SQL procedures

On 10/31/17 14:23, Tom Lane wrote: > Putting 0 in prorettype seems like a pretty bad idea. It seemed like the natural thing to do, since we use a zero OID to indicate "nothing" in many other places. > Why not use VOIDOID for the prorettype value? We need a way to distinguish functions that are

Re: [HACKERS] why not parallel seq scan for slow functions

On Wed, Nov 8, 2017 at 7:26 AM, Amit Kapila wrote: > We do want to generate it later when there isn't inheritance involved, > but only if there is a single rel involved (simple_rel_array_size > <=2). The rule is something like this, we will generate the gather > paths at

Re: [HACKERS] why not parallel seq scan for slow functions

On Wed, Nov 8, 2017 at 4:34 PM, Robert Haas wrote: > On Tue, Nov 7, 2017 at 9:41 PM, Amit Kapila wrote: >> This is required to prohibit generating gather path for top rel in >> case of inheritence (Append node) at this place (we want to generate >>

Re: [HACKERS] need info about extensibility in other databases

Hi, When is the English version of "GiST programming tutorial" available? Regards, Song -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Small improvement to compactify_tuples

On Tue, Nov 7, 2017 at 4:39 PM, Tom Lane wrote: > What I'm getting from the standard pgbench measurements, on both machines, > is that this patch might be a couple percent slower than HEAD, but that is > barely above the noise floor so I'm not too sure about it. Hmm. It

Re: [HACKERS] why not parallel seq scan for slow functions

On Tue, Nov 7, 2017 at 9:41 PM, Amit Kapila wrote: > This is required to prohibit generating gather path for top rel in > case of inheritence (Append node) at this place (we want to generate > it later when scan/join target is available). OK, but why don't we want to

Re: [HACKERS] path toward faster partition pruning

Hi Rajkumar, Thanks for testing. On 2017/11/08 15:52, Rajkumar Raghuwanshi wrote: > On Mon, Nov 6, 2017 at 3:31 PM, Amit Langote > wrote: > >> Attached updated set of patches, including the fix to make the new pruning >> code handle Boolean partitioning. >> > >

Re: [HACKERS] path toward faster partition pruning

On Mon, Nov 6, 2017 at 3:31 PM, Amit Langote wrote: > Attached updated set of patches, including the fix to make the new pruning > code handle Boolean partitioning. > Hi Amit, I have tried pruning for different values of constraint exclusion GUC change, not sure

Re: [HACKERS] MERGE SQL Statement for PG11

Ah, there is one reason not to use a mapping to CTEs to implement MERGE: it might be faster to use a single query that is a FULL OUTER JOIN of the source and target to drive the update/insert/delete operations. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] UPDATE of partition key

On Wed, Nov 8, 2017 at 5:57 PM, Amit Khandekar wrote: > Thomas, can you please try the attached incremental patch > regress_locale_changes.patch and check if the test passes ? The patch > is to be applied on the main v22 patch. If the test passes, I will > include these

Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

Hi David. Thanks for the review. (..also looking at the comments you sent earlier today.) On 2017/11/07 11:14, David Rowley wrote: > On 7 November 2017 at 01:52, David Rowley > wrote: >> Thanks. I'll look over it all again starting my Tuesday morning. (UTC+13) >

Re: [HACKERS] UPDATE of partition key

On 8 November 2017 at 07:55, Thomas Munro wrote: > On Tue, Nov 7, 2017 at 8:03 AM, Robert Haas wrote: >> The changes to trigger.c still make me super-nervous. Hey THOMAS >> MUNRO, any chance you could review that part? > > Looking, but

Re: [HACKERS] path toward faster partition pruning

On 7 November 2017 at 01:52, David Rowley wrote: > Thanks. I'll look over it all again starting my Tuesday morning. (UTC+13) Hi Amit, I had another look over this today. Apologies if any of the review seems petty. Here goes: 1. If test seems to be testing for a

Re: [HACKERS] Restricting maximum keep segments by repslots

Hello, At Mon, 6 Nov 2017 05:20:50 -0800, Andres Freund wrote in <20171106132050.6apzynxrqrzgh...@alap3.anarazel.de> > Hi, > > On 2017-10-31 18:43:10 +0900, Kyotaro HORIGUCHI wrote: > > - distance: > > how many bytes LSN can advance before the margin defined by > >

Re: [HACKERS] Parallel Hash take II

Hi, * avoids wasting memory on duplicated hash tables * avoids wasting disk space on duplicated batch files * avoids wasting CPU executing duplicate subplans What's the last one referring to? +static void +MultiExecParallelHash(HashState *node) +{ + switch

Re: [HACKERS] Fix bloom WAL tap test

On Wed, Nov 8, 2017 at 11:20 AM, Michael Paquier wrote: > On Wed, Nov 8, 2017 at 1:58 AM, Alexander Korotkov > wrote: >> On Tue, Nov 7, 2017 at 4:34 PM, Masahiko Sawada >> wrote: >>> I understood the necessity of this

Re: [HACKERS] [PATCH] A hook for session start

On Tue, Nov 7, 2017 at 9:58 PM, Fabrízio de Royes Mello wrote: > On Tue, Nov 7, 2017 at 1:15 AM, Michael Paquier > wrote: >> On Sun, Nov 5, 2017 at 3:14 AM, Fabrízio de Royes Mello >> wrote: >> I was going to to hack

Re: [HACKERS] why not parallel seq scan for slow functions

On Wed, Nov 8, 2017 at 2:51 AM, Robert Haas wrote: > On Mon, Nov 6, 2017 at 9:57 PM, Amit Kapila wrote: > >>> Also, even if inheritance is used, we might still be the >>> topmost scan/join target. >> >> Sure, but in that case, it won't generate

Re: [HACKERS] UPDATE of partition key

On Tue, Nov 7, 2017 at 8:03 AM, Robert Haas wrote: > The changes to trigger.c still make me super-nervous. Hey THOMAS > MUNRO, any chance you could review that part? Looking, but here's one silly thing that jumped out at me while getting started with this patch. I cannot

Re: [HACKERS] [COMMITTERS] pgsql: Expand empty end tag

On Wed, Nov 8, 2017 at 11:15 AM, Peter Eisentraut wrote: > Expand empty end tag Perhaps you missed this patch? https://www.postgresql.org/message-id/CAJrrPGdkL8TFk+-VivrW637js0v_KM=ub4pBFy=nf0bpafb...@mail.gmail.com It seems to me that the information within brackets should not

Re: [HACKERS] Fix bloom WAL tap test

On Wed, Nov 8, 2017 at 1:58 AM, Alexander Korotkov wrote: > On Tue, Nov 7, 2017 at 4:34 PM, Masahiko Sawada > wrote: >> I understood the necessity of this patch and reviewed two patches. > > Good, thank you. That's clearly a bug fix. >> diff

Re: [HACKERS] Fix bloom WAL tap test

On Wed, Nov 8, 2017 at 1:49 AM, Alexander Korotkov wrote: > On Tue, Nov 7, 2017 at 4:26 PM, Fabrízio Mello > wrote: >> The patch doesn't apply against master: >> >> fabrizio@macanudo:/d/postgresql (master) >> $ git apply

Re: [HACKERS] Remove duplicate setting in test/recovery/Makefile

On Wed, Nov 8, 2017 at 10:38 AM, Masahiko Sawada wrote: > Hi, > > I found that EXTRA_INSTALL is doubly set at both top and bottom of the > src/test/recovery/Makefile. Is it necessary? > > Attached patch fixes this. Indeed, there is some bad overlap between d851bef and

Re: [HACKERS] Fix a typo in dsm_impl.c

On Wed, Nov 8, 2017 at 6:36 AM, Robert Haas wrote: > On Mon, Nov 6, 2017 at 11:22 PM, Masahiko Sawada > wrote: >> Attached the patch for $subject. > > Committed. > Thank you! Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION

[HACKERS] Remove duplicate setting in test/recovery/Makefile

Hi, I found that EXTRA_INSTALL is doubly set at both top and bottom of the src/test/recovery/Makefile. Is it necessary? Attached patch fixes this. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center remove_duplicate_setting.patch

[HACKERS] OpenTemporaryFile() vs resowner.c

Hi hackers, Andres, Robert and Peter G rightly complained[1] that my shared temporary file patch opens a file, then calls ResourceOwnerEnlargeFiles() which can fail due to lack of memory, and then registers the file handle to make sure we don't leak it. Doh. The whole point of the separate

Re: [HACKERS] Exclude pg_internal.init from base backup

On Wed, Nov 8, 2017 at 9:50 AM, Haribabu Kommi wrote: > Thanks for the correction. I was not much aware of SGML markup usage. > While building the documentation, it raises an warning message of "empty > end-tag". > So I just added the end tag. Attached the update patch

Re: [HACKERS] Exclude pg_internal.init from base backup

On Wed, Nov 8, 2017 at 11:11 AM, Michael Paquier wrote: > On Wed, Nov 8, 2017 at 9:04 AM, Haribabu Kommi > wrote: > > The commit 98267e missed to check the empty SGML tag, attached patch > > fixes the same. > > > > -

Re: [HACKERS] MERGE SQL Statement for PG11

On Tue, Nov 07, 2017 at 03:31:22PM -0800, Peter Geoghegan wrote: > On Tue, Nov 7, 2017 at 3:29 PM, Nico Williams wrote: > > On Thu, Nov 02, 2017 at 03:25:48PM -0700, Peter Geoghegan wrote: > >> Nico Williams wrote: > >> >A MERGE mapped to a DML like

Re: [HACKERS] Exclude pg_internal.init from base backup

On Wed, Nov 8, 2017 at 9:04 AM, Haribabu Kommi wrote: > The commit 98267e missed to check the empty SGML tag, attached patch > fixes the same. - pg_internal.init (found in multiple directories) + pg_internal.init (found in multiple

Re: [HACKERS] Exclude pg_internal.init from base backup

On Wed, Nov 8, 2017 at 3:03 AM, Simon Riggs wrote: > On 5 November 2017 at 11:55, Magnus Hagander wrote: > > On Sat, Nov 4, 2017 at 4:04 AM, Michael Paquier < > michael.paqu...@gmail.com> > > wrote: > >> > >> On Fri, Nov 3, 2017 at 4:04 PM, Petr

Re: [HACKERS] Parallel Hash take II

Hi Peter, See responses to a couple of points below. I'll respond to the other points separately (ie with code/comment changes). On Wed, Nov 8, 2017 at 10:32 AM, Peter Geoghegan wrote: > On Tue, Nov 7, 2017 at 1:01 PM, Andres Freund wrote: >> +/* >> + *

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Wed, Nov 8, 2017 at 8:48 AM, Robert Haas wrote: > On Tue, Nov 7, 2017 at 4:35 AM, Haribabu Kommi > wrote: > > The newly added option is not recommended to be used in normal cases and > > it is used only for upgrade utilities. > > I don't know

Re: [HACKERS] MERGE SQL Statement for PG11

On Tue, Nov 7, 2017 at 3:29 PM, Nico Williams wrote: > On Thu, Nov 02, 2017 at 03:25:48PM -0700, Peter Geoghegan wrote: >> Nico Williams wrote: >> >A MERGE mapped to a DML like this: > > I needed to spend more time reading MERGE docs from other

Re: [HACKERS] [PATCH] Add ALWAYS DEFERRED option for constraints

On Mon, Nov 06, 2017 at 05:50:21PM +1300, Thomas Munro wrote: > On Fri, Oct 20, 2017 at 9:05 AM, Nico Williams wrote: > > Rebased (there were conflicts in the SGML files). > > Hi Nico > > FYI that version has some stray absolute paths in constraints.source: > > -COPY

Re: [HACKERS] MERGE SQL Statement for PG11

On Thu, Nov 02, 2017 at 03:25:48PM -0700, Peter Geoghegan wrote: > Nico Williams wrote: > >A MERGE mapped to a DML like this: I needed to spend more time reading MERGE docs from other RDBMSes. The best MERGE so far is MS SQL Server's, which looks like: MERGE INTO

Re: [HACKERS] Exclude pg_internal.init from base backup

On Wed, Nov 8, 2017 at 1:42 AM, David Steele wrote: > On 11/7/17 11:03 AM, Simon Riggs wrote: >> On 5 November 2017 at 11:55, Magnus Hagander wrote: >>> >>> So +1 for documenting the difference in how these are handled, as this is >>> important to know

Re: [HACKERS] Remove secondary checkpoint

On Wed, Nov 8, 2017 at 2:23 AM, Simon Riggs wrote: > On 31 October 2017 at 12:01, Michael Paquier > wrote: >> While the mention about a manual checkpoint happening after a timed >> one will cause a full range of WAL segments to be recycled, it

Re: [HACKERS] Small improvement to compactify_tuples

On Tue, Nov 7, 2017 at 2:40 PM, Юрий Соколов wrote: >> The same is true of unique indexes vs. non-unique. > > offtopic: recently I'd a look at setting LP_DEAD in indexes. > I didn't found huge difference between unique and non-unique indices. > There is codepath that works

Re: [HACKERS] Small improvement to compactify_tuples

On Tue, Nov 7, 2017 at 2:36 PM, Tom Lane wrote: > Peter Geoghegan writes: >> My point is only that it's worth considering that this factor affects >> how representative your sympathetic case is. It's not clear how many >> PageIndexMultiDelete() calls are from

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

On Wed, Nov 8, 2017 at 2:26 AM, Jacob Champion wrote: > On Mon, Nov 6, 2017 at 6:18 PM, Michael Paquier > wrote: >> Did you really test WAL replay? > > Is there a way to test this other than installcheck-world? The only > failure we've run into at

Re: [HACKERS] Small improvement to compactify_tuples

2017-11-08 1:11 GMT+03:00 Peter Geoghegan : > > The same is true of unique indexes vs. non-unique. offtopic: recently I'd a look at setting LP_DEAD in indexes. I didn't found huge difference between unique and non-unique indices. There is codepath that works only for unique, but it

Re: [HACKERS] Small improvement to compactify_tuples

Peter Geoghegan writes: > My point is only that it's worth considering that this factor affects > how representative your sympathetic case is. It's not clear how many > PageIndexMultiDelete() calls are from opportunistic calls to > _bt_vacuum_one_page(), how important that subset of

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

On Tue, Nov 7, 2017 at 9:26 AM, Jacob Champion wrote: > On Mon, Nov 6, 2017 at 6:18 PM, Michael Paquier > wrote: >> It seems to me that 0001 is good for a committer lookup, that will get >> rid of all existing bugs. For 0002, what you are

Re: [HACKERS] Small improvement to compactify_tuples

) On Tue, Nov 7, 2017 at 1:39 PM, Tom Lane wrote: > So I think we should seriously consider the attached, but it'd be a > good idea to benchmark it on a wider variety of platforms and test > cases. > create unlogged table test3 ( > id integer PRIMARY KEY with

Re: [HACKERS] Parallel Hash take II

On Wed, Nov 8, 2017 at 10:32 AM, Robert Haas wrote: > On Tue, Nov 7, 2017 at 4:01 PM, Andres Freund wrote: >> diff --git a/src/backend/utils/resowner/resowner.c >> b/src/backend/utils/resowner/resowner.c >> index 4c35ccf65eb..8b91d5a6ebe 100644 >> ---

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Tue, Nov 7, 2017 at 4:35 AM, Haribabu Kommi wrote: > The newly added option is not recommended to be used in normal cases and > it is used only for upgrade utilities. I don't know why it couldn't be used in normal cases. That seems like a totally legitimate thing

Re: [HACKERS] [PATCH] Overestimated filter cost and its mitigation

Robert Haas writes: > I think it would be a good idea, as Thomas says, to order the qual > clauses at an earlier stage and then remember our decision. However, > we have to think about whether that's going to increase planning time > in a noticeable way. I wonder why we

Re: [HACKERS] pg_stat_wal_write statistics view

On Tue, Nov 7, 2017 at 4:31 AM, Haribabu Kommi wrote: >> Updated patch attached. > Patch rebased. I think the earlier concerns about the performance impact of this are probably very valid concerns, and I don't see how the new version of the patch gets us much closer to

Re: [HACKERS] Small improvement to compactify_tuples

I've been getting less and less excited about this patch, because I still couldn't measure any above-the-noise performance improvement without artificial exaggerations, and some cases seemed actually slower. However, this morning I had an epiphany: why are we sorting at all? There is no

Re: [HACKERS] Fix a typo in dsm_impl.c

On Mon, Nov 6, 2017 at 11:22 PM, Masahiko Sawada wrote: > Attached the patch for $subject. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] Parallel Hash take II

On Tue, Nov 7, 2017 at 1:01 PM, Andres Freund wrote: > +/* > + * Build the name for a given segment of a given BufFile. > + */ > +static void > +MakeSharedSegmentName(char *name, const char *buffile_name, int segment) > +{ > + snprintf(name, MAXPGPATH, "%s.%d",

<    1   2   3   4   5   6   7   8   9   10   >