On Tue, 25 Jun 2019 at 19:14, Robert Haas wrote:
>
> On Fri, Jun 21, 2019 at 11:50 AM Amit Khandekar
> wrote:
> > > This definitely needs to be expanded, and follow the message style
> > > guideline.
> >
> > This message , with the v8 patch, looks like this :
> > ereport(LOG,
> >
From: Ashwin Agrawal [mailto:aagra...@pivotal.io]
> The objective is to gather feedback on design and approach to the same.
> The implementation has core basic pieces working but not close to complete.
Thank you for proposing a very interesting topic. Are you thinking of
including this in
On Sun, Jun 30, 2019 at 04:06:47PM +0300, Alexander Lakhin wrote:
> 4.33. close_ - > closept_
This one is incorrect as it refers to the various close_* routines
below.
> 4.36. combinedproj -> remove (orphaned after 69c3936a)
This looks intentional?
> I've split proposed patch to make the fixes
Tomas Vondra writes:
> Attached is a slightly improved version of the serialization patch.
I reviewed this patch, and tested it on hppa and ppc. I found one
serious bug: in the deserialization varlena case, you need
- dataptr += MAXALIGN(len);
+
From: Stephen Frost [mailto:sfr...@snowman.net]
> sh, don't look now, but there might be a "Resend email" button in the
> archives now that you can click to have an email sent to you...
>
> Note that you have to be logged in, and the email will go to the email address
> that you're logging
From: Amit Kapila [mailto:amit.kapil...@gmail.com]
> Tsunakawa/Haribabu - By reading this thread briefly, it seems we need
> some more inputs from other developers on whether to fix this or not,
> so ideally the status of this patch should be 'Needs Review'. Why it
> is in 'Waiting on Author'
> "Richard" == Richard Guo writes:
Richard> Hi all,
Richard> During the reorder of grouping sets into correct prefix order,
Richard> if only one aggregation pass is needed, we follow the order of
Richard> the ORDER BY clause to the extent possible, to minimize the
Richard> chance that
Peter Eisentraut writes:
> On 2019-05-29 21:03, Tom Lane wrote:
>> If we do delete them as useless, it might also be advisable to change
>> CreateConversionCommand() to refuse creation of conversions to/from
>> SQL_ASCII, to prevent future confusion.
> It seems nonsensical by definition to allow
On Fri, Jun 28, 2019 at 03:24:03PM -0700, Peter Geoghegan wrote:
On Mon, Apr 8, 2019 at 11:04 PM Peter Eisentraut
wrote:
Yeah, I think implementing a v4 generator in core would be trivial and
address almost everyone's requirements.
FWIW, I think that we could do better with nbtree page
Michael Paquier writes:
> On Sat, Jun 29, 2019 at 04:36:51PM -0400, Tom Lane wrote:
>> I think this is likely a consequence of ca129e58c0 having modified
>> 010_dump_connstr.pl to use "regress_postgres" not "postgres" as the
>> bootstrap superuser name in the source cluster. I suppose I
Hello Peter,
Yeah, I think implementing a v4 generator in core would be trivial and
address almost everyone's requirements.
Here is a proposed patch for this. I did a fair bit of looking around
in other systems for a naming pattern but didn't find anything
consistent. So I ended up just
Hello hackers,
Please consider fixing the next bunch of typos and inconsistencies in
the tree:
4.1. AccesShareLock -> AccessShareLock
4.2. AdjustTimestampForTypemod -> AdjustTimestampForTypmod
4.3. AExprConst -> AexprConst
4.4. AlterExtensionOwner_oid - remove (orphaned after 994c36e0)
4.5.
On Sun, Jun 30, 2019 at 11:06:58AM +0200, Peter Eisentraut wrote:
> I ended up rewriting this by extracting the parsing code into
> pg_lsn_in_internal() and having both pg_lsn_in() and
> check_recovery_target_lsn() calling it. This mirrors similar
> arrangements in float.c
The refactoring looks
Hi,
With the glibc 2.28 coming, all users will have to reindex almost
every indexes after a glibc upgrade to guarantee the lack of
corruption. Unfortunately, reindexdb is not ideal for that as it's
processing everything using a single connexion and isn't able to
discard indexes that doesn't
This has been committed.
On 2019-06-24 06:06, Michael Paquier wrote:
> I have been looking at this patch set. Patch 0001 looks good to me.
> You are removing all traces of a set of timestamp keywords not
> supported anymore, and no objections from my side for this cleanup.
>
> +#define
Hi
so 29. 6. 2019 v 10:19 odesÃlatel Pavel Stehule
napsal:
>
>
> so 29. 6. 2019 v 9:32 odesÃlatel Fabien COELHO
> napsal:
>
>>
>> Hello Pavel,
>>
>> > \set SORT_BY_SIZE on
>> > \dt -- sorted by schema, name (size is not calculated and is not
>> visible)
>> > \dt+ -- sorted by size
>>
>> Patch
There are 3 independent patches associated to one thread and one CF entry.
*** About toast table v3:
Patch applies cleanly, compiles, works for me.
ISTM that the he query should be unambiguous: pg_catalog.pg_class instead
of pg_class, add an alias (eg c), use c.FIELD to access an
On Fri, 21 Jun 2019 at 19:09, Dean Rasheed wrote:
> Hmm, maybe. I can certainly understand your dislike of using text[].
> I'm not sure that we can confidently say that multivariate statistics
> won't ever need additional tuning knobs, but I have no idea at the
> moment what they might be, and
18 matches
Mail list logo
