Hello, Amit
> I am not sure, if this is exactly what has been suggested by Robert,
> so it is not straightforward to see if his suggestion can allow us to
> use NUM_FREELISTS as 8 rather than 32. I think instead of trying to
> use FREELISTBUFF, why not do it as Robert has suggested and try with
>
Hello
There are applications that create and delete a lot of temporary
tables. Currently PostgreSQL doesn't handle such a use case well.
Consider the following benchmark/example.
postgresql.conf:
```
autovacuum = on
log_min_messages = debug2
```
temp-table.pgbench:
```
create temporary table t
> Won't it always use the same freelist to remove and add the entry from
> freelist as for both cases it will calculate the freelist_idx in same
> way?
No. If "our" freelist is empty when we try to remove an item from it we
borrow item from another freelist. Then this borrowed item will be
returne
> time pgbench -T 5 -R 0.1 -P 1 -c 2 -j 2
On my laptop this command executes 25 seconds instead of 5. I'm pretty
sure it IS a bug. Probably a minor one though.
I tested this patch on Ubuntu 14.04 LTS with GCC 4.8. It applies
cleanly on master branch (c7111d11) and solves a described problem.
No c
Hello, Michael
I didn't checked your patch in detail yet but here is a thought I would
like to share.
In my experience usually it takes number of rewrites before patch will
be accepted. To make sure that after every rewrite your patch still
solves an issue you described you should probably provid
Hello, Michael
> The easiest way to perform tests with this patch is to take a debugger
> and enforce the malloc'd pointers to NULL in the code paths.
I see. Still I don't think it's an excuse to not provide clear steps to
reproduce an issue. As I see it anyone should be able to easily check
your
> Attached is a v3 which test integers more logically. I'm a lazy
> programmer who tends to minimize the number of key strokes.
Well. From what I can tell this patch is Ready for Committer.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
Hello, Michael
Thanks a lot for steps to reproduce you provided.
I tested your path on Ubuntu Linux 14.04 LTS (GCC 4.8.4) and FreeBSD
10.2 RELEASE (Clang 3.4.1). In both cases patch applies cleanly, there
are no warnings during compilation and all regression tests pass. A few
files are not proper
Hello
I noticed:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=b6fb6471f6afaf649e52f38269fd8c5c60647669
... that comments for procedures pgstat_progress_update_param and
pgstat_progress_end_command are identical. Here is a patch that fixes
this. Also one empty line added afte
Hello
I noticed that master branch of PostgreSQL currently compiles with
warnings on FreeBSD 10.2 RELEASE:
```
pg_locale.c:1290:12: warning: implicit declaration of function
'wcstombs_l' is invalid in C99 [-Wimplicit-function-declaration]
result = wcstombs_l(to, from, tolen, locale);
pg_locale.
Hello, Tom
> I think what we need is configure logic to find out where wcstombs_l()
> is declared, and then #include only if it's necessary to
> get that definition. I haven't experimented but probably you could
> make such a check with nested uses of AC_CHECK_DECL.
Sounds like quite a dirty ha
62))
+#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 <<
31) << 31))
```
... were generated but `autoreconf -iv`. I was not sure what to do
about them. Eventually I decided to keep them. Still these changes could
be safely discarded.
--
Best regards,
Aleksand
ded stdlib.h ... wtf?
Same on FreeBSD.
--
Best regards,
Aleksander Alekseev
http://eax.me/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
perly pgindent'ed. Second patch fixes this too.
Naturally I checked that after applying these patches PostgreSQL still
compiles and pass all regression tests.
--
Best regards,
Aleksander Alekseev
http://eax.me/
diff --git a/src/backend/commands/policy.c b/src/backend/commands/policy.c
index bb735a
Here are a few more patches.
On Wed, 16 Mar 2016 18:11:04 +0300
Aleksander Alekseev wrote:
> Typos for the most part.
>
--
Best regards,
Aleksander Alekseev
http://eax.me/
diff --git a/src/backend/utils/adt/timestamp.c b/src/backend/utils/adt/timestamp.c
index 3f013e3..c9e5270 100644
Typos for the most part.
--
Best regards,
Aleksander Alekseev
http://eax.me/
diff --git a/contrib/pg_trgm/trgm_gin.c b/contrib/pg_trgm/trgm_gin.c
index ea8edef..2e41a9f 100644
--- a/contrib/pg_trgm/trgm_gin.c
+++ b/contrib/pg_trgm/trgm_gin.c
@@ -204,7 +204,7 @@ gin_trgm_consistent
There is a typo in one word in this commit:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=9a206d063c410df7cd5da01b169b23bff413fef5
Patch attached.
--
Best regards,
Aleksander Alekseev
http://eax.me/
diff --git a/contrib/unaccent/generate_unaccent_rules.py b/contrib/unaccent
have a strong feeling that we are just wasting our time here.
--
Best regards,
Aleksander Alekseev
http://eax.me/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
during regression tests run on buildfarms.
What do you think?
[1] http://clang.llvm.org/docs/MemorySanitizer.html
[2] http://clang.llvm.org/docs/AddressSanitizer.html
[3] http://clang.llvm.org/docs/LeakSanitizer.html
[4] http://clang.llvm.org/docs/ThreadSanitizer.html
--
Best regards,
Aleksander Al
ny such places.
Well in this case here is a patch that fixes "use of uninitialized
value" reports by MemorySanitizer I managed to catch so far.
--
Best regards,
Aleksander Alekseev
http://eax.me/
diff --git a/src/backend/access/gist/gistxlog.c b/src/backend/access/gist/gistxlog.c
index b48
0x00 0x00
0x7fffeb10: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
(gdb) quit
Naturally we could use memset() as well. But I personally find it a bit
less readable. And in theory it doesn't prevent some _very_ "smart" C
compiler from not cleaning the whole structure anyway.
--
Best regards,
> > It's possible that memset() would be more convincing.
>
> +1
OK, here is corrected patch.
--
Best regards,
Aleksander Alekseev
http://eax.me/
diff --git a/src/backend/access/gist/gistxlog.c b/src/backend/access/gist/gistxlog.c
index b48e97c..273e0b0 100644
--- a/src/ba
this thread.
If there are any other questions or doubts regarding these patches
please don't hesitate to ask.
--
Best regards,
Aleksander Alekseev
http://eax.me/
diff --git a/src/backend/utils/hash/dynahash.c b/src/backend/utils/hash/dynahash.c
index 24a53da..06c413c 100644
--- a/src/bac
e header files dependent files are not recompiled automatically.
--
Best regards,
Aleksander Alekseev
http://eax.me/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> Thanks! I can't think of anything else to worry about with regards to
> that version, so I have committed it.
>
Thanks, Robert. And thanks everyone for contributing to this patch.
--
Best regards,
Aleksander Alekseev
http://eax.me/
--
Sent via pgsql-hackers mailing list
Hello
I discovered that there is a lot of code duplication in heapam.c.
In particular relation_openrv and relation_openrv_extended procedures
and also heap_openrv and heap_openrv_extended procedures are almost the
same. Here is a patch that fixes this.
--
Best regards,
Aleksander Alekseev
http
regards,
Aleksander Alekseev
http://eax.me/
diff --git a/contrib/pg_stat_statements/pg_stat_statements.c b/contrib/pg_stat_statements/pg_stat_statements.c
index 3d9b8e4..4213c3a 100644
--- a/contrib/pg_stat_statements/pg_stat_statements.c
+++ b/contrib/pg_stat_statements/pg_stat_statements.c
ee more code on the screen. Besides since there is no code
duplication there is less change that somebody someday will change say
heap_openrv without updating heap_openrv_extended accordingly.
--
Best regards,
Aleksander Alekseev
http://eax.me/
diff --git a/src/backend/access/heap/heapam.c b/src
ments before I realized - there is none.
--
Best regards,
Aleksander Alekseev
http://eax.me/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ot; will accumulate until it become a _real_ problem.
As we know from experience, to that time it's usually much harder to
fix anything than it is now.
--
Best regards,
Aleksander Alekseev
http://eax.me/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e is no point of suggesting a patch that splits it into two or
three separate implementations for each use case, right? :) and I
misunderstood how it actually works. My apologies.
--
Best regards,
Aleksander Alekseev
http://eax.me/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
(0 rows)
```
Everything seems to work, no stacktraces in gdb.
Could you please provide more concrete steps to reproduce these
issues i.e, OS and compiler version, compilation flags (or package
version), cluster config, database schema, etc? These steps are required
at least to make sure tha
e
> reported problem. There is one similar problem [2] reported by Heikki
> which I think can be fixed separately.
> [...]
> Let me know if you think anything more from myside can help in moving
> patch.
+1, same here. Lets see whats committer's opinion.
--
Best regards,
A
't. Such a code is
hard to reason about. You could do it much simpler choosing only one
thing to do --- either allocate a new structure or use a provided one.
5) Code is not pgindent'ed and has many trailing spaces.
[1] http://www.postgresql.org/message-id/56eff347.20...@anastigmati
L sanitizers-friendly or not in a corresponding thread. So far
no one spoke against this idea. Thus I don't think that new patches
should complicate implementing it. Especially considering that it's
very simple to do and even is considered a good practice according to
PostgreSQL documentation.
k4umfcwa4e...@mail.gmail.com
On Thu, 21 Jan 2016 16:49:12 +0530
Dilip Kumar wrote:
> On Tue, Jan 12, 2016 at 1:50 PM, Aleksander Alekseev <
> a.aleks...@postgrespro.ru> wrote:
>
> >
> > increasing number of lock partitions (see columns "no locks",
> > "lwlock&q
Hi,
> First of all, why not merge both patches into one? They aren't too
> big anyway.
Agree.
> I think comments should be changed, to be more informative here.
> Add a comment here too.
> Maybe you should explain this magic number 7 in the comment above?
Done.
> Then, this thread became too
Hello, Tom
> Also, there are defined ways to convert between Datum format and
> other formats (DatumGetPointer() etc). This code isn't using 'em.
Fixed. But I was not sure how to deal with File and Buffer types since
they are ints (see fd.h and buf.h) and there is no DatumGetInt macro,
only Datu
> Um, that's not too surprising, because they're exactly the same patch?
Wrong diff. Here is correct one.
Everything else is right. I just re-checked :)
step2a:
number of transactions actually processed: 16325
latency average: 49.008 ms
latency stddev: 8.780 ms
tps = 163.182594 (including con
Hello, Tom.
I'm a bit concerned regarding assumption that sizeof int never exceeds 4
bytes. While this could be true today for most C compilers, standard
[1][2] doesn't guarantee that. Perhaps we should add something like:
StaticAssertStmt(sizeof(int) <= sizeof(int32),
"int size exceeds int32
> > This patch affects header files. By any chance didn't you forget to
> > run `make clean` after applying it? As we discussed above, when you
> > change .h files autotools doesn't rebuild dependent .c files:
> >
>
> Yes, actually i always compile using "make clean;make -j20; make
> install" If y
> This comment certainly requires some changes.
Fixed.
> BTW, could you explain why init_table_size was two times less than
> max_table_size?
I have no clue. My best guess is that it was a reasonable thing to do in
the past. Then somebody changed a code and now there is little reason
to use ini
I tested this patch on x64 and ARM servers for a few hours today. The
only problem I could find is that INSERT works considerably slower after
applying a patch. Beside that everything looks fine - no crashes, tests
pass, memory doesn't seem to leak, etc.
> Okay, now for some badness. I've restore
Hello, Robert.
> So: do we have clear evidence that we need 128 partitions here, or
> might, say, 16 work just fine?
Yes, this number of partitions was chosen based on this benchmark (see
"spinlock array" column):
http://www.postgresql.org/message-id/20151229184851.1bb7d1bd@fujitsu
In fact we c
Hello, Robert
> Basically, the burden for you to impose a new coding rule on everybody
> who uses shared hash tables in the future is very high.
I fixed an issue you described. Number of spinlocks doesn't depend of
NUM_LOCK_PARTITIONS anymore and could be specified for each hash table
on a callin
Hello, Robert
> Thanks, this looks way better. Some more comments:
>
> - I don't think there's any good reason for this patch to change the
> calling convention for ShmemInitHash(). Maybe that's a good idea and
> maybe it isn't, but it's a separate issue from what this patch is
> doing, and if
Hello, Robert
> It also strikes me that it's probably quite likely that slock_t
> mutex[NUM_FREELISTS] is a poor way to lay out this data in memory.
> For example, on a system where slock_t is just one byte, most likely
> all of those mutexes are going to be in the same cache line, which
> means y
s in
this (these) patch (patches). However as I understand there are
currently no unit tests in PostgreSQL at all, only integration/system
tests. Any advice how to do it better?
--
Best regards,
Aleksander Alekseev
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
responding connection string.
In this case user could extend prompt string quite easily like this:
```
\set EXPORT_CONNECTION_STRING true
\set PROMPT1 '%`psql ~/.psql_prompt_script`> =#'
```
Basically it does the same I did using Python and Bash aliases but in
much simpler and clea
_MAKE_MEM_DEFINED(&msg, sizeof(msg));
> Do we need both?
Apparently we don't. I removed VALGRIND_MAKE_MEM_DEFINED here since now
there are no uninitialized padding bytes in &msg.
Corrected patch is attached. If you have any other ideas how it could
be improved please let me k
know how to
include unit test and whether they should be included at all. Thus for now
unit/property-based tests could be found only on GitHub [1].
As usual, if you have any questions, suggestions or notes regarding this patch,
please let me know.
[1] https://github.com/afiskon/c-algorithms/tree/ma
sing course of action. In first
implementation we could just place all virtual part of the catalog in a shared
memory and protect it with a single lock. If it will work as expected the next
step would be elimination of bottlenecks --- using multiple locks, moving part
of a virtual catalog to local b
Implementation of rb_rightmost is trivial so we probably can do
without it.
> I think we should something like in the attached patch. It seems to pass
> your test suite, but I haven't done any other testing on this. Does it
> look OK to you?
Looks good to me.
--
Best regards,
Al
tp://afiskon.ru/s/15/83287ef7d2_malloc.txt
--
Best regards,
Aleksander Alekseev
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
maybe someone knows other procedures besides malloc, realloc
> and strdup that require special attention?
I recalled that there is also calloc(). I've found four places that use
calloc() and look suspicious to me (see attachment). What do you think -
are these bugs or not?
--
Best regards,
look suspicious to me (see attachment). What do you think -
> are these bugs or not?
I've just realized that there is also malloc-compatible ShmemAlloc().
Apparently it's return value sometimes is not properly checked too. See
attachment.
--
Best regards,
Aleksander Alekseev
./sr
up.
>
> And with an actual patch things are better.
Currently I can't think of any further improvements. I even would dare
to say that patch is Ready for Committer.
--
Best regards,
Aleksander Alekseev
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
or paying attention for such issues in PostgreSQL code!
--
Best regards,
Aleksander Alekseev
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
compatibility and
introduce a new procedure ShmemAllocSafe. Also we could add a scary
comment (and also a warning log message?) that ShmemAlloc is deprecated
and possibly will be removed in later releases.
--
Best regards,
Aleksander Alekseev
--
Sent via pgsql-hackers mailing list (pgsq
> Hi Aleksander,
>
> This has already been fixed with commit
> 4f9f495889d3d410195c9891b58228727b340189
>
> Thanks
Agree, it's fixed now. Thank you!
--
Best regards,
Aleksander Alekseev
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> Ok, committed.
>
> - Heikki
Thanks a lot for committing this patch and also for your contribution to
it!
--
Best regards,
Aleksander Alekseev
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Stacktraces are written to src/test/regress/log/initdb.log.
You can add `printf("%d\n", getpid())` and `sleep(1000)` calls somewhere
in main() procedure. It will give you some time to connect using debugger.
IIRC it's what I did.
[1] http://clang.llvm.org/docs/MemorySanitizer.ht
gt;
> I rewrote the comment a bit more and pushed it.
Tom, thank you for committing this patch. And thanks everyone for your
contribution!
--
Best regards,
Aleksander Alekseev
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.
> ^
> fe-connect.c:5239:39: note: put the semicolon on a separate line to
> silence this warning
> 1 warning generated.
8) get_next_element procedure implementation is way too smart (read
"complicated"). You could probably just store current list length and
generate a random number between 0 and length-1.
--
Best regards,
Aleksander Alekseev
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
regards,
Aleksander Alekseev
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
long! I think patches that would make
such code easier to read would have a good chance to be accepted.
In case you are interested I wrote a script that scans PostgreSQL code
and then prints procedures names and corresponding number of lines of
code (see attachment).
--
Best regards,
Aleks
that
describes how this procedure works, what makes you think that it gives a
good distribution in all possible cases (e.g. if there is more than
0x1 elements in a list - why not), etc. Right? :)
--
Best regards,
Aleksander Alekseev
--
Sent via pgsql-hackers mailing list (pgsql-h
appendPQExpBuffer(&conn->errorMessage,
error: src/interfaces/libpq/t/001-multihost.pl: already exists in
working directory
$ git diff
```
--
Best regards,
Aleksander Alekseev
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
de option
> /home/eax/temp/libpq-failover-8.patch:254: trailing whitespace.
>*/
> /home/eax/temp/libpq-failover-8.patch:306: trailing whitespace.
> appendPQExpBuffer(&conn->errorMessage,
> error: src/interfaces/libpq/t/001-multihost.pl: already exists in
> worki
vironments, a not just a hack for single misconfigured
system.
--
Best regards,
Aleksander Alekseev
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hello.
Very simple small patch - see attachment.
--
Best regards,
Aleksander Alekseev
diff --git a/src/backend/access/rmgrdesc/standbydesc.c b/src/backend/access/rmgrdesc/standbydesc.c
index 13797a3..77983e5 100644
--- a/src/backend/access/rmgrdesc/standbydesc.c
+++ b/src/backend/access
f (msg->id == SHAREDINVALRELMAP_ID)
> appendStringInfo(buf, " relmap db %u", msg->rm.dbId);
>
> Looking at inval.c, dbId can be InvalidOid.
Frankly I'm not very familiar with this part of code. InvalidOid is just
zero. Does it create some problem in this case?
--
Best regards,
Alek
t;test_pkey"
[3227] DETAIL: Key (k)=(k1) already exists.
[3176] LOG: worker process: logical replication worker for subscription 16402
(PID 3227) exited with exit code 1
```
What do you think?
--
Best regards,
Aleksander Alekseev
signature.asc
Description: PGP signature
.. ok
```
After:
```
t/001_rep_changes.pl .. ok
t/002_types.pl ok
t/003_constraints.pl .. ok
t/004_sync.pl . ok
t/005_encoding.pl . ok
t/006_rewrite.pl .. ok
t/007_ddl.pl .. ok
All tests successful.
```
--
Best regards,
Aleksander Alekseev
diff --g
t. Such behavior is
obviously a bug. So as an alternative we could just return an error in
response to ALTER TABLE ... ENABLE REPLICA TRIGGER query for triggers
that we know will never be executed.
--
Best regards,
Aleksander Alekseev
signature.asc
Description: PGP signature
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hello Anthony,
Great job!
I decided to take a closer look o
what
authorization method was chosen.
Suggested patch (first of many, I hope) renames `md5Salt` to more
general `pwsalt`.
Does it sound reasonable?
--
Best regards,
Aleksander Alekseev
diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c
index 0ba8530..25bb4c2 100644
--- a/src/backe
xes Makefile. On some systems (notably FreeBSD) there is
no `gcc` by default. Using `cc` is a more crossplatform way to compile a
project.
--
Best regards,
Aleksander Alekseev
diff --git a/pg_filedump.c b/pg_filedump.c
index 2f2cd53..ba55711 100644
--- a/pg_filedump.c
+++ b/pg_filedump.c
@@ -991,7 +99
27;;
LOG: statement: 111aaa
LOG: statement: 222bbb
```
--
Best regards,
Aleksander Alekseev
diff --git a/src/backend/commands/copy.c b/src/backend/commands/copy.c
index 5947e72..82b3a18 100644
--- a/src/backend/commands/copy.c
+++ b/src/backend/commands/copy.c
@@ -331,6 +331
application
that uses COPY and you don't have access to or something like this.
It could also be useful in some other cases.
This feature is very simple and easy to maintain. I'm sure we could find
a solution that will make happy both developers and users.
--
Best regards,
Aleksan
ose. For instance, if DBMS is provided as
a service.
Currently PostgreSQL allows to record all workload _except_ COPY
queries. Considering how easily it could be done I think it's wrong.
Basically the only real question here is how it should look like in
postgresql.conf.
--
Best regards,
Aleksander Alekseev
signature.asc
Description: PGP signature
y the only real question here is how it should look like in
> postgresql.conf.
OK, how about introducing a new boolean parameter named log_copy?
Corresponding patch is attached.
--
Best regards,
Aleksander Alekseev
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 8c25b45.
27;s not a case currently.
[1] https://github.com/postgrespro/sr_plan
--
Best regards,
Aleksander Alekseev
signature.asc
Description: PGP signature
I have is: do we really want to have
> password_encryption being set to "scram" for verifiers of
> SCRAM-SHA-256? I would think that scram_sha_256 makes the most sense.
> Who knows, perhaps there could be in a couple of years a SHA-SHA-512..
>
> At the same time, attach
Speaking about flaws, it looks like there is a memory leak in
array_to_utf procedure - result is allocated twice.
On Mon, Feb 20, 2017 at 02:51:13PM +0300, Aleksander Alekseev wrote:
> Hi!
>
> Currently I don't see any significant flaws in these patches. However I
> would li
and strdup calls)
* scram_Normalize doesn't check malloc return value
Sorry for lots of emails.
On Mon, Feb 20, 2017 at 03:15:14PM +0300, Aleksander Alekseev wrote:
> Speaking about flaws, it looks like there is a memory leak in
> array_to_utf procedure - result is allocated twice.
>
we could easily deal with:
```
xloginsert.c:742:18: warning: implicit conversion from 'int' to 'char'
changes value from 253 to -3 [-Wconstant-conversion]
```
Patch that fixes these warnings is attached to this email.
[1] http://lists.llvm.org/pipermail/cfe-dev/2016-March/048126.html
--
B
In theory - could we just always use our internal strl* implementations?
On Mon, Feb 20, 2017 at 09:26:44AM -0500, Tom Lane wrote:
> Aleksander Alekseev writes:
> > I've just tried to build PostgreSQL with Clang 3.9.1 (default version
> > currently available in Arch Linux)
1] http://afiskon.ru/s/e3/5f47af9102_benchmark.txt
[2] http://afiskon.ru/s/00/2008c4ae66_temp.png
[3] http://afiskon.ru/s/23/650f0afc89_stack.txt
[4] http://afiskon.ru/s/03/a7e685a4db_stack2.txt
--
Best regards,
Aleksander Alekseev
signature.asc
Description: PGP signature
/* list of expressions in the partition
> key;
>* one item for
> each zero entry in partattrs[] */
> #endif
> +
> +
> } FormData_pg_partitioned_table;
>
> /* ----
> @@ -62,13 +67,15 @
ion.diffs.txt
[2] http://afiskon.ru/s/76/a4fb71739c_full-build.sh.txt
On Wed, Mar 01, 2017 at 06:10:10PM +0900, Yugo Nagata wrote:
> Hi Aleksander,
>
> On Tue, 28 Feb 2017 18:05:36 +0300
> Aleksander Alekseev wrote:
>
> > Hi, Yugo.
> >
> > Looks like a great feature! I&#x
making the DETACH/ATTACH manipulation, though. But IMO it's not flexible
> case.
>
> It would be a good thing if a regular table could be partitioned through
> separate command. Then your idea would not be restrictive.
>
>
> --
> Maksim Milyutin
> Postgr
sure that this code is
test covered. An exact script I'm using could be found here [1].
[1] https://github.com/afiskon/pgscripts/blob/master/code-coverage.sh
On Wed, Mar 01, 2017 at 10:36:24AM +0900, Amit Langote wrote:
> Hi,
>
> On 2017/02/28 23:25, Aleksander Alekseev wrote:
&g
tion.
Agree, fixed.
On Mon, Mar 06, 2017 at 12:01:50PM -0800, Andres Freund wrote:
> Hi,
>
> This issue has bothered me in non-partitioned use-cases recently, so
> thanks for taking it up.
>
>
> On 2017-03-06 18:22:17 +0300, Aleksander Alekseev wrote:
> > diff --g
could be done here as well then.
On Tue, Mar 07, 2017 at 10:55:12AM +0900, Amit Langote wrote:
> Hi Aleksander,
>
> On 2017/03/07 0:22, Aleksander Alekseev wrote:
> > Hello.
> >
> > OK, here is a patch.
> >
> > Benchmark, before:
> >
> > ``
> noticed this in your patch:
>
> > * Add a corespinding entry to pgStatTabHash.
>
> "corresponding"
>
> Also a question: Some one-line comments are
>
> /* Comment. */
>
> while others are
>
> /*
> * Comment.
> */
>
> Why the di
needed and the value compatibility is checked by the compiler? I
> > guess there would be some more changes (question is how much), but it
> > would be cleaner.
>
> There's been no discussion or new patch on this thread recently. If you
> are planning to address the issue
xactly what I would call a solution. For instance on FreeBSD
Clang is a default compiler and many users build a software from source
code (FreeBSD ports). For some reason I doubt that many of them know
about these flags.
On Wed, Mar 15, 2017 at 02:25:38AM +, Noah Misch wrote:
> On Mon, Mar
d?
[1] https://wiki.postgresql.org/wiki/Valgrind
[2] http://afiskon.ru/s/8a/390698e914_valgrind.tgz
[3] http://afiskon.ru/s/09/c4f6231679_pgvg.txt
[4] https://github.com/afiskon/pgscripts/blob/master/quick-build.sh
[5] https://github.com/afiskon/pgscripts/blob/master/valgrind.sh
--
Best regards,
Aleksan
)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
--
Best regards,
Aleksander Alekseev
diff --git a/src/backend/postmaster/pgstat.c b/src/backend/postmaster/pgstat.c
index 7cacb1e9b2..a22a5a37c8 100644
--- a/src/backend/postmaster/pgstat.c
+++ b/src/bac
1 - 100 of 229 matches
Mail list logo
