On 2018-Aug-30, Yugo Nagata wrote:
> On Thu, 30 Aug 2018 06:52:58 -0300
> Alvaro Herrera wrote:
> > This should have been listed in the pg11 open items. Please list there
> > everything that should apply be applied branch 11 before release, so
> > that they get fixed (or at least considered)
On Thu, 30 Aug 2018 06:52:58 -0300
Alvaro Herrera wrote:
> Thanks! Pushed. There was a markup error in the documentation.
Thank you!
>
>
> This should have been listed in the pg11 open items. Please list there
> everything that should apply be applied branch 11 before release, so
> that
Thanks! Pushed. There was a markup error in the documentation.
This should have been listed in the pg11 open items. Please list there
everything that should apply be applied branch 11 before release, so
that they get fixed (or at least considered) before we release.
On Thu, Aug 30, 2018 at 12:30 PM Alexander Korotkov
wrote:
> On Thu, Aug 30, 2018 at 12:17 PM Alexander Korotkov
> wrote:
> > # Current patch (use list)
> > x run 1 run 2 run 3
> > 0.11206 1230 1231
> > 0.01 2862 2813 2802
> > 0.003 13915 13911 13900
>
> Sorry, I didn't explain
On Thu, Aug 30, 2018 at 12:17 PM Alexander Korotkov
wrote:
> # Current patch (use list)
> x run 1 run 2 run 3
> 0.11206 1230 1231
> 0.01 2862 2813 2802
> 0.003 13915 13911 13900
Sorry, I didn't explain what these tables means. There are times in
milliseconds for 3 runs of
On 2018/08/29 21:06, Amit Langote wrote:
> I measured the gain in performance due to each patch on a modest virtual
> machine. Details of the measurement and results follow.
>
> UPDATE:
>
> nparts master0001 0002 0003
> == ==
> 0 28562893 2862
Hi!
On Tue, Aug 28, 2018 at 12:50 PM Alexander Korotkov
wrote:
> On Thu, Jul 26, 2018 at 8:39 PM Andrey Borodin wrote:
> > I'm not sure in architectural point of view: supporting two ways (list and
> > heap) to store result seems may be a bit heavy, but OK. At least, it has
> > meaningful
On Thu, 30 Aug 2018 10:54:08 +0200
Michael Banck wrote:
> Hi,
>
> On Thu, Aug 30, 2018 at 05:48:24PM +0900, Yugo Nagata wrote:
> > Oops, It's my mistake. I updated the patch.
>
> Looks good to me now.
>
> One could argue that the message could be 'checksums verified in file
> FILE' (plural)
Hello hackers!
It seems bgwriter running on the replicas is broken in the commit
8d68ee6 and as a result bgwriter never updates minRecoveryPoint in the
pg_control.Please see a detailed explanation below.
2018-08-29 22:54 GMT+02:00 Michael Paquier :
> This is not a solution in my opinion, as you
> On Wed, 29 Aug 2018 at 09:32, Ashutosh Bapat
> wrote:
>
> > * Many functions carry some unrelated arguments just to pass them through,
> > which obscures the purpose of a function.
>
> Can you please provide some examples?
E.g this chain with partsupfunc & collations:
Hi,
On Thu, Aug 30, 2018 at 05:48:24PM +0900, Yugo Nagata wrote:
> Oops, It's my mistake. I updated the patch.
Looks good to me now.
One could argue that the message could be 'checksums verified in file
FILE' (plural) rather than 'checksum verified in file FILE', but that is
quickly approaching
On Thu, 30 Aug 2018 10:34:06 +0200
Michael Banck wrote:
> Hi,
>
> On Thu, Aug 30, 2018 at 05:35:09PM +0900, Yugo Nagata wrote:
> > --- a/doc/src/sgml/ref/pg_verify_checksums.sgml
> > +++ b/doc/src/sgml/ref/pg_verify_checksums.sgml
> > @@ -61,11 +61,11 @@ PostgreSQL documentation
> >
> >
Hi,
On Thu, Aug 30, 2018 at 05:35:09PM +0900, Yugo Nagata wrote:
> --- a/doc/src/sgml/ref/pg_verify_checksums.sgml
> +++ b/doc/src/sgml/ref/pg_verify_checksums.sgml
> @@ -61,11 +61,11 @@ PostgreSQL documentation
>
>
>
> - -d
> + -v
Sorry that I did not catch this the
Hi,
I noticed that pg_verify_checksums computes bogus checksums if I compile
it with '-O2 -Wall' but without -fno-strict-aliasing. Also I am getting
a compile warning then:
|src/bin/pg_verify_checksums$ make CFLAGS='-g -O2 -Wall'
[...]
|gcc -g -O2 -Wall -I../../../src/include
|
On Thu, 30 Aug 2018 10:13:31 +0200
Michael Banck wrote:
> Hi,
>
> thanks for fixing this up!
>
> On Wed, Aug 29, 2018 at 11:25:28PM +0900, Yugo Nagata wrote:
> > diff --git a/doc/src/sgml/ref/pg_verify_checksums.sgml
> > b/doc/src/sgml/ref/pg_verify_checksums.sgml
> > index
Hi,
thanks for fixing this up!
On Wed, Aug 29, 2018 at 11:25:28PM +0900, Yugo Nagata wrote:
> diff --git a/doc/src/sgml/ref/pg_verify_checksums.sgml
> b/doc/src/sgml/ref/pg_verify_checksums.sgml
> index ecc5501eae..a1ff060c2b 100644
> --- a/doc/src/sgml/ref/pg_verify_checksums.sgml
> +++
Hi hackers,
I am really confused. If my conclusions are correct, then nobody ever
tried to use replication slots at Windows!
The function RestoreSlotFromDisk in slot.c contains the following code:
static void
RestoreSlotFromDisk(const char *name)
{
ReplicationSlotOnDisk cp;
int
I spotted the formatting issue in an older version and the change I did
confused me thinking that it was fixing the issue.
Sorry.
Martín
On Thu, Aug 30, 2018 at 12:34 AM Bruce Momjian < Bruce Momjian ( Bruce Momjian
) > wrote:
>
>
>
> On Wed, Aug 29, 2018 at 08:02:54PM -0700, Martín
On Sat, Aug 11, 2018 at 12:47:05PM -0700, Noah Misch wrote:
> On Wed, Aug 08, 2018 at 09:58:38AM -0400, Tom Lane wrote:
> > When the security team was discussing this issue before, we speculated
> > about ideas like inventing a function trust mechanism, so that attacks
> > based on search path
On 29/08/2018 16:39, Fabien COELHO wrote:
>
>>> The majority rule (34 make & 22 free) suggest that it is more often use
>>> than not. I'd suggest to stick to that for consistency & homogeneity.
>>
>> But it's consistently not used in DDL command implementations, only in
>> normal query parsing.
>
On 2 August 2018 at 21:32, Peter Geoghegan wrote:
If I want to sort on heap TID as a tie-breaker, I cannot cut any
> corners. That is, it has to be just another column, at least as far as
> the implementation is concerned (heap TID will have a different
> representation in internal pages and
On Thu, 30 Aug 2018 15:01:24 +0900 (Tokyo Standard Time)
Kyotaro HORIGUCHI wrote:
> At Wed, 29 Aug 2018 20:10:15 +0900, Yugo Nagata wrote
> in <20180829201015.d9d4fde2748910e86a13c...@sraoss.co.jp>
> > On Wed, 29 Aug 2018 16:01:53 +0530
> > Amit Kapila wrote:
> >
> > > > By the way, I think
On Thu, 30 Aug 2018 09:14:26 +0300
Heikki Linnakangas wrote:
> On 30/08/18 07:48, Yugo Nagata wrote:
> > Attached is a patch to fix comments of IndexInfo. ii_KeyAttrNumbers was
> > renamed to ii_IndexAttrNumbers and ii_Am was added but these are
> > not reflected to the comment.
>
> Applied,
On 30/08/18 07:48, Yugo Nagata wrote:
Attached is a patch to fix comments of IndexInfo. ii_KeyAttrNumbers was
renamed to ii_IndexAttrNumbers and ii_Am was added but these are
not reflected to the comment.
Applied, thanks!
- Heikki
At Wed, 29 Aug 2018 20:10:15 +0900, Yugo Nagata wrote in
<20180829201015.d9d4fde2748910e86a13c...@sraoss.co.jp>
> On Wed, 29 Aug 2018 16:01:53 +0530
> Amit Kapila wrote:
>
> > > By the way, I think we can fix this also by clearing the header
> > > information of the last
> > > page instead of
101 - 125 of 125 matches
Mail list logo
