On 25 March 2018 at 18:28, David Rowley wrote:
> The attached delta applies on top of v39 plus delta1.
Sorry, the attached should do this. Ignore the last attachment.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
v39
On 24 March 2018 at 16:42, David Rowley wrote:
> I've done this in the attached patch against v39.
>
> I also renamed argvalues to argexprs, since they're not values. The
> PartClauseInfo could probably do with the same change too, but I
> didn't touch it.
The attached goes a little further and
Tomas Vondra writes:
> FWIW this is where the view listing dictionaries loaded into shared
> memory would be helpful - you'd at least know there's a dictionary,
> wasting memory.
Well, that's only because we failed to make the implementation transparent
:-(. But it's not unlikely that an mmap-ba
On 03/25/2018 06:18 AM, Tom Lane wrote:
> Tomas Vondra writes:
>> On 3/24/18 9:56 PM, Tom Lane wrote:
>>> Also, the scheme for releasing the dictionary DSM during
>>> RemoveTSDictionaryById is uncertain and full of race conditions:
>>> the DROP might roll back later, or someone might come along
Tomas Vondra writes:
> On 3/24/18 9:56 PM, Tom Lane wrote:
>> Also, the scheme for releasing the dictionary DSM during
>> RemoveTSDictionaryById is uncertain and full of race conditions:
>> the DROP might roll back later, or someone might come along and
>> start using the dictionary (causing a fre
On 3/24/18 9:56 PM, Tom Lane wrote:
> Arthur Zakirov writes:
>> [ v10 patch versions ]
>
> I took a quick look through this. I agree with the comments about
> mmap-ability not being something we should insist on now, and maybe
> not ever. However, in order to keep our options open, it seems l
Stephen Frost writes:
> I don't completely buy off on the argument that having these #define's
> would make it easier for forks (we've had quite a few folks fork PG, but
> how many of them have actually changed "base"?) and I'm on the fence
> about if these will make our lives simpler down the roa
Andres Freund writes:
> On 2018-02-10 18:37:17 +, Tom Lane wrote:
> CALL ptest1(substring(random()::text, 1, 1)); -- ok, volatile arg
> At first I was gosh darned confused, this really didn't seem likely to
> be an LLVM induced failure. And it turns out it isn't. If the value
> returned by
Thomas Munro wrote:
> typos
A dead line.
--
Thomas Munro
http://www.enterprisedb.com
0003-Remove-dead-code.patch
Description: Binary data
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Fri, Mar 23, 2018 at 01:38:38AM +0900, Fujii Masao wrote:
> > Personally it looks very intrusive, so I'm feeling inclined to push
> > the changes without that refactoring.
I've been reading over the first couple of posted patches and
On Sun, Mar 25, 2018 at 3:55 AM, Tom Lane wrote:
> I noticed that doing pgindent with the current typedefs list available
> from the buildfarm caused a lot of havoc in what had been stable code.
> Looking into the reasons, it seems that:
>
> (1) "bool" is no longer listed as a typedef name (probab
From: Robert Haas
I also said it would be worse on spinning disks.
Also, Yoshimi Ichiyanagi did not find it to be true even on NVRAM.
Yes, let me withdraw this proposal. I couldn't see any performance
difference even with ext4 volume on a PCIe flash memory.
Regards
MauMau
On Fri, Mar 23, 2018 at 8:27 PM, Pavan Deolasee
wrote:
>>
>>
>> I would probably just have a few regression lines that should be sure
>> to exercise the code path and leave it at that.
>>
>
> I changed the regression tests to include a few more scenarios, basically
> using multi-column indexes in
Here is a v14, after yet another rebase, and some comments added to answer
your new comments.
Attached v15 is a simple rebase after Teodor push of new functions &
operators in pgbench.
Patch v16 is a rebase.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sg
On Sat, Mar 24, 2018 at 12:39 PM, Alexander Korotkov
wrote:
> +1, putting "nattributes" to argument of index_truncate_tuple() would
> make this function way more universal.
Great.
> Originally that code was written by Teodor, but I also put my hands there.
> In GIN entry tree, item pointers are
On 2018-03-24 14:51:32 -0700, Peter Geoghegan wrote:
> On Sat, Mar 24, 2018 at 1:36 PM, Andres Freund wrote:
> > I've attached the difference between a objdump typedefs list roughly
> > equivalent to what the buildfarm uses. There's no difference when not
> > using llvm.
> >
> > I'm a bit uncomfor
On Sat, Mar 24, 2018 at 1:36 PM, Andres Freund wrote:
> I've attached the difference between a objdump typedefs list roughly
> equivalent to what the buildfarm uses. There's no difference when not
> using llvm.
>
> I'm a bit uncomfortable relying --dwarf-depth=3, with 3 being determined
> purely e
On 2018-02-10 18:37:17 +, Tom Lane wrote:
> Avoid premature free of pass-by-reference CALL arguments.
> src/test/regress/expected/create_procedure.out | 12 +++
> src/test/regress/sql/create_procedure.sql | 4 +++-
> 3 files changed, 33 insertions(+), 11 deletions(-)
There's a re
Arthur Zakirov writes:
> [ v10 patch versions ]
I took a quick look through this. I agree with the comments about
mmap-ability not being something we should insist on now, and maybe
not ever. However, in order to keep our options open, it seems like
we should minimize the amount of API we expos
On 2018-03-24 10:41:40 -0700, Andres Freund wrote:
> I'm about to head out, but afterwards I'm going to check what the
> typedefs collected actually are when LLVM is enabled.
It's indeed from llvm:
<3><5201>: Abbrev Number: 4 (DW_TAG_typedef)
<5202> DW_AT_name: (indirect string, of
On 2018-02-06 15:43:29 -0500, Tom Lane wrote:
> Andres Freund writes:
> > We've several callers to load_external_function() that do not use the
> > returned value as a PGFunction. I'd vote for changing the return type to
> > void * and have fmgr.c cast it to PGFunction after verifying the
> > func
On Sat, Mar 24, 2018 at 5:21 AM, Peter Geoghegan wrote:
> On Thu, Mar 22, 2018 at 8:23 AM, Alexander Korotkov
> wrote:
> >> * There is minor formatting issue in this part of code. Some spaces
> need
> >> to be replaced with tabs.
> >> +IndexTuple
> >> +index_truncate_tuple(Relation idxrel, Inde
Claudio Freire writes:
> [ 0001-Vacuum-Update-FSM-more-frequently-v9.patch ]
I hadn't paid any attention to this patch previously, so maybe I'm
missing something ... but this sure seems like a very bizarre approach
to the problem. If the idea is to fix the FSM's upper levels after
vacuuming a kn
Hello hackers,
I’d like to propose the implementation of new wire protocol using http2
framing.
It appears to me that http2 solves many of the issues on the TODO list under
“Wire Protocol Changes / v4 Protocol,“ without any obvious downsides.
The implementation I have in mind has zero impa
On Sat, Mar 24, 2018 at 5:27 AM, Robert Haas wrote:
> If it's possible to identify the two OIDs that are supposed to match
> and cross-check that the OIDs are the same, then we could just bomb
> out with an error if they aren't. That's not lovely, and is basically
> a hack, but it's possible that
Hi,
On 2018-03-24 13:34:45 -0400, Tom Lane wrote:
> That was my first thought as well, since this seems to have changed
> quite recently. I don't think it's a bad idea to be collecting typedefs
> from something that compiles that code, because otherwise our own
> typedefs in that area won't be kn
Andres Freund writes:
> On 2018-03-24 13:25:34 -0400, Tom Lane wrote:
>> (2) "abs", "boolean", "iterator", "other", "pointer", "reference",
>> "string", and "type" all now are listed as typedef names.
>>
>> It's probably okay to treat "boolean" as a typedef, but all those others
>> are complete d
Hi,
On 2018-03-24 13:25:34 -0400, Tom Lane wrote:
> (2) "abs", "boolean", "iterator", "other", "pointer", "reference",
> "string", and "type" all now are listed as typedef names.
>
> It's probably okay to treat "boolean" as a typedef, but all those others
> are complete disasters. Anyone know wh
I noticed that doing pgindent with the current typedefs list available
from the buildfarm caused a lot of havoc in what had been stable code.
Looking into the reasons, it seems that:
(1) "bool" is no longer listed as a typedef name (probably because
stdbool.h makes it a macro instead);
(2) "abs",
On Fri, Mar 23, 2018 at 11:52 PM, Pavan Deolasee
wrote:
> A quick gdb tracing shows that the CTE itself is assigned plan_id 1 and the
> SubPlan then gets plan_id 2. I can investigate further, but given that we
> see a similar behaviour with regular UPDATE, I don't think it's worth.
Clearly I jump
Hi,
Am Freitag, den 23.03.2018, 17:43 +0100 schrieb Michael Banck:
> Am Freitag, den 23.03.2018, 10:54 -0400 schrieb David Steele:
> > In my experience actual block errors are relatively rare, so there
> > aren't likely to be more than a few in a file. More common are
> > overwritten or transpose
Kapil Sharma writes:
> Is it possible to run installcheck (pg_regress) tests from a remote host ?
I think if you set PGHOST and other relevant libpq environment variables,
an installcheck run will connect where they specify. The hard part would
be making sure that (a) your test files match the r
On 3/22/18 11:50, Tomas Vondra wrote:
> 1) plpgsql.sgml
>
> The new paragraph talks about "intervening command" - I've been unsure
> what that refers too, until I read the comment for ExecutCallStmt(),
> which explains this as CALL -> SELECT -> CALL. Perhaps we should add
> that to the sgml docs t
On Sat, Mar 24, 2018 at 12:37:21PM +, Simon Riggs wrote:
> If you have anything further to say, make it a formal complaint
> offlist so we can discuss engineering here.
Commit fest operations and patch reviews concern the community. There
is always something to learn for other people followin
On Sat, Mar 24, 2018 at 01:49:28AM +1100, Haribabu Kommi wrote:
> Here I attached the updated patch that returns either the connected
> host/hostaddr
> or NULL in case if the connection is not established.
>
> I removed the returning default host details, because the default host
> details are als
On Sat, Mar 24, 2018 at 8:41 AM, Robert Haas wrote:
> On Fri, Mar 23, 2018 at 12:12 AM, Amit Kapila wrote:
>> Yeah, sometimes that kind of stuff change performance characteristics,
>> but I think what is going on here is that create_projection_plan is
>> causing the lower node to build physical t
2018-03-24 10:06 GMT+01:00 Fabien COELHO :
>
> Hello Pavel,
>
> I'm suggesting to add \csv which would behave like \H to toggle CSV
mode so as to improve this situation, with a caveat which is that
toggling back \csv would have forgotted the previous settings (just
l
On 24 March 2018 at 12:19, Robert Haas wrote:
> On Sat, Mar 24, 2018 at 8:11 AM, Simon Riggs wrote:
>> On 24 March 2018 at 11:58, Robert Haas wrote:
>>> On Sat, Mar 24, 2018 at 7:42 AM, Simon Riggs wrote:
I suggest we focus on the engineering. I've not discussed this patch
with Pavan
On Sat, Mar 24, 2018 at 5:28 PM, Robert Haas wrote:
>
> This is a patch about which multiple people have expressed concerns.
> You're trying to jam a heavily redesigned version in at the last
> minute without adequate review. Please don't do that.
>
>
TBH this is not a heavily redesigned version
On Sat, Mar 24, 2018 at 8:16 AM, Robert Haas wrote:
> On Thu, Mar 22, 2018 at 7:13 PM, Peter Geoghegan wrote:
>> While I think this this particular HINT buglet is pretty harmless, I
>> continue to be concerned about the unintended consequences of having
>> multiple RTEs for MERGE's target table.
On 24 March 2018 at 12:16, Robert Haas wrote:
> On Thu, Mar 22, 2018 at 7:13 PM, Peter Geoghegan wrote:
>> While I think this this particular HINT buglet is pretty harmless, I
>> continue to be concerned about the unintended consequences of having
>> multiple RTEs for MERGE's target table. Each R
On Sat, Mar 24, 2018 at 8:11 AM, Simon Riggs wrote:
> On 24 March 2018 at 11:58, Robert Haas wrote:
>> On Sat, Mar 24, 2018 at 7:42 AM, Simon Riggs wrote:
>>> I suggest we focus on the engineering. I've not discussed this patch
>>> with Pavan offline.
>>
>> Well then proposing to commit moments
On Thu, Mar 22, 2018 at 7:13 PM, Peter Geoghegan wrote:
> While I think this this particular HINT buglet is pretty harmless, I
> continue to be concerned about the unintended consequences of having
> multiple RTEs for MERGE's target table. Each RTE comes from a
> different lookup path -- the first
On 24 March 2018 at 11:58, Robert Haas wrote:
> On Sat, Mar 24, 2018 at 7:42 AM, Simon Riggs wrote:
>> I suggest we focus on the engineering. I've not discussed this patch
>> with Pavan offline.
>
> Well then proposing to commit moments after it's been posted is
> ridiculous. That's exactly the
On Sat, Mar 24, 2018 at 7:42 AM, Simon Riggs wrote:
> I suggest we focus on the engineering. I've not discussed this patch
> with Pavan offline.
Well then proposing to commit moments after it's been posted is
ridiculous. That's exactly the opposite of "focusing on the
engineering".
This is a pa
I suggest we focus on the engineering. I've not discussed this patch
with Pavan offline.
On 23 March 2018 at 23:32, Michael Paquier wrote:
> On Fri, Mar 23, 2018 at 11:06:48AM +, Simon Riggs wrote:
>> Your assumption that I would commit a new patch that was 29 mins old
>> is frankly pretty ri
Hi Andres,
I spotted a couple of typos and some very minor coding details -- see
please see attached.
--
Thomas Munro
http://www.enterprisedb.com
0001-Correct-some-minor-typos-in-the-new-JIT-code.patch
Description: Binary data
0002-Minor-code-cleanup-for-llvmjit_wrap.cpp.patch
Description: B
While investigating moving pgbench expressions to fe_utils so that they can
be shared with psql (\if ..., \let ?), I figure out that psql's \if has a
syntax to test whether a variable exists, which is not yet available to
pgbench.
This patch adds the same syntax to pgbench expression so that
Patch isn't applyed cleanly anymore.
Indeed. Here is a rebase. All pgbench patches conflict about test cases.
Patch v12, yet another rebase.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index d52d324..41d9030 100644
--- a/doc/src/sgml/ref/pgbench.sgml
Hello Pavel,
I'm suggesting to add \csv which would behave like \H to toggle CSV
mode so as to improve this situation, with a caveat which is that
toggling back \csv would have forgotted the previous settings (just
like \H does, though, so would for instance reset to aligned wit
minor fix
>
>
another fix in help
Pavel
postgres=# \f
Field separator is "".
postgres=# \pset format csv
Output format is csv.
postgres=# \f
Field separator is ",".
postgres=# \pset format unaligned
Output format is unaligned.
postgres=# \f
Field separator is "|".
postgres=# \f ;
Field separator
On Sat, Mar 24, 2018 at 01:02:47AM -0700, Kapil Sharma wrote:
> Is it possible to run installcheck (pg_regress) tests from a remote
> host?
You can use EXTRA_REGRESS_OPTS to pass a custom set of options to
pg_regress, say:
EXTRA_REGRESS_OPTS='--host=remote_ip' make installcheck
You can use as well
minor fix
>
all is working now
[pavel@nemesis postgresql]$ psql --csv -F ';' -c "table foo" postgres
a;b;c
3;4;Nazdar
3;4;Nazdar
[pavel@nemesis postgresql]$ psql -F ';' --csv -c "table foo" postgres
a;b;c
3;4;Nazdar
3;4;Nazdar
[pavel@nemesis postgresql]$ psql --csv -c "table foo" postgres
a,
2018-03-24 8:24 GMT+01:00 Pavel Stehule :
>
>
> 2018-03-24 8:15 GMT+01:00 Fabien COELHO :
>
>>
>> Hello Pavel,
>>
>> The patch adds a simple way to generate csv output from "psql" queries,
much simpler than playing around with COPY or \copy. It allows to
generate
a clean CSV dump fr
Hi,
Is it possible to run installcheck (pg_regress) tests from a remote host ?
Thanks,
Kapil.
2018-03-24 8:15 GMT+01:00 Fabien COELHO :
>
> Hello Pavel,
>
> The patch adds a simple way to generate csv output from "psql" queries,
>>> much simpler than playing around with COPY or \copy. It allows to
>>> generate
>>> a clean CSV dump from something as short as:
>>>
>>> sh> psql --csv -c 'TA
Hello Pavel,
The patch adds a simple way to generate csv output from "psql" queries,
much simpler than playing around with COPY or \copy. It allows to generate
a clean CSV dump from something as short as:
sh> psql --csv -c 'TABLE foo' > foo.csv
Documentation is clear.
Test cover a signific
57 matches
Mail list logo
