Hello Amit,
I have updated the patch based on these observations. Attached v2.
Patch v2 applies & compiles cleanly, works for me.
I'm not partial to Hungarian notation conventions, which is not widely
used elsewhere in pg. I'd suggest eolchar -> eol or line_end or whatever,
but others ma
While reviewing the patches in
http://postgr.es/m/20191126.213752.2132434859202124793.horikyota@gmail.com
I noticed three related problems. The defects motivating that other thread
are specific to wal_level=minimal. The related problems are not specific to
any wal_level, hence my starting a s
Michael Paquier writes:
> On Fri, Nov 29, 2019 at 10:30:47AM -0500, Tom Lane wrote:
>> What's the impact going to be on buildfarm members with older openssl
>> installations? Perhaps "none", if they aren't running the ssl test
>> suite, but we should be clear about it.
> Actually, no, what I am
On Fri, Nov 29, 2019 at 7:11 PM Masahiko Sawada
wrote:
>
> On Thu, 28 Nov 2019 at 11:57, Amit Kapila wrote:
> >
>
> > I think it is probably because this part of the code doesn't consider
> > PARALLEL_VACUUM_DISABLE_LEADER_PARTICIPATION. I think if we want we
> > can change it but I am slightly
On Thu, Nov 21, 2019 at 11:31 AM Tom Lane wrote:
> Thomas Munro writes:
> > I think the choices are: (1) switch to ssize_t and return -1, (2) add
> > at least one of BufFileEof(), BufFileError(), (3) have BufFileRead()
> > raise errors with elog(). I lean towards (2), and I doubt we need
> > Buf
On Fri, Nov 29, 2019 at 10:30:47AM -0500, Tom Lane wrote:
> What's the impact going to be on buildfarm members with older openssl
> installations? Perhaps "none", if they aren't running the ssl test
> suite, but we should be clear about it.
The buildfarm logs don't directly report the version of
On Fri, Oct 11, 2019 at 04:49:11PM +0300, Ants Aasma wrote:
> Thanks for the pointer, wow that's a long thread. For some reason it did
> not consider lifting the INT_MAX tuples/12GB limitation. I'll see if I can
> pick up where that thread left off and push it along.
Hmm. Okay.. Then I have mark
On Fri, Nov 29, 2019 at 03:31:21PM +0530, Amit Kapila wrote:
> It might be better to move it to next CF as the discussion is still active.
OK, just did that.
--
Michael
signature.asc
Description: PGP signature
Hi Paul
I'm starting to look at this again. Here's a few proposed changes to
the current code as I read along.
I noticed that 0001 does not compile on its own. It works as soon as I
add 0002. What this is telling me is that the current patch split is
not serving any goals; I think it's okay to
On Fri, Nov 29, 2019 at 07:01:39PM +0100, David Fetter wrote:
> Folks,
>
> Per a suggestion Christophe made, please find attached a patch to
> $Subject:
>
> Apart from carefully fudging with pg_resetwal, and short of running in
> production for a few weeks, what would be some good ways to test th
On Fri, Nov 29, 2019 at 12:34 PM Thomas Munro wrote:
> ... or stop using
> _mdfd_getseg() for this so that you can remove segments independently
> without worrying about sync requests for other segments (it was
> actually like that in an earlier version of the patch for commit
> 3eb77eba, but some
Folks,
Per a suggestion Christophe made, please find attached a patch to
$Subject:
Apart from carefully fudging with pg_resetwal, and short of running in
production for a few weeks, what would be some good ways to test this?
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 377
Hi,
I encountered that the assertion error is reported instead of a proper
PANIC message when failed to fsync WAL. The cause is that there are
multiple places where we call XLogFileNameP function that calls palloc
during critical section, for example XLogWrite function.
TRAP: FailedAssertion("Cri
Hi Fabien,
On Fri, Nov 29, 2019 at 10:13 PM Fabien COELHO wrote:
> > I wonder why we don't use the same style for $subject as pg_basebackup
> > --progress, that is, use a carriage return instead of a newline after
> > each line reporting the number of tuples copied?
>
> Patch applies cleanly, com
Michael Paquier writes:
> On Fri, Nov 29, 2019 at 01:40:48PM +0100, Magnus Hagander wrote:
>> +1. As long as we still have support to change it down if needed, it's a
>> good thing to ship with a proper default.
> +1.
What's the impact going to be on buildfarm members with older openssl
installa
On 11/28/19 10:25 PM, Greg Nancarrow wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: tested, passed
> Documentation:tested, failed
>
> Hi A
On Thu, 28 Nov 2019 at 11:57, Amit Kapila wrote:
>
> On Thu, Nov 28, 2019 at 4:10 PM Mahendra Singh wrote:
> >
> > On Thu, 28 Nov 2019 at 13:32, Masahiko Sawada
> > wrote:
> >>
> >> On Wed, 27 Nov 2019 at 19:21, Mahendra Singh wrote:
> >> >
> >> >
> >> > Thanks for the re-based patches.
> >> >
I wonder why we don't use the same style for $subject as pg_basebackup
--progress, that is, use a carriage return instead of a newline after
each line reporting the number of tuples copied?
Patch applies cleanly, compiles, and works for me.
My 0.02€:
fprintf -> fputs or fputc to avoid a form
On Fri, Nov 29, 2019 at 01:40:48PM +0100, Magnus Hagander wrote:
> +1. As long as we still have support to change it down if needed, it's a
> good thing to ship with a proper default.
+1.
--
Michael
signature.asc
Description: PGP signature
On Fri, Nov 29, 2019 at 11:10 AM Daniel Gustafsson wrote:
> > On 29 Nov 2019, at 08:36, Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> wrote:
> >
> > I propose to change the default of ssl_min_protocol_version to TLSv1.2
> (from TLSv1, which means 1.0). Older versions would still be supp
On Fri, Nov 29, 2019 at 12:22 AM Mark Dilger wrote:
>
> Hackers,
>
> While working on the problem of XID wraparound within the LISTEN/NOTIFY
> system, I tried to increment XIDs by more than one per transaction.
> This leads to a number of test failures, many which look like:
>
> +ERROR: could not
On Fri, Nov 29, 2019 at 1:36 PM Juan José Santamaría Flecha
wrote:
>
>
>
> On Fri, Nov 29, 2019 at 7:30 AM Michael Paquier wrote:
>>
>> On Thu, Nov 28, 2019 at 08:53:56AM +0530, Amit Kapila wrote:
>> > I have pushed the refactoring patch. In the second patch, I have a
>> > few more comments. I
After digesting the discussion, let's reshuffle this a bit.
I have committed the change that adds the error location in one place.
That worked independently.
Attached is a new patch that refactors things a bit to pass the
ParseState into functions such as PrepareQuery() and ExecuteQuery()
in
> On 29 Nov 2019, at 08:36, Peter Eisentraut
> wrote:
>
> I propose to change the default of ssl_min_protocol_version to TLSv1.2 (from
> TLSv1, which means 1.0). Older versions would still be supported, just not
> by default.
+1 for having a sane default with a way to fall back to older vers
On Fri, Nov 29, 2019 at 1:36 PM Juan José Santamaría Flecha
wrote:
>
>
> On Fri, Nov 29, 2019 at 7:30 AM Michael Paquier wrote:
>>
>> On Thu, Nov 28, 2019 at 08:53:56AM +0530, Amit Kapila wrote:
>> > I have pushed the refactoring patch. In the second patch, I have a
>> > few more comments. I am
Michaël,
+ boolaset;
It seems to me that there is no point to have the variable aset in
Command because this structure includes already MetaCommand, so the
information is duplicated. [...] Perhaps I am missing something?
Yep. ISTM that you are missing that aset is not an independ
On 2019-11-28 17:11, Tom Lane wrote:
I read through the patch set and have just one quibble: in the
proposed new docs,
+Allows modification of the structure of system tables as well as
+certain other risky actions on system tables. This is otherwise not
+allowed even for
On Fri, 29 Nov 2019 18:16:00 +0900
Yugo Nagata wrote:
> On Fri, 29 Nov 2019 15:34:52 +0900
> Amit Langote wrote:
>
> > Thanks a lot for working on this. It's a great (and big!) feature and
> > I can see that a lot of work has been put into writing this patch. I
> > started looking at the patc
On Fri, 29 Nov 2019 15:34:52 +0900
Amit Langote wrote:
> Thanks a lot for working on this. It's a great (and big!) feature and
> I can see that a lot of work has been put into writing this patch. I
> started looking at the patch (v8), but as it's quite big:
>
> 34 files changed, 5444 insertio
Yamada-san,
On Fri, Nov 29, 2019 at 5:45 PM Tatsuro Yamada
wrote:
> Attached patch is the revised patch. :)
>
> I wonder two things below. What do you think?
>
> 1)
> For now, I'm not sure it should be set current_child_table_relid to zero
> when the current phase is changed from "acquiring inher
Tomas-san and Jeff-san
I'm very sorry for my slow response.
Tomas-san wrote:
> That does indeed seem like a bug. We should certainly archive all WAL
> segments, irrespectedly of primary shutdowns/restarts/whatever.
I think so, too.
Tomas-san wrote:
> I guess we should make sure the archiver is
Hi Alvaro and Amit!
On 2019/11/29 9:54, Tatsuro Yamada wrote:
Hi Alvaro!
Hmmm... I understand your opinion but I'd like to get more opinions too. :)
Do you prefer these column names? See below:
Here's my take on it:
pid
datid
datname
relid
phase
sample_blks_total
sam
Luis,
It seems you've got enough support for this concept, so let's move
forward with this patch. There are some comments from Tom about the
patch; would you like to send an updated version perhaps?
Thanks
Hi,
I've attached a new version (v6) removing the superfluous JOIN that Tom
identified,
On Fri, Nov 29, 2019 at 7:21 AM Michael Paquier wrote:
>
> On Fri, Nov 29, 2019 at 03:19:49PM +0900, Michael Paquier wrote:
> > On Wed, Nov 13, 2019 at 12:53:09PM +0100, Julien Rouhaud wrote:
> >> I'd really like to have the queryid function available through SQL,
> >> but I think that this specif
On Thu, 28 Nov 2019 11:03:33 -0300
Alvaro Herrera wrote:
> One thing pending in this development line is how to catalogue aggregate
> functions that can be used in incrementally-maintainable views.
> I saw a brief mention somewhere that the devels knew it needed to be
> done, but I don't see in t
At Thu, 28 Nov 2019 21:37:03 +0900 (JST), Kyotaro Horiguchi
wrote in
> > > 0dc8ead463 hit this. Rebased.
> >
> > Please review the pg_waldump.c hunks in 0001; they revert recent changes.
>
> Ughhh! I'l check it. Thank you for noticing!!
Fixed that, re-rebased and small comment and cosmetic ch
If Anastasia doesn't mind I'd like to send new version of the patch.
On 2019/11/28 12:29, Artur Zakirov wrote:
On 2019/11/27 13:22, Michael Paquier wrote:
Yeah, the actual take is if we want to make the frontend code more
complicated with a large set of SQL queries to check that each object
ACL
On Fri, Nov 29, 2019 at 7:30 AM Michael Paquier wrote:
> On Thu, Nov 28, 2019 at 08:53:56AM +0530, Amit Kapila wrote:
> > I have pushed the refactoring patch. In the second patch, I have a
> > few more comments. I am not completely sure if it is a good idea to
> > write a new test file 060_drop
38 matches
Mail list logo
