On Sat, Feb 22, 2020 at 10:22:27PM +0100, Daniel Gustafsson wrote:
> Turns out that we in heap_multi_insert missed to call log_heap_new_cid for the
> first tuple inserted, we only do it in the loop body for the subsequent ones.
> With the attached patch, the v6 of this patch posted upthead pass
On Fri, Feb 21, 2020 at 08:13:34AM -0500, David Steele wrote:
> Do you have the thread? I'd like to see what was proposed and what the
> objections were.
Here you go:
https://www.postgresql.org/message-id/20180205071022.ga17...@paquier.xyz
--
Michael
signature.asc
Description: PGP signature
On Fri, Feb 21, 2020 at 05:37:15PM +0900, Kyotaro Horiguchi wrote:
> The two str[n]cmps are different only in matching length. I don't
> think we don't need to differentiate the two message there, so we
> could reduce the code as:
>
> | cmplen = strlen(excludeFiles[].name);
> | if (!prefix_patch)
On Fri, 14 Feb 2020 at 14:37, Robert Haas wrote:
>
>> On Fri, Feb 14, 2020 at 2:08 PM Dave Cramer
>> wrote:
>> > Well now you are asking the driver to re-interpret the results in a
>> different way than the server which is not what we tend to do.
>> >
>> > The server throws an error we throw an
On Fri, Feb 21, 2020 at 04:49:59PM +0900, Kyotaro Horiguchi wrote:
> At Wed, 19 Feb 2020 17:29:08 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > At Tue, 18 Feb 2020 23:44:52 -0800, Noah Misch wrote in
> > > - When reusing an index build, instead of storing the dropped relid in the
> > >
On Thu, Feb 20, 2020 at 04:56:38PM -0800, Jeff Davis wrote:
On Wed, 2020-02-19 at 20:16 +0100, Tomas Vondra wrote:
1) explain.c currently does this:
I wonder if we could show something for plain explain (without
analyze).
At least the initial estimate of partitions, etc. I know not showing
On Sat, Feb 22, 2020 at 10:53:35PM +0100, Tomas Vondra wrote:
> I've started looking at this patch, because I've been long missing the
Thanks for looking
I have brief, initial comments before I revisit the patch.
> 3) Almost all executor nodes that are modified to include this new
>
Hi,
I've started looking at this patch, because I've been long missing the
information about hashagg hash table, so I'm pleased someone is working
on this. In general I agree it may be useful to add simila information
to other nodes using a hashtable, but IMHO the hashagg bit is the most
useful,
> On 26 Jan 2020, at 21:30, Andres Freund wrote:
> On 2020-01-22 23:18:12 +0100, Daniel Gustafsson wrote:
>>> On 26 Nov 2019, at 06:44, Michael Paquier wrote:
>>
>> Re this patch being in WoA state for some time [0]:
>>
>>> The regression tests of contrib/test_decoding are still failing here:
Hello.
> The patch about making color by default [1] introduces the function
> terminal_supports_color(), that I think is relevant for this issue. Please
> find attached a new version based on that idea.
I am not sure it is good idea to mix both patches because it adds some
confusion and makes
On Sat, 2020-02-22 at 10:00 -0800, Andres Freund wrote:
> Both patches, or just 0013? Seems the earlier one might make the
> addition of the opcodes you add less verbose?
Just 0013, thank you. 0008 looks like it will simplify things.
Regards,
Jeff Davis
Hi,
On 2020-02-22 09:55:26 -0800, Jeff Davis wrote:
> On Fri, 2020-02-21 at 12:22 -0800, Andres Freund wrote:
> > I'd also like to apply something like 0013 from that thread, I find
> > the
> > whole curperagg, select_current_set, curaggcontext logic confusing as
> > hell. I'd so far planned to
On Fri, 2020-02-21 at 12:22 -0800, Andres Freund wrote:
> I'd also like to apply something like 0013 from that thread, I find
> the
> whole curperagg, select_current_set, curaggcontext logic confusing as
> hell. I'd so far planned to put this on the backburner until this
> patch
> has been
On Fri, 2020-02-21 at 19:24 -0600, Joe Nelson wrote:
> I could imagine having two types, a rational8 for the current
> implementation, and an arbitrary precision rational. Perhaps...
The main thing I'm trying to avoid is a situation where we introduce
"rational", but it only meets a subset of the
On Sat, Feb 22, 2020 at 8:01 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > From my point of view criticism of this patch was addressed by
> > argument, that pg_shmem_init_time() allows to calculate the server
> > uptime [1]. This is very basic information, which is reasonable to
> > get
Alexander Korotkov writes:
> From my point of view criticism of this patch was addressed by
> argument, that pg_shmem_init_time() allows to calculate the server
> uptime [1]. This is very basic information, which is reasonable to
> get without log files parsing. It's more than year since [1] is
On Sun, Dec 23, 2018 at 11:14 PM Alexander Korotkov
wrote:
> On Tue, Apr 10, 2018 at 8:58 PM Robert Haas wrote:
> > On Tue, Apr 10, 2018 at 9:07 AM, David Steele wrote:
> > > On 3/29/18 9:40 AM, Tomas Vondra wrote:
> > >> On 03/28/2018 08:55 PM, David Steele wrote:
> > >>> I'm setting this
On 2020-02-17 18:42, Peter Eisentraut wrote:
On 2020-02-03 13:47, Andres Freund wrote:
Comment:
- It'd be good to split out the feature independent refactorings, like
the introduction of InitControlFile(), into their own commit. Right
now it's hard to separate out what should just
On Sat, Feb 22, 2020 at 08:09:24AM +0100, Julien Rouhaud wrote:
> On Tue, Feb 18, 2020 at 07:39:49AM +0100, Julien Rouhaud wrote:
> > On Tue, Feb 18, 2020 at 7:19 AM Michael Paquier wrote:
> > >
> > > On Tue, Feb 18, 2020 at 07:06:25AM +0100, Julien Rouhaud wrote:
> > > > On Tue, Feb 18, 2020 at
On Tue, Feb 18, 2020 at 02:29:33PM +0900, Michael Paquier wrote:
> On Sun, Feb 16, 2020 at 01:08:35PM -0600, Justin Pryzby wrote:
> > Forking old, long thread:
> > https://www.postgresql.org/message-id/36712441546604286%40sas1-890ba5c2334a.qloud-c.yandex.net
> > On Fri, Jan 04, 2019 at 03:18:06PM
> On 18 Feb 2020, at 03:03, Thomas Munro wrote:
>
> From the trivialities department, I see a bunch of warnings about
> local declaration placement (we're still using C90 rules for those by
> project policy):
>
> refcursor.c:138:3: error: ISO C90 forbids mixed declarations and code
>
21 matches
Mail list logo
