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
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
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
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
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.
> >
> >
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:
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.
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
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
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
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,
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
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
>
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
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
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
>
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
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
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
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
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
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
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
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
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*
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,
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
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
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,
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
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,
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
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
> 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
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
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
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
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
49 matches
Mail list logo
