sort_mem_blocks / (parallel_workers + 1) <
min_sort_mem_blocks)
+ sort_mem_blocks / (parallel_workers + (leaderasworker
? 1 : 0)) < min_sort_mem_blocks)
Thank you for working on this patch!
All the best,
Tels
find . -type f -name '*.p[lm]' -print0 | sort -u -z | xargs -0 ...
Not sure if that is more, or less, portable then the original -print
variant, tho.
Best regards,
Tels
Moin,
On Thu, December 28, 2017 5:43 pm, Tom Lane wrote:
> "Tels" <nospam-pg-ab...@bloodgate.com> writes:
>> On Wed, December 27, 2017 3:38 pm, Tom Lane wrote:
>>> Also, I changed PLpgSQL_var.isconst and PLpgSQL_var.notnull from "int"
>>> to
e internet, so you might as well use
the CPAN version directly.
The best course seems to me to have dependencies on the OS packackes for
the Perl modules you want to use. Not sure, however, if the build farm
client has "proper" Debian etc. packages and if it is even possible to add
these dependencies in this way.
Best wishes,
Tels
tuples are needed */
If I'm not wrong, the layout of the struct will include quite a bit of
padding on 64 bit due to the mixing of bool and int64, maybe it would be
better to sort the fields differently, e.g. pack 4 or 8 bools together?
Not sure if that makes much of a difference, though.
That's all for now :)
Thank you for your work,
Tels
Moin,
On Mon, January 15, 2018 2:34 pm, Tels wrote:
> Maybe that's a Linux-specific thing, but I always use Ctrl-D to exit a
> console, and this works with psql, too, even when in the middle of a query
> typed.
>
> So maybe this could be suggested?
Sorry, should have really
can make it print
> that thing.
Maybe that's a Linux-specific thing, but I always use Ctrl-D to exit a
console, and this works with psql, too, even when in the middle of a query
typed.
So maybe this could be suggested?
Best wishes,
Tels
ITY INCLUDING
CONSTRAINTS INCLUDING INDEXES INCLUDING STORAGE INCLUDING
COMMENTS.
+ INCLUDING DEFAULTS INCLUDING IDENTITY INCLUDING
CONSTRAINTS INCLUDING INDEXES INCLUDING STORAGE INCLUDING STATISTICS
INCLUDING COMMENTS.
Best wishes,
Tels
case.
I'm not sure if you mean exactly the scenario as in the attached test
case, but this works in plpgsql, too, and would be a shame to lose.
OTOH, one could also write:
SELECT INTO ba, bb a,b FROM foo(1);
and it would still work, or wouldn't it?
Best regards,
Tels
test.psql
Description: Binary data
test.pl
Description: Perl program
n here?
Are the uninitialized bytes that are written out "whatever was in the
memory previously" or just some "0x00 bytes from the allocation but not
yet overwritten from the PG code"?
Because the first sounds like it could be a security problem - if random
junk bytes go out to the disk, and stay there, information could
inadvertedly leak to permanent storage.
Best regards,
Tels
ed git? An
account? Where? And how does it all work?
I guess a lot of potential translators who aren't programmers would be
left baffled, too.
Best regards,
Tels
nd/or code are correct, just a grammar fix:
+/*
+ * If we've sent a record is at or beyond the flushed
point, then
+ * we're caught up.
That should read more like this:
"If we've sent a record that is at or beyond the flushed point, we have
caught up."
All the best,
Tels
Moin,
On Tue, December 26, 2017 5:26 am, Masahiko Sawada wrote:
> On Tue, Dec 26, 2017 at 6:19 PM, Tels <nospam-pg-ab...@bloodgate.com>
> wrote:
>> Moin,
>>
>> On Mon, December 25, 2017 7:26 pm, Masahiko Sawada wrote:
>>> On Tue, Dec 26, 2017
worth it?
And maybe folding all four bool fields into an "int flags" field with bits
would save space, and not much slower (depending on often how the
different flags are accessed due to the ANDing and ORing ops)?
Best regards,
Tels#include
#include
#include
/*
* #include &quo
lanced tree with a
minimum (or at least not-as-high) number of levels, or does it increase in
height every insert and creates a "tall stack"?
@Peter: Could you please share your back-of-the-envelope calculation, I'd
love to get some insights into the innards.
All the best,
Tels
open my $fh, "rand" or die; foreach (1..130) {$x="";
next if rand()> 0.; sysseek $fh,$_*8*1024,0 or die $!; sysread $fh,
$x,8*1024; print length $x} ' | uniq -c
432810 8192
real0m26,575s
user0m0,540s
sys 0m2,200s
So it does get slower, but only about 2.5 times respectively about 30%.
Hope this helps,
Tels
00:00 one day
later", that could work, but you can't just have it meaning "add 24 hours
to the clock".
For instance, during daylight saving time changes, days can be 23 hours or
25 hours long...
Best wishes,
Tels
(1 row)
>
> regression=# select time '23:59:59.999';
>time
> --
> 24:00:00
> (1 row)
>
> If we didn't allow '24:00:00' as a valid value then we'd need to
> throw an error for '23:59:59.999', which doesn't seem nice.
Hm, but shouldn't the result then be "00:00:00" instead of "24:00:00"?
With addition it seems to work different:
postgres=# select time '23:59:59.99' + interval '0.01 seconds';
?column?
--
00:00:00
(1 row)
Best regards,
Tels
Anyway, in a few places we have functions that use a lot (> a dozend)
regexps that are also moderate complex (e.g. span multiple lines). In
these cases the performance was not really up to par, so I experimented
and in the end rewrote the functions in plperl. Which fixed the
performance, so we no longer had this issue.
All the best,
Tels
sure which case it is in this example. Shouldn't the system aim to
have at least some basic stats, even if the user never runs ANALYZE? Or is
this on purpose for these tests to see what happens?
Best regards,
Tels
en before fixed tests were
> completed, because this old machine is slow.
+ *) if [ `find ${PGDATA} -type f ! -perm 640 | wc -l` -ne 0 ]; then
Shouldn't ${PGDATA} in the above as argument to find be quoted, otherwise
the shell would get confused if it contains spaces or other special
characters?
Regards,
Tels
also concerned that that would let anybody who could alter the
environment then let arbitrary code be run as user postgres. Is this
something that poses a risk in addition to the current situation?
Best regards,
Tels
Moin,
On Sat, July 21, 2018 12:47 pm, Dagfinn Ilmari Mannsåker wrote:
> Tom Lane writes:
>
>> "Tels" writes:
>>> + *) if [ `find ${PGDATA} -type f ! -perm 640 | wc -l` -ne 0 ]; then
>>
>>> Shouldn't ${PGDATA} in the above as argument to fin
ot; has its grammar at odds with
the purpose the code seems to be.
It could be named "SkipTuples" (e.g. this is the number of tuples we need
to skip, not the number we have skipped), and the other one then
"iss_SkipTuplesRemaining" so they are consistent with each other.
Others might have a better name for these two, of course.
Best wishes,
Tels
t not come out in the order you expect - especially
with paralell queries, new processing nodes etc.
Best wishes,
Tels
PS: We use string_agg() in a case where we first agg each row, then
string_agg() all rows, and the resulting string is really huge. We did run
into the "out of memory"-prob
plpgsql.extra_errors for errors. Both can be set
either to
+a comma-separated list of checks, "none" or
+"all".
quotes here around '"all"'. I think it should be one or the other in both
cases.
Also:
+ Currently
+the list of available checks includes only one:
but then it lists more than one check?
Best wishes,
Tels
ing deadlines like starting commit fests?
In addition, clear rules and well-formulated project goals would help a lot.
Also, the discussion about "needs of the project" vs. the "needs of the
users" [0] should be separate from the "what do we do about the lack of
manpowe
actually a read followed by a dependent write.
+*/
(" Pairs ..." vs. ". We only ...")
Best regards,
Tels
, but also have all the other data
and see all other (still existing) versions, if they want.
If that page is "more confusing" than a directory listing where you have
to pick the right file, or not, is of course debatable.
Regards,
Tels
readable.
Oh, one more question. Shouldn't these regexps that start with "^" also
end with "$"? Or can there be output like:
'COMMENT ON DATABASE postgres IS $QR_IDENTIFIER; SELECT 1;'
?
Best regards,
Tels
free time on their hands will sit around,
drink a nice cup of tea and come up
with all sorts of attacks on these things that you didn't (and couldn't)
anticipate now.
So IMHO it would be much better to err on the side of caution and
encrypt everything possible.
Best regards,
Tels
- *start++ = *a;
- *a-- = swap;
+ memcpy(pos - 2, DIGIT_TABLE + c, 2);
+ i += 2;
}
+ else
+ *a = (char) ('0' + value2);
+
+ return olength;
}
The line "i += 2;" modifies i, but i is never used again nor returned.
Best regards,
Tels
e would be incompressible, the
second one would be just a copy. This might not happens that often in
practical inputs, though.
I wonder if you agree and what would happen if you try this variant on
your corpus tests.
Best regards,
Tels
th SHA-1 and about
427 MByte / s with SHA-256 (if I haven't miscalculated something). You'd
need a
pretty fast disk (aka M.2 SSD) and network (aka > 1 Gbit) to top these
speeds
and then you'd use a real CPU for your server, not some poor Intel
powersaving
surfing thingy-majingy :)
Best regards,
Tels
Moin,
On 2019-11-22 23:30, David Steele wrote:
On 11/22/19 5:15 PM, Tels wrote:
On 2019-11-22 20:01, Robert Haas wrote:
On Fri, Nov 22, 2019 at 1:10 PM David Steele
wrote:
> Phrased more positively, if you want a cryptographic hash
> at all, you should probably use one that isn't
Moin,
On 2019-10-20 16:27, Tom Lane wrote:
Tels writes:
On 2019-10-20 13:30, Andreas Karlsson wrote:
Agreed, this sounds like something useful to do since virtually all
strict functions cannot return NULL, especially the ones which are
used in tight loops. The main design issue seems
UNCTION f1 ... STRICT;
CREATE FUNCTION f2 ... STRICT NONULL;
CREATE FUNCTION f3 ... NONULL;
and the last wold throw "not implementet yet"? "NEVER RETURNS NULL"
would also ryme with the existing "RETURNS NULL ON NULL INPUT", but I
find the verbosity too high.
Best regards,
Tels
--
Best regards,
Tels
On 2019-11-24 15:38, David Steele wrote:
On 11/23/19 4:34 PM, Andrew Dunstan wrote:
On 11/23/19 3:13 AM, Tels wrote:
Without the strong hashes it would be pointless to sign the manifest.
I guess I must have missed where we are planning to add a
cryptographic
signature.
I don't think
Dear Dean,
On 2020-03-01 20:47, Dean Rasheed wrote:
On Fri, 28 Feb 2020 at 08:15, Dean Rasheed
wrote:
It's possible that there are further gains to be had in the sqrt()
algorithm on platforms that support 128-bit integers, but I haven't
had a chance to investigate that yet.
Rebased patch
Moin,
On 2020-02-07 15:42, Emre Hasegeli wrote:
> The patch looks unduly invasive to me, but I think that it might be
> right that we should go back to a macro-based implementation, because
> otherwise we don't have a good way to be certain that the function
> parameter won't get evaluated
. That
will making an extension later much easier and avoids the "we need to
add X, but that breaks compatibility with all software out there"
situations that often arise a few years down the line.
Best regards,
and a happy New Year 2020
Tels
, thetime)
and it would be easier, and (hopefully) faster?
Best regards,
Tels
Hello Tom,
On 2020-11-18 16:49, Tom Lane wrote:
Tels writes:
On 2020-11-18 06:06, Michael Paquier wrote:
On Mon, Nov 16, 2020 at 10:14:10PM -0500, Tom Lane wrote:
Agreed, I'm not trying to block this patch. Just wishing
there were a better way.
To me the code looks like a prime
;data-driven"
refactoring.
It should be redone as generic code that reads a table of rules with
params and then checks and applies each. Thus the repetitive code would
be replaced by a bit more generic code and a lot of code-free data.
--
Best regards,
Tels
44 matches
Mail list logo
