On Mon, Apr 13, 2020 at 5:57 AM Stephen Frost wrote:
>
> There's a couple of other pieces here that I think bear mentioning. The
> first is that pgBackRest has an actual 'restore' command- and that works
> with the filters and works with the storage drivers, so what you're
> looking at when it co
On Mon, Apr 20, 2020 at 11:24 AM Thomas Munro wrote:
>
> On Sat, Apr 18, 2020 at 9:27 PM Dilip Kumar wrote:
> > On Sat, Apr 18, 2020 at 11:47 AM Thomas Munro
> > wrote:
> > > I think I found another bug in MaintainOldSnapshotTimeMapping(): if
> > > you make time jump by more than old_snapshot_t
On 2020/03/10 6:56, Andres Freund wrote:
Hi,
On 2020-03-06 16:33:18 -0300, Alvaro Herrera wrote:
On 2020-Mar-06, Michael Paquier wrote:
On Thu, Mar 05, 2020 at 09:40:54AM -0500, Robert Haas wrote:
Seems reasonable, but it would be better if people proposed these
kinds of changes closer to t
On 2020/04/18 0:31, Tom Lane wrote:
Kyotaro Horiguchi writes:
At Fri, 17 Apr 2020 16:03:34 +0900, Fujii Masao
wrote in
I agree that it might be worth considering the removal of am_sync for
the master branch or v14. But I think that it should not be
back-patched.
Ah! Agreed.
Yeah, tha
On Mon, Apr 20, 2020 at 8:18 AM Amit Kapila wrote:
>
> On Sat, Apr 18, 2020 at 8:35 PM Robert Haas wrote:
> >
> > On Fri, Apr 17, 2020 at 7:44 PM Andres Freund wrote:
> > > This suggest that pipes do have a considerably higher overhead on
> > > windows, but that it's not all that terrible if one
On Sat, Apr 18, 2020 at 9:27 PM Dilip Kumar wrote:
> On Sat, Apr 18, 2020 at 11:47 AM Thomas Munro wrote:
> > I think I found another bug in MaintainOldSnapshotTimeMapping(): if
> > you make time jump by more than old_snapshot_threshold in one go, then
> > the map gets cleared and then no early p
On Sun, 19 Apr 2020 at 01:00, Tom Lane wrote:
>
> Masahiko Sawada writes:
> > On Sat, 18 Apr 2020 at 00:31, Tom Lane wrote:
> >> + /* Quick out if not even configured to be synchronous */
> >> + if (SyncRepConfig == NULL)
> >> + return false;
>
> > I felt strange a bit that we do the a
On 2020/04/18 16:01, Noah Misch wrote:
On Fri, Apr 17, 2020 at 05:06:29PM +0900, Kyotaro Horiguchi wrote:
At Fri, 17 Apr 2020 17:00:15 +0900 (JST), Kyotaro Horiguchi
wrote in
By the way, if latch is consumed in WalSndLoop, succeeding call to
WalSndWaitForWal cannot be woke-up by the latch-
On Fri, 17 Apr 2020 at 22:50, Masahiko Sawada
wrote:
>
> On Tue, 14 Apr 2020 at 22:41, tushar wrote:
> >
> > Hi ,
> >
> > We have a sql file called 'generated.sql' under src/test/regress/sql
> > folder . if we run this file on psql , take the dump and try to restore
> > it on another db
> > we a
On Mon, Apr 20, 2020 at 4:32 AM Michael Paquier wrote:
>
> On Sun, Apr 19, 2020 at 03:59:50PM -0300, Ranier Vilela wrote:
> > Em dom., 19 de abr. de 2020 às 12:34, Juan José Santamaría Flecha <
> > juanjo.santama...@gmail.com> escreveu:
> >> This line needs a break, other than that LGTM.
> >
> > S
On Sat, Apr 18, 2020 at 5:14 AM Andres Freund wrote:
>
> zstd -T0 < onegbofrandom > NUL
> zstd -T0 < onegbofrandom > /dev/null
> linux host: 0.361s
> windows guest: 0.602s
>
> zstd -T0 < onegbofrandom | dd bs=1M of=NUL
> zstd -T0 < onegbofrandom | dd bs=1M of=/dev/null
> linux host: 0.454
On Thu, Apr 16, 2020 at 10:12 PM Robert Haas wrote:
>
> Hi,
>
> I'm starting a new thread for this, because the recent discussion of
> problems with old_snapshot_threshold[1] touched on a lot of separate
> issues, and I think it will be too confusing if we discuss all of them
> on one thread. Atta
Em dom., 19 de abr. de 2020 às 22:00, David Rowley
escreveu:
> On Mon, 20 Apr 2020 at 11:24, Ranier Vilela wrote:
> > I tried: https://godbolt.org with:
> >
> > -O2:
> >
> > f1:
> > int main (int argv, char **argc)
> > {
> > return strlen(argc[0]) == 0;
> > }
> >
> > f1: Assembly
> > main:
On Sat, Apr 18, 2020 at 8:35 PM Robert Haas wrote:
>
> On Fri, Apr 17, 2020 at 7:44 PM Andres Freund wrote:
> > This suggest that pipes do have a considerably higher overhead on
> > windows, but that it's not all that terrible if one takes care to use
> > large buffers in each pipe element.
> >
>
On Sun, 2020-04-19 at 16:19 -0700, Peter Geoghegan wrote:
> Is it possible that the issue has something to do with what the
> compiler knows about the alignment of the tapes back when they were a
> flexible array vs. now, where it's a separate allocation? Perhaps I'm
> over reaching, but it occurs
On Mon, 20 Apr 2020 at 11:24, Ranier Vilela wrote:
> I tried: https://godbolt.org with:
>
> -O2:
>
> f1:
> int main (int argv, char **argc)
> {
> return strlen(argc[0]) == 0;
> }
>
> f1: Assembly
> main: # @main
> mov rcx, qword ptr [rsi]
>
On Sat, Apr 18, 2020 at 02:23:25PM -0400, James Coleman wrote:
On Thu, Apr 16, 2020 at 9:26 PM Tom Lane wrote:
Tomas Vondra writes:
> I think we have essentially three options:
> 1) assuming there's just a single group
> 2) assuming each row is a separate group
> 3) something in between
> If
> On Apr 19, 2020, at 3:55 PM, Michael Paquier wrote:
>
> On Thu, Mar 19, 2020 at 11:47:46AM -0700, Mark Dilger wrote:
>> On Mar 19, 2020, at 11:30 AM, Mark Dilger
>> wrote:
>>> Will post v3 shortly.
>
> Thanks for sending a new version of the patch and removing the bits
> about object drop
Em dom., 19 de abr. de 2020 às 18:38, Tom Lane escreveu:
> Tomas Vondra writes:
> > On Sun, Apr 19, 2020 at 11:24:38AM -0300, Ranier Vilela wrote:
> >> strlen it is one of the low fruits that can be harvested.
>
> > Maybe there are places where this would help, but I don't see a reason
> > to ju
Em dom., 19 de abr. de 2020 às 19:00, David Rowley
escreveu:
> On Mon, 20 Apr 2020 at 09:38, Tom Lane wrote:
> > The cases where Ranier proposes to replace strlen(foo) == 0
> > with a test on foo[0] do seem like wins, though. Asking for
> > the full string length to be computed is more computat
On Sun, Apr 19, 2020 at 3:07 PM Jeff Davis wrote:
> 1. Is my analysis correct?
> 2. What is the scale of this problem? What about other platforms or
> compilers? Are there other cases in PostgreSQL that might suffer from
> the use of FORTIFY_SOURCE?
> 3. Even if this is the compiler's fault, shoul
On Sun, Apr 19, 2020 at 03:59:50PM -0300, Ranier Vilela wrote:
> Em dom., 19 de abr. de 2020 às 12:34, Juan José Santamaría Flecha <
> juanjo.santama...@gmail.com> escreveu:
>> This line needs a break, other than that LGTM.
>
> Sure. Attached new patch with this revision.
Amit, are you planning to
On Fri, 17 Apr 2020 at 19:08, Amit Langote wrote:
> While looking at this, I observed that the PartitionPruneInfo of the
> top-level Append (the one that later gets thrown out) contains bogus
> information:
>
>{PARTITIONPRUNEINFO
>:prune_infos ((
> {PARTITIONEDRELPRUNEINFO
> :r
On Thu, Mar 19, 2020 at 11:47:46AM -0700, Mark Dilger wrote:
> On Mar 19, 2020, at 11:30 AM, Mark Dilger
> wrote:
>> Will post v3 shortly.
Thanks for sending a new version of the patch and removing the bits
about object drops. Your additions to src/backend/ look fine to me,
so I have no object
There was a previous thread[1], but I think it needs some wider
discussion.
I brought up an issue where GCC in combination with FORTIFY_SOURCE[2]
causes a perf regression for logical tapes after introducing
LogicalTapeSetExtend()[3]. Unfortunately, FORTIFY_SOURCE is used by
default on ubuntu. I h
On Mon, 20 Apr 2020 at 09:38, Tom Lane wrote:
> The cases where Ranier proposes to replace strlen(foo) == 0
> with a test on foo[0] do seem like wins, though. Asking for
> the full string length to be computed is more computation than
> necessary, and it's less clear that the compiler could be
>
Tomas Vondra writes:
> On Sun, Apr 19, 2020 at 11:24:38AM -0300, Ranier Vilela wrote:
>> strlen it is one of the low fruits that can be harvested.
> Maybe there are places where this would help, but I don't see a reason
> to just throw away all strlen calls and replace them with something
> clear
On 4/19/20 10:29 PM, Ranier Vilela wrote:
Em dom., 19 de abr. de 2020 às 16:33, Tomas Vondra
mailto:tomas.von...@2ndquadrant.com>>
escreveu:
On Sun, Apr 19, 2020 at 11:24:38AM -0300, Ranier Vilela wrote:
>Hi,
>strlen it is one of the low fruits that can be harvested.
>What i
On Sun, Apr 19, 2020 at 05:29:52PM -0300, Ranier Vilela wrote:
Em dom., 19 de abr. de 2020 às 16:33, Tomas Vondra <
tomas.von...@2ndquadrant.com> escreveu:
On Sun, Apr 19, 2020 at 11:24:38AM -0300, Ranier Vilela wrote:
>Hi,
>strlen it is one of the low fruits that can be harvested.
>What is you
On Sun, Apr 19, 2020 at 03:13:29PM -0400, Alvaro Herrera wrote:
> On 2020-Apr-18, Justin Pryzby wrote:
> > I haven't heard a compelling argument for or against either way.
> >
> > Maybe the worst behavior might be if, during ATTACH, we searched for a
> > matching
> > trigger, and "merged" it (mar
On 2020-Apr-19, Justin Pryzby wrote:
> It's probably rare that we'd be inserting into a table old enough to be
> detached, and normally that would be ok, but if a trigger were missing, it
> would misbehave. In our use-case, we're creating trigger on the parent as a
> convenient way to maintain th
Em dom., 19 de abr. de 2020 às 16:33, Tomas Vondra <
tomas.von...@2ndquadrant.com> escreveu:
> On Sun, Apr 19, 2020 at 11:24:38AM -0300, Ranier Vilela wrote:
> >Hi,
> >strlen it is one of the low fruits that can be harvested.
> >What is your opinion?
> >
>
> That assumes this actually affects/impr
Hello hackers,
19.04.2020 13:37, Tom Lane wrote:
>
> Peter Eisentraut writes:
>> The HEAPDEBUGALL define has been broken since PG12 due to tableam
>> changes. Should we just remove this? It doesn't look very useful.
>> It's been around since Postgres95.
>> If we opt for removing: PG12 added an a
On Sun, Apr 19, 2020 at 11:24:38AM -0300, Ranier Vilela wrote:
Hi,
strlen it is one of the low fruits that can be harvested.
What is your opinion?
That assumes this actually affects/improves performance, without any
measurements proving that. Considering large number of the places you
modified
On Wed, Apr 08, 2020 at 11:44:33AM -0500, Justin Pryzby wrote:
> On Wed, Apr 08, 2020 at 12:02:39PM -0400, Alvaro Herrera wrote:
> > On 2020-Apr-08, Justin Pryzby wrote:
> >
> > > This seems to be a bug in master, v12, and (probably) v11, where "FOR
> > > EACH FOR"
> > > was first allowed on part
On 2020-Apr-18, Justin Pryzby wrote:
> I haven't heard a compelling argument for or against either way.
>
> Maybe the worst behavior might be if, during ATTACH, we searched for a
> matching
> trigger, and "merged" it (marked it inherited) if it matched. That could be
> bad if someone *wanted* t
Em dom., 19 de abr. de 2020 às 12:34, Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> escreveu:
>
> On Sun, Apr 19, 2020 at 1:58 PM Ranier Vilela wrote:
>
>> Em dom., 19 de abr. de 2020 às 07:16, Juan José Santamaría Flecha <
>> juanjo.santama...@gmail.com> escreveu:
>>
>>> On Sat, Apr
Hi,
last week I finished pspg 3.0 https://github.com/okbob/pspg . pspg now
supports pipes, named pipes very well. Today the pspg can be used as pager
for output of \watch command. Sure, psql needs attached patch.
I propose new psql environment variable PSQL_WATCH_PAGER. When this
variable is not
Isaac Morland writes:
> If we were only concerned with HTML output then based on the desired
> semantics and appearance I would recommend without hesitation. Because
> of the need to produce PDF as well and my lack of knowledge of the Postgres
> documentation build process, I can't be so certain
On Sun, 19 Apr 2020 at 09:23, Tom Lane wrote:
> In any case, I reject the idea that we should just drop the table
> markup altogether and use inline variablelists. In most of these
> sections there is a very clear separation between the table contents
> (with per-function or per-operator detail
On Wed, Apr 15, 2020 at 2:04 PM James Coleman wrote:
>
> On Wed, Apr 15, 2020 at 11:02 AM James Coleman wrote:
> >
> > On Tue, Apr 14, 2020 at 2:53 AM Michael Paquier wrote:
> > >
> > > Hi,
> > >
> > > When initializing an incremental sort node, we have the following as
> > > of ExecInitIncremen
On Sun, Apr 19, 2020 at 1:58 PM Ranier Vilela wrote:
> Em dom., 19 de abr. de 2020 às 07:16, Juan José Santamaría Flecha <
> juanjo.santama...@gmail.com> escreveu:
>
>> On Sat, Apr 18, 2020 at 1:43 PM Ranier Vilela
>> wrote:
>>
>>> I have some observations about this patch, related to style, if
Hi,
strlen it is one of the low fruits that can be harvested.
What is your opinion?
regards,
Ranier Vilela
remove_strlen.patch
Description: Binary data
Hi Justin,
Thanks for the review!
On Sat, Apr 18, 2020 at 10:41 PM Justin Pryzby wrote:
>
> Should capitalize at least the non-text one ? And maybe the text one for
> consistency ?
>
> + ExplainPropertyInteger("WAL fpw", NULL,
I think we should keep both version consistent, wheth
On Sat, Apr 18, 2020 at 10:36 PM Justin Pryzby wrote:
>
> On Tue, Apr 07, 2020 at 10:53:05AM -0500, Justin Pryzby wrote:
> > On Tue, Apr 07, 2020 at 08:40:30AM -0400, James Coleman wrote:
> > > > And, should it use two spaces before "Sort Method", "Memory" and
> > > > "Pre-sorted
> > ...
> > > I
Peter Eisentraut writes:
> The HEAPDEBUGALL define has been broken since PG12 due to tableam
> changes. Should we just remove this? It doesn't look very useful.
> It's been around since Postgres95.
> If we opt for removing: PG12 added an analogous HEAPAMSLOTDEBUGALL
> (which still compiles co
Peter Eisentraut writes:
> This scares me in terms of maintainability of both the toolchain and the
> markup. Table formatting is already incredibly fragile, and here we
> just keep poking it until it looks a certain way instead of thinking
> about semantic markup.
That's a fair criticism, bu
The HEAPDEBUGALL define has been broken since PG12 due to tableam
changes. Should we just remove this? It doesn't look very useful.
It's been around since Postgres95.
If we opt for removing: PG12 added an analogous HEAPAMSLOTDEBUGALL
(which still compiles correctly). Would we want to keep t
Em dom., 19 de abr. de 2020 às 07:16, Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> escreveu:
>
> On Sat, Apr 18, 2020 at 6:07 AM Amit Kapila
> wrote:
>
>> On Sat, Apr 18, 2020 at 12:14 AM Juan José Santamaría Flecha
>> wrote:
>> >
>> > We can get a match for those locales in non-IS
> On Thu, Apr 09, 2020 at 09:55:25AM +1200, Thomas Munro wrote:
> Thanks. Here's a rebase.
Thanks for working on this patch, it seems like a great feature. I'm
probably a bit late to the party, but still want to make couple of
commentaries.
The patch indeed looks good, I couldn't find any signif
On 2020-04-17 02:25, Tom Lane wrote:
I eventually figured out that the approved way to do per-table-entry
customization is to attach "role" properties to the DocBook elements,
and then key off the role names in applying formatting changes in
the customization layer. So attached is a v3 that hand
On 2020-04-16 08:26, Pierre Giraud wrote:
The screenshot attached uses a tag for the descrition/example block.
I like this better, but then you don't really need the table because you
can just make the whole thing a definition list.
--
Peter Eisentraut http://www.2ndQuadrant.co
On 2020-04-13 22:33, Tom Lane wrote:
Maybe we're just trying to shoehorn too much information into a single
table.
Yeah, back at the beginning of this exercise, Alvaro wondered aloud
if we should go to something other than tables altogether. I dunno
what that'd look like though.
Yeah, after r
On Sat, Apr 18, 2020 at 6:07 AM Amit Kapila wrote:
> On Sat, Apr 18, 2020 at 12:14 AM Juan José Santamaría Flecha
> wrote:
> >
> > We can get a match for those locales in non-ISO format by enumerating
> available locales with EnumSystemLocalesEx(), and trying to find a match.
>
> I have not revi
54 matches
Mail list logo
