Hello, thank you for the new version.
At Fri, 4 Jan 2019 00:25:57 +0100, Peter Eisentraut
wrote in
<3f8a7a73-cebe-016f-49e3-853733f8b...@2ndquadrant.com>
> Updated patches for some merge conflicts
0001: Seems perfect to me.
0002:
The test 54-56 of 001_ssltest.pl failed, which succeeded
Sorry, I left a garbage.
At Mon, 28 Jan 2019 17:14:00 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190128.171400.111796002.horiguchi.kyot...@lab.ntt.co.jp>
> Hello, thank you for the new version.
>
> At Fri, 4 Jan 2019 00:25:57 +0100, Peter Eisentraut
> wrote in
>
On Sun, Jan 27, 2019 at 1:59 PM Michael Paquier wrote:
> On Sat, Jan 26, 2019 at 01:45:46PM +0100, Magnus Hagander wrote:
> > One workaround you could perhaps look at here is to run pg_basebackup
> > with --no-sync. That way there will be no fsyncs issued while running.
> You
> > will then of
Hi David,
On 2019/01/28 13:18, David Rowley wrote:
> On Sat, 12 Jan 2019 at 02:00, Amit Langote wrote:
>> On 2019/01/09 9:09, David Rowley wrote:
>>> postgres=# update parent set c = c where a = 333;
>>> server closed the connection unexpectedly
>>> This probably means the server
At Wed, 26 Dec 2018 12:59:32 -0500, Tom Lane wrote in
<32289.1545847...@sss.pgh.pa.us>
> Kyotaro HORIGUCHI writes:
> > I found that in the documentation thanks to a notification
> > off-list. And after some reconfirmation, what I want to fix is
> > only a few lines of comment in
On Mon, Jan 28, 2019 at 8:08 PM Michael Paquier wrote:
> On Mon, Jan 28, 2019 at 12:28:30AM -0500, Tom Lane wrote:
> > Thomas Munro writes:
> >> That's ... annoying. I wish indent wouldn't do that, because it means
> >> that my declarations get moved around every time I write code.
> >
> > If
Michael Paquier wrote:
> In src/bin/psql/copy.c, handleCopyIn():
>
> /*
> * This code erroneously assumes '\.' on a line alone
> * inside a quoted CSV string terminates the \copy.
> *
> http://www.postgresql.org/message-id/e1tdnvq-0001ju...@wrigleys.postgresql.org
> */
> if (strcmp(buf,
Hi,
On 1/27/19 7:50 PM, Jamison, Kirk wrote:
There were also helpful comments from the developers above,
pointing it to the right direction.
In addition to Peter's comment, quoting "...if you want to do this
as fast as possible, don't use this script. That comment could be
enhanced to suggest
Since the LLVM stuff went in, src/tools/pginclude/cpluspluscheck
fails on my main devel machine, because
In file included from /tmp/cpluspluscheck.jobsM6/test.cpp:3:
./src/include/jit/llvmjit_emit.h:13:25: error: llvm-c/Core.h: No such file or
directory
and then there's a bunch of ensuing
Tom Lane wrote:
> A variant that might or might not be safer is "\g insist on you putting a mark there that shows you intended to read.
>
> Also, not quite clear what we'd do about copy-from-program.
> I think "\g |foo" is definitely confusing for that. "\g foo|"
> would be better if it
On 1/28/19 1:22 AM, Alexander Korotkov wrote:
> On Sun, Jan 27, 2019 at 1:50 PM Alexander Korotkov
> wrote:
>> On Sat, Jan 26, 2019 at 4:27 AM Alexander Korotkov
>> wrote:
>>>
>>> On Wed, Jan 23, 2019 at 8:01 AM Alexander Korotkov
>>> wrote:
Finally, I'm going to commit this if no
> On Sun, Jan 20, 2019 at 6:17 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Fri, Jan 18, 2019 at 11:22 AM Amit Khandekar
> > wrote:
> >
> > I believe you are going to add a new regression testcase for the change ?
>
> Yep.
So, here are these two patches for pg_dump/psql with a few
In the pluggable-storage discussion, there was some talk of renaming
nodes/relation.h to avoid confusion with the new access/relation.h
header. I think this is a fine idea, not only because of that conflict
but because "relation.h" has never made a lot of sense as the file's
name.
After a bit of
Tom Lane wrote:
> OK. I fixed the error-cleanup issue and pushed it.
>
> The patch applied cleanly back to 9.5, but the code for \g is a good
> bit different in 9.4. I didn't have the interest to try to make the
> patch work with that, so I just left 9.4 alone.
Thanks!
Now as far as
On Tue, Jan 29, 2019 at 12:18 AM Tom Lane wrote:
> In the pluggable-storage discussion, there was some talk of renaming
> nodes/relation.h to avoid confusion with the new access/relation.h
> header. I think this is a fine idea, not only because of that conflict
> but because "relation.h" has
On Fri, Jan 25, 2019 at 4:18 PM Alvaro Herrera wrote:
> Right, the planner/executor "disconnect" is one of the challenges, and
> why I was trying to keep the old copy of the PartitionDesc around
> instead of building updated ones as needed.
I agree that would be simpler, but I just don't see how
> "Amit" == Amit Kapila writes:
Amit> All of these seems to run with fsync=off. Is it possible that
Amit> vacuum has updated FSM, but the same is not synced to disk and
Amit> when we try to read it, we didn't get the required page?
No.
fsync never affects what programs see while the
On 28/01/2019 09:14, Kyotaro HORIGUCHI wrote:
> 0002:
>
> The test 54-56 of 001_ssltest.pl failed, which succeeded before
> applying 0002. Seems to need to use another user.
>
> # Failed test 'pg_stat_ssl view without client certificate: no stderr'
> # at t/001_ssltests.pl line 313.
> #
Tom Lane wrote:
> > Now as far as I can see, there is nothing that \copy to file or program
> > can do that COPY TO STDOUT cannot do.
>
> I don't think there's a way to get the effect of "\copy to pstdout"
> (which, IIRC without any caffeine, means write to psql's stdout regardless
> of
"Daniel Verite" writes:
> Now as far as I can see, there is nothing that \copy to file or program
> can do that COPY TO STDOUT cannot do.
I don't think there's a way to get the effect of "\copy to pstdout"
(which, IIRC without any caffeine, means write to psql's stdout regardless
of where
On 09/01/2019 02:47, Peter Geoghegan wrote:
On Fri, Dec 28, 2018 at 3:32 PM Peter Geoghegan wrote:
On Fri, Dec 28, 2018 at 3:20 PM Heikki Linnakangas wrote:
I'm envisioning that you have an array, with one element for each item
on the page (including the tuple we're inserting, which isn't
"Daniel Verite" writes:
> Tom Lane wrote:
>> A variant that might or might not be safer is "\g > insist on you putting a mark there that shows you intended to read.
> I haven't written any patch yet, but I was thinking of submitting
> something like that, with the addition of "\g >foo" as
On Mon, Jan 28, 2019, at 10:25, Michael Paquier wrote:
> On Mon, Jan 28, 2019 at 09:05:26AM +0100, Magnus Hagander wrote:
> > And for plain format, we'd do the same -- sync after each file segment, and
> > then a final one of the directory when done, right?
>
> Well, the code is doing a double
On Sunday, January 13, 2019 4:57:48 PM EST Tom Lane wrote:
> I also wonder why we'd allow RECORD but not RECORDARRAY.
That's by omission. There's no reason to refuse RECORDARRAY here for
the same reason why RECORD is accepted.
> More generally, why not any polymorphic type? [...] the
> fact
Robert Haas writes:
> On Sat, Jan 26, 2019 at 12:35 PM Tom Lane wrote:
>> Attached is an 0004 that makes a stab at providing some intelligence
>> for unnest() and the integer cases of generate_series().
> That looks awesome.
> I'm somewhat dubious about whole API. It's basically -- if you
On Sun, Jan 27, 2019 at 2:28 AM Noah Misch wrote:
> > Does this also implicitly mean we've just agreed to push back the
> > retirement of the @postgresql.org aliases for the lists until v11 is
> > EOL..?
> >
> > I can understand the concern around translators and back-patching and
> > such, but I
Thank you very much for reviewing the patch!
> 28 янв. 2019 г., в 12:15, Andreas Karlsson написал(а):
>
> = Code
>
> * Have some minor style issues like that there should be spaces around || (in
> gistcanreturn()) and ? and : (in gistFormTuple()).
Fixed.
>
> * I do not see any need for
Stephen Frost writes:
>> On Sun, Jan 27, 2019 at 2:28 AM Noah Misch wrote:
>>> What are those blocked infrastructure improvements?
> The specific improvements we're talking about are DKIM/DMARC/SPF, which
> is becoming more and more important to making sure that the email from
> our lists can
On Mon, Jan 28, 2019 at 7:26 PM Tom Lane wrote:
> Stephen Frost writes:
> >> On Sun, Jan 27, 2019 at 2:28 AM Noah Misch wrote:
> >>> What are those blocked infrastructure improvements?
>
> > The specific improvements we're talking about are DKIM/DMARC/SPF, which
> > is becoming more and more
On 1/28/19 11:30 AM, Fabrízio de Royes Mello wrote:
IMHO you should use long option name '--jobs' like others.
Thanks for your feedback !
Done, and v4 attached.
Best regards,
Jesper
>From 142b4723f433f39d0eed2ced4beccc3721451103 Mon Sep 17 00:00:00 2001
From: jesperpedersen
Date: Fri, 21
On Sat, Jan 26, 2019 at 12:35 PM Tom Lane wrote:
> Attached is an 0004 that makes a stab at providing some intelligence
> for unnest() and the integer cases of generate_series().
That looks awesome.
I'm somewhat dubious about whole API. It's basically -- if you have a
problem and a PhD in
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Mon, Jan 28, 2019 at 7:26 PM Tom Lane wrote:
>
> > Stephen Frost writes:
> > >> On Sun, Jan 27, 2019 at 2:28 AM Noah Misch wrote:
> > >>> What are those blocked infrastructure improvements?
> >
> > > The specific improvements
On Mon, Jan 28, 2019 at 1:15 PM Jesper Pedersen
wrote:
>
> Done.
>
> Attached is v3.
>
IMHO you should use long option name '--jobs' like others.
Regards,
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e
On Mon, Jan 28, 2019 at 10:18 AM Tom Lane wrote:
> In the pluggable-storage discussion, there was some talk of renaming
> nodes/relation.h to avoid confusion with the new access/relation.h
> header. I think this is a fine idea, not only because of that conflict
> but because "relation.h" has
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sun, Jan 27, 2019 at 2:28 AM Noah Misch wrote:
> > > Does this also implicitly mean we've just agreed to push back the
> > > retirement of the @postgresql.org aliases for the lists until v11 is
> > > EOL..?
> > >
> > > I can understand
Hi,
On 2019-01-28 15:17:19 -0500, Tom Lane wrote:
> In <6044.1548524...@sss.pgh.pa.us> I worried about how much planner
> stuff that patch might end up dragging into files that contain
> planner support functions, and suggested that we could refactor the
> planner's header files to reduce the
On Mon, Jan 28, 2019 at 3:17 PM Tom Lane wrote:
> I'm really unhappy that force_parallel_mode and
> parallel_leader_participation are being treated as planner GUCs.
> They are not that, IMO, because they also affect the behavior of
> the executor, cf HandleParallelMessage, ExecGather,
Andres Freund writes:
> On 2019-01-28 15:50:22 -0500, Tom Lane wrote:
>> Andres Freund writes:
>>> Ugh, isn't it nicer to just use the underlying struct type instead of
>>> that?
>> No, because that'd mean that anyplace relying on optimizer.h would also
>> have to write "struct PlannerInfo"
On 2019-01-22 11:42:35 -0800, Andres Freund wrote:
> Hi,
>
> On 2019-01-22 11:08:40 -0800, Donald Dong wrote:
> > In the standard_planner, we set the proper JIT flags on the resulting
> > PlannedStmt node. We also offered a planer hook so extensions can
> > add customized planners. The JIT flags
Hi,
On 2019-01-28 14:10:55 -0800, Andres Freund wrote:
> So, I'd pushed the latest version. And longfin came back with an
> interesting error:
>
> ERROR: page 135 of relation "pg_class" should be empty but is not
>
> The only way I can currently imagine this happening is that there's a
>
On Mon, Jan 28, 2019 at 12:10 PM Amit Kapila wrote:
>
> On Mon, Jan 28, 2019 at 10:03 AM John Naylor
> wrote:
> >
> 1.
> @@ -26,7 +26,7 @@
> pg_relation_size('fsm_check_size', 'fsm') AS fsm_size;
> heap_size | fsm_size
> ---+--
> - 24576 |0
> + 32768 |
> Otherwise "\g -" looks good as a portable solution.
+1
Robert Haas writes:
> However, generally we have not had great luck with just sticking
> keywords in there (cf. VACUUM, ANALYZE, EXPLAIN, COPY) which is why I
> suggested using a flexible syntax with parenthesized options.
Fair, except that as you then proceed to point out, that does not work
Hi,
On 2019-01-28 15:50:22 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-01-28 15:17:19 -0500, Tom Lane wrote:
> >> Since I was intentionally trying to limit what optimizer.h pulls in,
> >> and in particular not let it include relation.h, I needed an opaque
> >> typedef for
Hi,
On 2019-01-15 17:35:21 -0500, Tom Lane wrote:
> Andres Freund writes:
> >> Looking at the surrounding code made me wonder about the wisdom of
> >> entering empty pages as all-visible and all-frozen into the VM. That'll
> >> mean we'll never re-discover them on a primary, after promotion.
On Fri, Jan 25, 2019 at 01:01:22PM +0100, Daniel Verite wrote:
> Bruce Momjian wrote:
>
> > but I am able to see the failure using STDIN:
> >
> > COPY test FROM STDIN CSV;
> > Enter data to be copied followed by a newline.
> > End with a backslash and a period on a
Peter Eisentraut writes:
> On 28/01/2019 21:35, Tom Lane wrote:
>> Conceivably we could make it work without the parens:
>> ...
> Or put it at the end?
> WITH ctename AS ( query ) MATERIALIZED
Yeah, I thought about that too, but it doesn't seem like an improvement.
If the query is very long
Andres Freund writes:
> On 2019-01-28 13:02:11 -0800, Andres Freund wrote:
>> It's not required by C99, it however is required by C11. But a lot of
>> compilers have allowed it as an extension for a long time (like before
>> C99), unless suppressed by some option.
> Hm, it's only in gcc 4.6, so
On Mon, Jan 28, 2019 at 04:06:17PM +0100, Daniel Verite wrote:
> Michael Paquier wrote:
>
> > In src/bin/psql/copy.c, handleCopyIn():
> >
> > /*
> > * This code erroneously assumes '\.' on a line alone
> > * inside a quoted CSV string terminates the \copy.
> > *
> >
On 28/01/2019 21:35, Tom Lane wrote:
> Conceivably we could make it work without the parens:
>
> WITH ctename AS [ option = value [ , ] ] ( query )
>
> which for the immediate feature I'd be tempted to spell as
>
> WITH ctename AS [ materialize = on/off ] ( query ... )
>
> I
On Thu, Jan 24, 2019 at 08:14:41PM +0300, Konstantin Knizhnik wrote:
> The main differences with pgbouncer are that:
>
> 1. It is embedded and requires no extra steps for installation and
> configurations.
> 2. It is not single threaded (no bottleneck)
> 3. It supports all clients (if client
On Mon, Jan 28, 2019 at 7:32 AM Heikki Linnakangas wrote:
> I spent some time first trying to understand the current algorithm, and
> then rewriting it in a way that I find easier to understand. I came up
> with the attached. I think it optimizes for the same goals as your
> patch, but the
On Sun, Jan 27, 2019 at 8:23 AM Andrew Gierth
wrote:
> I think it makes more sense to say
> that we never inline if MATERIALIZED is specified, that we always inline
> if NOT MATERIALIZED is specified, and that if neither is specified the
> planner will choose (but perhaps note that currently it
Andres Freund writes:
> On 2019-01-28 15:17:19 -0500, Tom Lane wrote:
>> Since I was intentionally trying to limit what optimizer.h pulls in,
>> and in particular not let it include relation.h, I needed an opaque
>> typedef for PlannerInfo. On the other hand relation.h also needs to
>> typedef
On 28/01/2019 17:47, Jesper Pedersen wrote:
> On 1/28/19 11:30 AM, Fabrízio de Royes Mello wrote:
>> IMHO you should use long option name '--jobs' like others.
>>
>
> Thanks for your feedback !
>
> Done, and v4 attached.
I would drop the changes in pgupgrade.sgml. We don't need to explain
what
On 03/11/2018 00:14, Andreas 'ads' Scherbaum wrote:
> GNU make, version 3.8 or newer
> ISO/ANSI C compilar (at least C99-compliant)
> Flex 2.5.31 or later, and Bison 1.875 or later (for building from git)
> Perl 5.8.3 (for building from git)
I'm not in favor of listing all these versions here.
On Mon, Jan 21, 2019 at 10:28 AM Tom Lane wrote:
> Andreas Karlsson writes:
> > I have a minor biksheddish question about the syntax.
> > You proposed:
> > WITH cte_name [[NOT] MATERIALIZED] AS (query) main_query
> > While Andrew proposed:
> > WITH cte_name AS [[NOT] MATERIALIZED] (query)
On 1/28/19 3:50 PM, Peter Eisentraut wrote:
Done, and v4 attached.
I would drop the changes in pgupgrade.sgml. We don't need to explain
what doesn't happen, when nobody before now ever thought that it would
happen.
Also, we don't need the versioning stuff. The new cluster in pg_upgrade
is
On Fri, Jan 25, 2019 at 7:21 PM Tom Lane wrote:
> Anyway I think the names need to be any-something.
To me, that seems unnecessarily rigid. Not a bad idea if we can come
up with something that is otherwise acceptable. But all of your
suggestions sound worse than Pavel's proposal, so...
--
In <6044.1548524...@sss.pgh.pa.us> I worried about how much planner
stuff that patch might end up dragging into files that contain
planner support functions, and suggested that we could refactor the
planner's header files to reduce the inclusion footprint. Attached
are some proposed patches to
Hi,
On 2019-01-28 13:02:11 -0800, Andres Freund wrote:
> It's not required by C99, it however is required by C11. But a lot of
> compilers have allowed it as an extension for a long time (like before
> C99), unless suppressed by some option. I think that's partially because
> C++ has allowed it
Hi,
Bruce Momjian writes:
> It is nice it is a smaller patch. Please remind me of the performance
> advantages of this patch.
The patch as it stands is mostly helpful in those situations:
- application server(s) start e.g. 2000 connections at start-up and
then use them depending on user
On Sun, Jan 27, 2019 at 10:10:36PM +0900, Michael Paquier wrote:
> On Thu, Jan 24, 2019 at 10:09:30PM -0500, Bruce Momjian wrote:
> > This seems like a bug to me. Looking at the code, psql issues the
> > prompts for STDIN, but when it sees \. alone on a line, it has no idea
> > you are in a
On Fri, Jan 25, 2019 at 04:33:54PM +0200, Heikki Linnakangas wrote:
> On 15/01/2019 02:52, John Naylor wrote:
> >The majority of cases are measurably faster, and the best case is at
> >least 20x faster. On the whole I'd say this patch is a performance win
> >even without further optimization. I'm
Robert Haas writes:
> On Mon, Jan 28, 2019 at 3:17 PM Tom Lane wrote:
>> I'm really unhappy that force_parallel_mode and
>> parallel_leader_participation are being treated as planner GUCs.
> The only use of parallel_leader_participation at plan time seems to be
> to twiddle the costing, and the
Hi,
So, I'd pushed the latest version. And longfin came back with an
interesting error:
ERROR: page 135 of relation "pg_class" should be empty but is not
The only way I can currently imagine this happening is that there's a
concurrent vacuum that discovers the page is empty, enters it into the
Hi,
On 2019-01-28 18:08:59 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I'm inclined to put back the
> >LockBuffer(buf, BUFFER_LOCK_UNLOCK);
> >LockRelationForExtension(onerel, ExclusiveLock);
> >UnlockRelationForExtension(onerel, ExclusiveLock);
> >
Andres Freund writes:
> On 2019-01-28 19:51:22 -0500, Tom Lane wrote:
>> I propose that we should fix this by making the whole bodies of those
>> two headers be #ifdef USE_LLVM.
> Hm, I think it's sufficient that we error out if llvm was configured,
> we've sufficient buildfarm machines running
On Tue, Jan 29, 2019 at 4:03 AM Andres Freund wrote:
> On 2019-01-29 04:00:19 +0300, Alexander Korotkov wrote:
> > + /*
> > + * It is safe to use here PG_TRY/PG_CATCH without subtransaction
> > because
> > + * no function called inside performs data modification.
> > + */
> >
Alexander Korotkov writes:
> + if (jspThrowErrors(cxt) ||
> + ERRCODE_TO_CATEGORY(errcode) != ERRCODE_DATA_EXCEPTION)
> + PG_RE_THROW();
> BTW, this code also looks... useless. I can't see whole numeric.c
> throwing ERRCODE_DATA_EXCEPTION.
On Tue, Jan 29, 2019 at 4:44 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Tue, Jan 29, 2019 at 4:03 AM Andres Freund wrote:
> >> FWIW, I still think this is a terrible idea and shouldn't be merged this
> >> way. The likelihood of introducing subtle bugs seems way too high - even
> >>
At Mon, 28 Jan 2019 14:53:43 +0100, Peter Eisentraut
wrote in
<24783370-5acd-e0f3-8eb7-7f42ff2a0...@2ndquadrant.com>
> On 28/01/2019 09:14, Kyotaro HORIGUCHI wrote:
> > 0002:
> >
> > The test 54-56 of 001_ssltest.pl failed, which succeeded before
> > applying 0002. Seems to need to use
Hi all,
In 2016, a thread was started about implementing INSERT INTO ... SET ...
that included a patch and was basically ready for inclusion in
PostgreSQL. However, it seems as though it stagnated for some reason.
Does anybody remember this and is there perhaps someone who knows what
the
Andres Freund writes:
> I'm inclined to put back the
>LockBuffer(buf, BUFFER_LOCK_UNLOCK);
>LockRelationForExtension(onerel, ExclusiveLock);
>UnlockRelationForExtension(onerel, ExclusiveLock);
>LockBufferForCleanup(buf);
>if
On Tue, Jan 29, 2019 at 12:37 AM John Naylor
wrote:
>
> On Mon, Jan 28, 2019 at 12:10 PM Amit Kapila wrote:
>
> > 2.
> > @@ -15,13 +15,9 @@
> > SELECT octet_length(get_raw_page('test_rel_forks', 'main', 100)) AS
> > main_100;
> > ERROR: block number 100 is out of range for relation
I wrote:
> Since the LLVM stuff went in, src/tools/pginclude/cpluspluscheck
> fails on my main devel machine, because
Actually, it also fails on another machine that does have LLVM installed:
In file included from /tmp/cpluspluscheck.LqnoZj/test.cpp:3:
./src/include/jit/llvmjit_emit.h: In
Hi,
Although I became your reviewer, it seems to be difficult to feedback in this
CF.
I continue to review, so would you update your patch please?
Until then I review your current patch.
There is one question.
date_1.out which maybe is copy of date.out includes trailing space and gaps of
Hi,
On 2019-01-28 20:21:49 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-01-28 19:51:22 -0500, Tom Lane wrote:
> >> I propose that we should fix this by making the whole bodies of those
> >> two headers be #ifdef USE_LLVM.
>
> > Hm, I think it's sufficient that we error out if llvm
On Tue, Jan 29, 2019 at 4:30 AM Alexander Korotkov
wrote:
> On Tue, Jan 29, 2019 at 4:03 AM Andres Freund wrote:
> > On 2019-01-29 04:00:19 +0300, Alexander Korotkov wrote:
> > > + /*
> > > + * It is safe to use here PG_TRY/PG_CATCH without subtransaction
> > > because
> > > + *
Andres Freund writes:
> I don't think we are actually contradicting each other. The aim of that
> error was to prevent pieces of code that aren't conditional on
> --with-llvm from including llvmjit.h. I was, for a moment and wrongly,
> thinking that we could style the header in a way that'd make
Andres Freund writes:
> I did that now. I couldn't reproduce it locally, despite a lot of
> runs. Looking at the buildfarm it looks like the failures were,
> excluding handfish which failed without recognizable symptoms before and
> after, on BSD derived platforms (netbsd, freebsd, OX), which
On Tue, Jan 29, 2019 at 12:35:30AM +, Jamison, Kirk wrote:
> I just checked the patch.
> As per advice, you removed the versioning and specified --jobs.
> The patch still applies, builds and passed the tests successfully.
I would document the optional VACUUM_OPTS on the page of pg_upgrade.
On 2019-01-28 19:51:22 -0500, Tom Lane wrote:
> On 2019-01-28 11:19:21 -0500, Tom Lane wrote:
> > Since the LLVM stuff went in, src/tools/pginclude/cpluspluscheck
> > fails on my main devel machine, because
> >
> > In file included from /tmp/cpluspluscheck.jobsM6/test.cpp:3:
> >
On 2019-01-29 04:17:33 +0300, Alexander Korotkov wrote:
> On Tue, Jan 29, 2019 at 4:03 AM Andres Freund wrote:
> > On 2019-01-29 04:00:19 +0300, Alexander Korotkov wrote:
> > > + /*
> > > + * It is safe to use here PG_TRY/PG_CATCH without subtransaction
> > > because
> > > + * no
Alexander Korotkov writes:
> On Tue, Jan 29, 2019 at 4:03 AM Andres Freund wrote:
>> FWIW, I still think this is a terrible idea and shouldn't be merged this
>> way. The likelihood of introducing subtle bugs seems way too high - even
>> if it's possibly not buggy today, who says that it's not
Hi,
On 2019-01-28 17:31:15 -0800, Andres Freund wrote:
> On 2019-01-29 04:17:33 +0300, Alexander Korotkov wrote:
> > I'm probably not yet understanding all the risks this code have. So far I
> > see:
>
> I find these *more* than sufficient to not go to the PG_TRY/CATCH
> approach.
>
>
> > 1)
(2019/01/28 19:37), Etsuro Fujita wrote:
> (2019/01/25 20:33), Etsuro Fujita wrote:
>> I noticed yet another thing while updating the patch for pushing down
>> ORDER BY LIMIT. Let me explain. When costing foreign paths on the
>> basis of local statistics, we calculate/cache the costs of an
Hi Jesper,
Thanks for updating your patches quickly.
>On 1/28/19 3:50 PM, Peter Eisentraut wrote:
>>> Done, and v4 attached.
>>
>> I would drop the changes in pgupgrade.sgml. We don't need to explain
>> what doesn't happen, when nobody before now ever thought that it would
>> happen.
>>
>>
On 1/28/19 7:26 PM, Andrey Borodin wrote:
* I am no fan of the tupdesc vs truncTupdesc separation and think that it is a
potential hazard, but I do not have any better suggestion right now.
B-tree is copying tupdesc every time they truncate tuple. We need tuple
truncation a little more often:
On Tue, Jan 29, 2019 at 11:49:37AM +0900, Takashi Menjo wrote:
> Because of pg_pwrite()[1], openLogOff, a static global variable in xlog.c,
> seems taken over by a local variable startoffset and no longer used
> now.
It seems to me that keeping openLogOff is still useful to get a report
about the
On Tue, Jan 29, 2019 at 12:18:29PM +0900, Kyotaro HORIGUCHI wrote:
> At Mon, 28 Jan 2019 14:53:43 +0100, Peter Eisentraut
> wrote in
> <24783370-5acd-e0f3-8eb7-7f42ff2a0...@2ndquadrant.com>
>> This is strange. The tests work for me, and also on the cfbot. The
>
> Agreed. It seemed so also to
On Mon, Jan 28, 2019 at 05:05:32PM -0500, Tom Lane wrote:
> Yeah, I thought about that too, but it doesn't seem like an improvement.
> If the query is very long (which isn't unlikely) I think people would
> prefer to see the option(s) up front.
Having these options at the front of the WITH clause
Mark Dilger writes:
>> The swtich in src/backend/parser/analyze.c circa line 2819 should
>> probably have an explicit case for RTE_RESULT rather than just a
>> comment and allowing the default to log "unrecognized RTE type",
>> since it's not really unrecognized, just unexpected. But I'm not
>>
On 28.01.2019 16:50, Tomas Vondra wrote:
On 1/28/19 1:22 AM, Alexander Korotkov wrote:
* I decided to change behavior of jsonb_path_match() to throw as less
errors as possible. The reason is that it's used to implement
potentially (patch is pending) indexable operator. Index scan is not
Andres Freund writes:
> And even if you, to address Tom's point about plpgsql, had a category
> that could only be thrown by core code,
Actually, that wasn't quite what my point was there. Even if the error
that is thrown is perfectly safe and was thrown from a known spot in the
core code,
Hi,
On 2019-01-28 16:40:36 -0800, Andres Freund wrote:
> On 2019-01-28 15:49:33 -0800, Andres Freund wrote:
> > On 2019-01-28 18:08:59 -0500, Tom Lane wrote:
> > > Andres Freund writes:
> > > > I'm inclined to put back the
> > > >LockBuffer(buf, BUFFER_LOCK_UNLOCK);
> > > >
Hi,
On 2019-01-28 15:49:33 -0800, Andres Freund wrote:
> On 2019-01-28 18:08:59 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > I'm inclined to put back the
> > >LockBuffer(buf, BUFFER_LOCK_UNLOCK);
> > >LockRelationForExtension(onerel, ExclusiveLock);
> > >
Hi,
On 2019-01-29 04:00:19 +0300, Alexander Korotkov wrote:
> + /*
> + * It is safe to use here PG_TRY/PG_CATCH without subtransaction because
> + * no function called inside performs data modification.
> + */
> + PG_TRY();
> + {
> + res =
On Tue, Jan 29, 2019 at 4:03 AM Andres Freund wrote:
> On 2019-01-29 04:00:19 +0300, Alexander Korotkov wrote:
> > + /*
> > + * It is safe to use here PG_TRY/PG_CATCH without subtransaction
> > because
> > + * no function called inside performs data modification.
> > + */
> >
On Mon, 28 Jan 2019 at 21:21, Amit Langote
wrote:
> Thanks for the fix, I'll incorporate it in the next version I'll post by
> tomorrow.
I just started reading 0001 again. I made a few notes:
1. Should bms_del_members() instead of bms_difference() if you don't
mind modifying in place, which it
1 - 100 of 124 matches
Mail list logo
