On Wed, Mar 06, 2019 at 07:45:06PM +1300, David Rowley wrote:
> Partitioned indexes have this similar inherit tablespace from parent
> feature, so ca4103025dfe26 was intended to align the behaviour of the
> two. Partitioned indexes happen not to suffer from the same issue as
> the indexes are attac
Hi,
Commit bd7c95f0c1a38becffceb3ea7234d57167f6d4bf add DECLARE
STATEMENT support to ECPG. This introduced the new rule
for EXEC SQL CLOSE cur and with that it gets transformed into
ECPGclose().
Now prior to the above commit, someone can declare the
cursor in the SQL statement and "CLOSE cur_nam
Hi,
On 2019/03/06 15:48, Michael Paquier wrote:
> On Tue, Mar 05, 2019 at 11:04:17PM +0900, Amit Langote wrote:
>> Maybe we should error out as follows in
>> transformPartitionRangeBounds(), although that means we'll get
>> different error message than when using list partitioning syntax:
>
> Hm.
On Tue, Mar 05, 2019 at 11:04:17PM +0900, Amit Langote wrote:
> Maybe we should error out as follows in
> transformPartitionRangeBounds(), although that means we'll get
> different error message than when using list partitioning syntax:
Hm. I don't think that this is a good idea as you could lose
Over on [1] Andres pointed out that the pg_dump support for the new to
PG12 tablespace inheritance feature is broken. This is the feature
added in ca4103025dfe26 to allow a partitioned table to have a
tablespace that acts as the default tablespace for newly attached
partitions. The idea being that
On 2019/03/05 17:56, Tatsuro Yamada wrote:
Hi Robert!
On 2019/03/05 11:35, Robert Haas wrote:
On Mon, Mar 4, 2019 at 5:38 AM Tatsuro Yamada
wrote:
=== Current design ===
CLUSTER command uses Index Scan or Seq Scan when scanning the heap.
Depending on which one is chosen, the command will pro
Fujita-san,
On 2019/03/06 15:10, Etsuro Fujita wrote:
> --- a/doc/src/sgml/ddl.sgml
> +++ b/doc/src/sgml/ddl.sgml
> @@ -3376,6 +3376,13 @@ ALTER TABLE measurement ATTACH PARTITION
> measurement_y2008m02
>
>
>
> +
> +
> + UPDATE row movement is not supported in the
On Mon, Mar 4, 2019 at 10:27 AM Masahiko Sawada wrote:
>
> On Sat, Mar 2, 2019 at 3:54 AM Robert Haas wrote:
> >
> > On Fri, Mar 1, 2019 at 12:19 AM Masahiko Sawada
> > wrote:
> > > > I wonder if we really want this behavior. Should a setting that
> > > > controls the degree of parallelism whe
On 2019/03/06 1:13, Robert Haas wrote:
On Tue, Mar 5, 2019 at 3:56 AM Tatsuro Yamada
wrote:
=== Discussion points ===
- Progress counter for "3. sorting tuples" phase
- Should we add pgstat_progress_update_param() in tuplesort.c like a
"trace_sort"?
Thanks to Peter
(2019/03/06 13:53), Amit Langote wrote:
On 2019/03/06 13:30, David Rowley wrote:
I think you missed my point. If there's no special support for "tuple
moving", as you say, then what help is it to tell the user "if the FDW
supports tuple routing"? The answer is, it's not any help. How would
(2019/03/06 13:18), Amit Langote wrote:
The main problem here is indeed that the limitation is not listed under
the partitioning limitations in ddl.sgml, where it's easier to notice than
in the UPDATE's page.
Agreed.
I've updated my patch to remove the release-11.sgml
changes.
Thanks for th
On Wed, Mar 6, 2019 at 2:46 PM Michael Paquier wrote:
>
> On Wed, Mar 06, 2019 at 11:45:01AM +0900, Masahiko Sawada wrote:
> > I realized that the tab completions for SKIP_LOCKED option of both
> > VACUUM and ANALYZE are missing. Attached patch adds them.
>
> Thanks Sawada-san, committed.
Thank y
Paul Ramsey writes:
>> On Mar 5, 2019, at 3:56 PM, Tom Lane wrote:
>> Then you're at least missing adequate tests for the 3-arg functions...
>> 3 args with the index column second will not work as this stands.
> Some of the operators are indifferent to order (&&, overlaps) and others are
> not
On Wed, Mar 06, 2019 at 11:45:01AM +0900, Masahiko Sawada wrote:
> I realized that the tab completions for SKIP_LOCKED option of both
> VACUUM and ANALYZE are missing. Attached patch adds them.
Thanks Sawada-san, committed.
--
Michael
signature.asc
Description: PGP signature
Imai-san,
Thanks for the review.
On 2019/03/06 11:09, Imai, Yoshikazu wrote:
> Here is the code review for previous v26 patches.
>
> [0002]
> In expand_inherited_rtentry():
>
> expand_inherited_rtentry()
> {
> ...
> + RelOptInfo *rel = NULL;
>
> can be declared at more later:
>
> if (ol
On Wed, 6 Mar 2019 11:27:38 +0900
Michael Paquier wrote:
> On Tue, Mar 05, 2019 at 07:55:22PM -0600, Karl O. Pinc wrote:
> > Attached: doc_base64_v4.patch
>
> Details about the "escape" mode are already available within the
> description of function "encode". Wouldn't we want to consolidate a
On 2019/03/06 13:30, David Rowley wrote:
> On Wed, 6 Mar 2019 at 17:20, Amit Langote
> wrote:
>>
>> On 2019/03/06 12:47, David Rowley wrote:
>>> It seems a bit light on detail to me. If I was a user I'd want to know
>>> what exactly the FDW needed to support this. Does it need a special
>>> parti
On Tue, 5 Mar 2019 at 19:08, Andres Freund wrote:
>
> On 2019-03-05 16:01:50 +1300, David Rowley wrote:
> > I'd suggest it's made to work the same way as ca4103025dfe26 made
> > tablespaces work.
>
> Hm, is that actually correct? Because as far as I can tell that doesn't
> have the necessary pg_d
On Wed, 6 Mar 2019 at 17:20, Amit Langote wrote:
>
> On 2019/03/06 12:47, David Rowley wrote:
> > It seems a bit light on detail to me. If I was a user I'd want to know
> > what exactly the FDW needed to support this. Does it need a special
> > partition move function? Looking at ExecFindPartitio
On Tue, Mar 5, 2019 at 8:01 PM Kyotaro HORIGUCHI
wrote:
>
> Hello, I have some other comments.
>
Thank you for the comment!
On Tue, Mar 5, 2019 at 8:01 PM Kyotaro HORIGUCHI
wrote:
>
>
> + nleft;/* item pointers we left */
>
> The name seems to be something other, a
On 2019/03/06 12:47, David Rowley wrote:
> On Wed, 6 Mar 2019 at 16:29, Etsuro Fujita
> wrote:
>> That means that rows can be moved from a local partition to a foreign
>> partition if the FDW supports it.
>
> It seems a bit light on detail to me. If I was a user I'd want to know
> what exactly t
Fujita-san,
On 2019/03/06 13:04, Etsuro Fujita wrote:
> (2019/03/06 11:34), Amit Langote wrote:
>> Ah, indeed. In the documentation fix patch I'd posted, I also made
>> changes to release-11.sgml to link to the limitations section. (I'm
>> attaching it here for your reference.)
>
> I'm not sure
Hi Jim,
Thanks for replying here.
On Wed, 6 Mar 2019 at 16:37, Jim Finnerty wrote:
>
> Actually, we're working hard to integrate the two approaches. I haven't had
> time since I returned to review your patch, but I understand that you were
> checking for strict predicates as part of the nullnes
Hello.
At Mon, 4 Mar 2019 03:03:51 +, "Ideriha, Takeshi"
wrote in
<4E72940DA2BF16479384A86D54D0988A6F44564E@G01JPEXMBKW04>
> Does this result show that hard-limit size option with memory accounting
> doesn't harm to usual users who disable hard limit size option?
Not sure, but 4% seems be
(2019/03/06 11:34), Amit Langote wrote:
Ah, indeed. In the documentation fix patch I'd posted, I also made
changes to release-11.sgml to link to the limitations section. (I'm
attaching it here for your reference.)
I'm not sure it's a good idea to make changes to the release notes like
that,
Stephen Frost writes:
> * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
>
>> Or maybe we avoid that, and you rename be-secure-gssapi.c to just
>> be-gssapi.c and also combine that with the contents of
>> be-gssapi-common.c.
>
> I don't know why we would need to, or want to, combine
>
On Wed, 6 Mar 2019 at 16:29, Etsuro Fujita wrote:
>
> (2019/03/06 11:06), David Rowley wrote:
> > I don't quite understand what a "foreign table to some other
> > partition" is meant to mean. Partitions don't have foreign tables,
> > they can only be one themselves.
>
> I think "foreign table" is
(2019/03/06 11:06), David Rowley wrote:
On Tue, 5 Mar 2019 at 03:01, Derek Hans wrote:
Based on a reply to reporting this as a bug, moving rows out of foreign
partitions is not yet implemented so this is behaving as expected. There's a
mention of this limitation in the Notes section of the Up
On Wed, Mar 6, 2019 at 4:07 PM Shawn Debnath wrote:
> On Wed, Mar 06, 2019 at 11:13:31AM +1300, Thomas Munro wrote:
> > So... can anyone tell us what happens on Windows?
> C:\Users\Shawn Debnath\Desktop>c:\Python27\python.exe tmunro-ssl-test.py
> --client
> Sending A...
> 2
> Sending B...
> [Err
On Wed, Mar 06, 2019 at 02:21:15PM +1300, Thomas Munro wrote:
> Here's some missing documentation.
The addition looks fine to me.
> Hmm, yeah. I wish these were alphabetised, I wish there was an
> automated warning about this, I wish these tranches were declared a
> better way that by adding cod
Hi,
I realized that the tab completions for SKIP_LOCKED option of both
VACUUM and ANALYZE are missing. Attached patch adds them.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
skip_locked.patch
Description: Binary data
Greetings,
On Tue, Mar 5, 2019 at 18:36 Michael Paquier wrote:
> On Tue, Mar 05, 2019 at 02:08:03PM +0100, Tomas Vondra wrote:
> > Based on quickly skimming that thread the main issue seems to be
> > deciding which files in the data directory are expected to have
> > checksums. Which is a valid
On Tue, Mar 05, 2019 at 02:08:03PM +0100, Tomas Vondra wrote:
> Based on quickly skimming that thread the main issue seems to be
> deciding which files in the data directory are expected to have
> checksums. Which is a valid issue, of course, but I was expecting
> something about partial read/write
Hi,
Thanks for looking!
On 2019-03-05 18:27:45 -0800, Ashwin Agrawal wrote:
> While playing with the tableam, usage of which starts with commit
> v12-0023-tableam-Introduce-and-use-begin-endscan-and-do-i.patch, should we
> check for NULL function pointer before actually calling the same and ERROR
Hi,
Thanks for looking!
On 2019-03-05 18:27:45 -0800, Ashwin Agrawal wrote:
> While playing with the tableam, usage of which starts with commit
> v12-0023-tableam-Introduce-and-use-begin-endscan-and-do-i.patch, should we
> check for NULL function pointer before actually calling the same and ERROR
On 2019/03/06 11:29, David Rowley wrote:
> On Wed, 6 Mar 2019 at 15:26, Amit Langote
> wrote:
>>
>>> I've tried to put all this right again in the attached. However, I was
>>> a bit unsure of what "but they can be moved into a foreign table if
>>> the foreign data wrapper supports it." is referri
On Wed, 6 Mar 2019 at 15:26, Amit Langote wrote:
>
> > I've tried to put all this right again in the attached. However, I was
> > a bit unsure of what "but they can be moved into a foreign table if
> > the foreign data wrapper supports it." is referring to. Copying Robert
> > and Etsuro as this wa
Hi,
While playing with the tableam, usage of which starts with commit
v12-0023-tableam-Introduce-and-use-begin-endscan-and-do-i.patch, should we
check for NULL function pointer before actually calling the same and ERROR
out instead as NOT_SUPPORTED or something on those lines.
Understand its kind
On Tue, Mar 05, 2019 at 07:55:22PM -0600, Karl O. Pinc wrote:
> Attached: doc_base64_v4.patch
Details about the "escape" mode are already available within the
description of function "encode". Wouldn't we want to consolidate a
description for all the modes at the same place, including some words
Hi David,
On 2019/03/06 11:06, David Rowley wrote:
> On Tue, 5 Mar 2019 at 03:01, Derek Hans wrote:
>> Based on a reply to reporting this as a bug, moving rows out of foreign
>> partitions is not yet implemented so this is behaving as expected. There's a
>> mention of this limitation in the Not
On Tue, Mar 05, 2019 at 12:47:54PM +, Chris Travers wrote:
> I tried installing a test extension into a temp schema. I found
> this was remarkably difficult to do because pg_temp did not work (I
> had to create a temporary table and then locate the actual table it
> was created in). While tha
On Wed, Mar 6, 2019 at 2:10 AM, Imai, Yoshikazu wrote:
> > and Imai-san's review. I haven't been able to pin down the bug (or
> > whatever) that makes throughput go down as the partition count
> > increases, when tested with a --enable-cassert build.
>
> I didn't investigate that problem, but the
Amit-san,
On Tue, Mar 5, 2019 at 10:24 AM, Amit Langote wrote:
> On 2019/03/05 9:50, Amit Langote wrote:
> > I'll post the updated patches after diagnosing what I'm suspecting a
> > memory over-allocation bug in one of the patches. If you configure
> > build with --enable-cassert, you'll see that
On Tue, 5 Mar 2019 at 03:01, Derek Hans wrote:
> Based on a reply to reporting this as a bug, moving rows out of foreign
> partitions is not yet implemented so this is behaving as expected. There's a
> mention of this limitation in the Notes section of the Update docs.
(Moving this discussion t
On Tue, Mar 05, 2019 at 02:10:01PM +0300, Nikita Glukhov wrote:
> I known about this volatility issues, but maybe I incorrectly understand what
> should be marked as volatile for pointer variables: the pointer itself and/or
> the memory referenced by it. I thought that only pointer needs to be mar
On 2019/03/06 0:57, Jesper Pedersen wrote:
> On 3/5/19 5:24 AM, Amit Langote wrote:
>> Attached an updated version. This incorporates fixes for both Jesper's
>> and Imai-san's review. I haven't been able to pin down the bug (or
>> whatever) that makes throughput go down as the partition count inc
Hi Fabien,
On Tue, 5 Mar 2019 23:02:26 +0100 (CET)
Fabien COELHO wrote:
> > Attached: doc_base64_v3.patch
>
> I'm ok with referencing the historical MIME RFC.
For the record, RFC 2045 is updated but not
yet obsolete. The updates don't invalidate
section 6.8.
> "RFC2045 section 6.8" -> "RFC
On Tue, Mar 5, 2019 at 8:04 PM David Rowley
wrote:
> Actually, I'm not sure it could work at all. It does not seem very
> safe to lookup a partition's parent without actually holding a lock on
> the partition and we can't lock the partition and then lock each
> parent in turn as that's the exact
> On Mar 5, 2019, at 3:56 PM, Tom Lane wrote:
>
> Paul Ramsey writes:
>> On Mar 5, 2019, at 3:26 PM, Tom Lane wrote:
>>> Hm, I think your addition of this bit is wrong:
>>>
>>> +/*
>>> +* Arguments were swapped to put the index value on the
>>> +
On Wed, Mar 6, 2019 at 2:18 PM Alvaro Herrera wrote:
> On 2019-Mar-05, Jeremy Schneider wrote:
> > It's possible I'm misreading this, but I'm thinking that commits
> > cc5f8136 and ab9e0e71 added a few tranches which we need to add to the docs.
> >
> > session_dsa, session_record_table, session_ty
On 2019-Mar-05, Jeremy Schneider wrote:
> It's possible I'm misreading this, but I'm thinking that commits
> cc5f8136 and ab9e0e71 added a few tranches which we need to add to the docs.
>
> session_dsa, session_record_table, session_typmod_table, and
> shared_tuplestore
>
> https://www.postgresq
Jerry,
On 2019-Mar-05, Jerry Jelinek wrote:
> Thanks again for your review. I went through your proposed patch diffs and
> applied most of them to my original changes. I did a few things slightly
> differently since I wanted to keep to to 80 columns for the source code,
> but I can revisit that i
On 2019-Mar-04, Robert Haas wrote:
> On Mon, Mar 4, 2019 at 5:38 AM Tatsuro Yamada
> wrote:
> > === Discussion points ===
> >
> > - Progress counter for "3. sorting tuples" phase
> > - Should we add pgstat_progress_update_param() in tuplesort.c like a
> >"trace_sort"?
> >T
On Wed, 6 Mar 2019 at 04:46, Tomas Vondra wrote:
>
> On 3/5/19 6:55 AM, David Rowley wrote:
> > The only way I can think to fix this is to just never lock partitions
> > at all, and if a lock is to be obtained on a partition, it must be
> > instead obtained on the top-level partitioned table. Tha
Hi all,
Here is my attempt to fix a 12-years old ltree bug (which is a todo item).
I see it's not backward-compatible, but in my understanding that's
what is documented. Previous behavior was inconsistent with
documentation (where single asterisk should match zero or more
labels).
http://archive
Here is Pavel's patch rebased to master branch, added the dropdb
--force option, a test case & documentation.
I'm willing to work on it if needed. What are possible bad things that
could happen here? Is the documentation clear enough?
Thanks.
On Tue, Dec 18, 2018 at 4:34 PM Marti Raudsepp wrot
On Wed, 6 Mar 2019 at 07:17, Robert Haas wrote:
>
> On Wed, Dec 19, 2018 at 5:08 PM David Rowley
> wrote:
> > With my idea for using live_parts, we'll process the partitions
> > looking for interleaved values on each query, after pruning takes
> > place. In this case, we'll see the partitions are
On Tue, Mar 5, 2019 at 3:46 AM David Steele wrote:
> I have marked this entry as targeting PG13 since it is too late to
> consider for PG12.
Sounds right. As Peter said himself, this patch is WIP, so it's too
soon to consider integrating it. This is also fairly evident from the
content of the p
On Wed, 6 Mar 2019 at 12:25, David Rowley wrote:
> That sounds fine. I'll take mine elsewhere since I didn't start this thread.
Moved to
https://www.postgresql.org/message-id/CAKJS1f82pqjqe3WT9_xREmXyG20aOkHc-XqkKZG_yMA7JVJ3Tw%40mail.gmail.com
--
David Rowley http://www.2ndQ
Paul Ramsey writes:
> On Mar 5, 2019, at 3:26 PM, Tom Lane wrote:
>> Hm, I think your addition of this bit is wrong:
>>
>> +/*
>> +* Arguments were swapped to put the index value on the
>> +* left, so we need the commutated operator for
Way back in [1] I proposed that we allow NOT IN subqueries to be
converted into an anti-join where the subquery cannot return any NULL
values. As Tom pointed out to me, I had neglected to consider that
the outer side producing NULLs can cause the anti-join plan to produce
incorrect results. The
> On Mar 5, 2019, at 3:26 PM, Tom Lane wrote:
>
> Paul Ramsey writes:
>> Thanks for the patch, I’ve applied and smoothed and taken your advice on
>> schema-qualified lookups as well.
>
> Hm, I think your addition of this bit is wrong:
>
> +/*
> +* Arg
Paul Ramsey writes:
> Thanks for the patch, I’ve applied and smoothed and taken your advice on
> schema-qualified lookups as well.
Hm, I think your addition of this bit is wrong:
+/*
+* Arguments were swapped to put the index value on the
+
On Wed, 6 Mar 2019 at 03:37, Tom Lane wrote:
>
> David Steele writes:
> > I'm not sure if I have an issue with competing patches on the same
> > thread. I've seen that before and it can lead to a good outcome. It
> > case, as you say, also lead to confusion.
>
> It's a bit of a shame that the c
On Wed, 6 Mar 2019 at 08:41, Sergei Kornilov wrote:
> In this case we need extra argument for ConstraintImpliedByRelConstraint for
> some caller-provided existConstraint, right? Along with Relation itself? Then
> I need make copy of existConstraint, append relation constraints and call
> predic
Thanks for chipping in on this.
On Wed, 6 Mar 2019 at 01:53, Tomas Vondra wrote:
> But on the other hand it feels a bit weird that we increase this one
> value and leave all the other (also very conservative) defaults alone.
Which others did you have in mind? Like work_mem, shared_buffers? If
s
Alvaro,
Thanks again for your review. I went through your proposed patch diffs and
applied most of them to my original changes. I did a few things slightly
differently since I wanted to keep to to 80 columns for the source code,
but I can revisit that if it is not an issue. I also cleaned up the
c
On 3/4/19 7:42 AM, Christoph Berg wrote:
> Re: Andrew Dunstan 2019-03-04
> <7cc6d2c1-bd87-9890-259d-36739c247...@2ndquadrant.com>
>> Looks good to me.
> +1.
>
OK, I think we have agreement on Tom's patch. Do we want to backpatch
it? It's a change in behaviour, but I find it hard to believe any
On 2/6/19 2:32 AM, Pavan Deolasee wrote:
> Hello,
>
> Currently either the table level option `toast_tuple_target` or the
> compile time default `TOAST_TUPLE_TARGET` is used to decide whether a
> new tuple should be compressed or not. While this works reasonably
> well for most situations, at tim
On 2019-03-05 17:14:55 -0500, Andrew Dunstan wrote:
> This patch is tiny, seems perfectly reasonable, and has plenty of
> support. I'm going to commit it shortly unless there are last minute
> objections.
+1
On 2/25/19 8:38 AM, David Rowley wrote:
> On Tue, 26 Feb 2019 at 02:06, Joe Conway wrote:
>> On 2/25/19 1:17 AM, Peter Geoghegan wrote:
>>> On Sun, Feb 24, 2019 at 9:42 PM David Rowley
>>> wrote:
The current default vacuum_cost_limit of 200 seems to be 15 years old
and was added in f4
On Wed, Mar 6, 2019 at 9:21 AM Tom Lane wrote:
> The bug #15598 report is more troublesome, as we don't have a strong
> reason to believe it's not common on Windows. However, I wonder whether
> we can really do anything at all about that one. If I understand what
> Andrew was hypothesizing in th
Hello Karl,
Attached: doc_base64_v3.patch
I'm ok with referencing the historical MIME RFC.
"RFC2045 section 6.8" -> "RFC 2045 Section 6.8"
you can link to the RFC directly with:
https://tools.ietf.org/html/rfc2045#section-6.8";>RFC 2045
Section 6.8
--
Fabien.
On Thu, Feb 28, 2019 at 3:27 PM Robert Haas wrote:
> I'm not currently aware of any remaining correctness issues with this
> code, although certainly there may be some. There has been a certain
> dearth of volunteers to review any of this. I do plan to poke at it a
> bit to see whether it has an
On Tue, Mar 5, 2019 at 12:24:14AM -0300, Alvaro Herrera wrote:
> On 2019-Mar-04, Bruce Momjian wrote:
>
> > On Thu, Feb 28, 2019 at 10:28:44AM +0300, Sergei Kornilov wrote:
> > > Hello
> > >
> > > postgresql.conf.sample was changed recently in REL_10_STABLE (commit
> > > ab1d9f066aee4f9b81abde6
-- Forwarded message -
From: Siarhei Siniak
Date: Tue, 5 Mar 2019 at 23:31
Subject: Re: [Issue] Can't recompile cube extension as PGXS, utils/float.h
is not installed
To: Tom Lane
>AFAICT, that file only exists in HEAD, not in any released branch, and
>it is installed during "ma
Thomas Munro writes:
> Bleugh. I think this OpenSSL package might just be buggy on ARM. On
> x86, apparently the same version of OpenSSL and all other details of
> the test the same, I can see that SSL_connect() returns <= 0
> (failure), and then we ask for that cert revoked message directly and
On Tue, Mar 5, 2019 at 3:37 AM Heikki Linnakangas wrote:
> I'm looking at the first patch in the series now. I'd suggest that you
> commit that very soon. It's useful on its own, and seems pretty much
> ready to be committed already. I don't think it will be much affected by
> whatever changes we
> On Mar 4, 2019, at 4:22 PM, Tom Lane wrote:
>
> Paul Ramsey writes:
>>> On Mar 4, 2019, at 2:52 PM, Tom Lane wrote:
>>> BTW, if you'd like me to review the code you added for this, I'd be happy
>>> to do so. I've never looked at PostGIS' innards, but probably I can make
>>> sense of the c
Hello, David!
> I've made a pass over v10. I think it's in pretty good shape, but I
> did end up changing a few small things.
Thank you! I merged your changes to new patch version.
> The only thing that I'm a bit unsure of is the tests. I've read the
> thread and I see the discussion above about
There already are solutions regarding this feature in Postgres
using "connection pooler" wording
see
pgpool: http://www.pgpool.net/mediawiki/index.php/Main_Page
pgbouncer: https://pgbouncer.github.io/
there are also discussions to include this as a core feature
https://www.postgresql.org/mes
On Wed, Mar 6, 2019 at 7:05 AM Thomas Munro wrote:
> On Wed, Mar 6, 2019 at 6:07 AM Tom Lane wrote:
> > Annoying. I'd be happier about writing code to fix this if I could
> > reproduce it :-(
>
> Hmm. Note that eelpout only started doing it with OpenSSL 1.1.1.
Bleugh. I think this OpenSSL pac
On 3/5/19, 1:22 AM, "Masahiko Sawada" wrote:
> On Tue, Mar 5, 2019 at 8:27 AM Bossart, Nathan wrote:
>> + VACUUM removes dead tuples and prunes HOT-updated
>> + tuples chain for live tuples on table. If the table has any dead tuple
>> + it removes them from both table and indexes f
We don't currently have any buildfarm animals running 32 bit mingw
builds for releases > 10. As part of my testing of msys 2 I thought I
would try its 32 bit compiler and got this regression diff on HEAD
cheers
andrew
diff -w -U3
C:/tools/msys64/home/Administrator/bf/root/HEAD/pgsql/src/tes
On Tue, Mar 5, 2019 at 12:59 PM Andres Freund wrote:
> Based on this mail I'm currently planning to simply forbid specifying
> USING for partitioned tables. Then we can argue about this later.
+1. I actually think that might be the right thing in the long-term,
but it undeniably avoids committin
On Wed, Dec 19, 2018 at 5:08 PM David Rowley
wrote:
> With my idea for using live_parts, we'll process the partitions
> looking for interleaved values on each query, after pruning takes
> place. In this case, we'll see the partitions are naturally ordered. I
> don't really foresee any issues with
On Wed, Mar 6, 2019 at 6:07 AM Tom Lane wrote:
> Thomas Munro writes:
> > You can see that poll() already knew the other end had closed the
> > socket. Since this is clearly timing... let's see, yeah, I can make
> > it fail every time by adding sleep(1) before the comment "Send the
> > startup p
On 2019-03-04 22:08:04 -0800, Andres Freund wrote:
> Hi,
>
> On 2019-03-05 16:01:50 +1300, David Rowley wrote:
> > On Tue, 5 Mar 2019 at 12:47, Andres Freund wrote:
> > > CREATE TABLE tableam_parted_heap2 (a text, b int) PARTITION BY list (a)
> > > USING heap2;
> > >
> > > SET default_table_acce
Peter Eisentraut wrote:
> Older ICU versions (<54) don't support all the locale customization
> options, so many of my new tests in collate.icu.utf8.sql will fail on
> older systems. What should we do about that? Have another extra test file?
Maybe stick to the old-style syntax for the
út 5. 3. 2019 v 15:35 odesílatel Tom Lane napsal:
> David Steele writes:
> > This thread has been very quiet for a month. I agree with Andres [1]
> > that we should push this to PG13.
>
> I think the main thing it's blocked on is disagreement on what the
> type name should be, which is kind of
On 2/28/19 4:27 PM, Alexander Kuzmenkov wrote:
On 2/18/19 03:20, Tom Lane wrote:
The dummy-relation stuff I referred to has now been merged, so there's
really no good reason not to revise the patch along that line.
I'll try to post the revised implementation soon.
I'll close this on March 8
Thomas Munro writes:
> You can see that poll() already knew the other end had closed the
> socket. Since this is clearly timing... let's see, yeah, I can make
> it fail every time by adding sleep(1) before the comment "Send the
> startup packet.". I assume that'll work on any Linux machine?
Gre
>
>
> I agree with Andres and Robert. This patch should be pushed to PG13.
>
> I'll do that on March 8 unless there is a compelling argument not to.
>
>
No objection. I'll continue to work on it, though.
Thomas Munro writes:
> +#include "fmgr.h"
> +#include "storage/block.h"
> +#include "storage/relfilenode.h"
> +#include "storage/smgr.h"
> +#include "storage/sync.h"
> Why do we need to include fmgr.h in md.h?
More generally, any massive increase in an include file's inclusions
is probably a sig
On Mon, Mar 4, 2019 at 6:27 PM Tomas Vondra
wrote:
> 11) Wording of some of the error messages in the execute methods seems a
> bit odd. For example executeNumericItemMethod may complain that it
>
> ... is applied to not a numeric value
>
> but perhaps a more natural wording would be
>
>
On Wed, Mar 6, 2019 at 5:07 AM Shawn Debnath wrote:
> Confirmed. Patch shows 8900 ms vs 192 ms on master for the insert test.
> Interesting! It's reproducible so should be able to figure out what's
> going on. The only thing we do in ForwardSyncRequest() is split up the 8
> bits into 2x4 bits and
On Wed, Mar 6, 2019 at 3:33 AM Tom Lane wrote:
> Thomas Munro writes:
> > Disappointingly, that turned out to be just because 10 and earlier
> > didn't care what the error message said.
>
> That is, you can reproduce the failure on old branches? That lets
> out a half-theory I'd had, which was t
On Tue, Mar 5, 2019 at 3:56 AM Tatsuro Yamada
wrote:
> >> === Discussion points ===
> >>
> >>- Progress counter for "3. sorting tuples" phase
> >> - Should we add pgstat_progress_update_param() in tuplesort.c like a
> >> "trace_sort"?
> >> Thanks to Peter Geoghegan for th
On Tue, Mar 5, 2019 at 3:00 AM Etsuro Fujita
wrote:
> apply_projection_to_path() not only jams the given tlist into the
> existing path but updates its tlist eval costs appropriately except for
> the cases of Gather and GatherMerge:
I had forgotten that detail, but I don't think it changes the ba
On 3/5/19 5:24 AM, Amit Langote wrote:
Attached an updated version. This incorporates fixes for both Jesper's
and Imai-san's review. I haven't been able to pin down the bug (or
whatever) that makes throughput go down as the partition count increases,
when tested with a --enable-cassert build.
1 - 100 of 155 matches
Mail list logo
