Hi Ashutosh:
Thanks for your time.
On Fri, Feb 7, 2020 at 11:54 PM Ashutosh Bapat
wrote:
> Hi Andy,
> What might help is to add more description to your email message like
> giving examples to explain your idea.
>
> Anyway, I looked at the testcases you added for examples.
> +create table sel
On Sat, 8 Feb 2020 at 03:24, Andres Freund wrote:
>
> Hi,
>
> On 2020-02-07 20:44:31 +0900, Masahiko Sawada wrote:
> > Yeah I'm not going to use pgcrypto for transparent data encryption.
> > The KMS patch includes the new basic infrastructure for cryptographic
> > functions (mainly AES-CBC). I'm t
Hi hackers, attached is a proof of concept patch adding a new base type
called "rational" to represent fractions. It includes arithmetic,
simplification, conversion to/from float, finding intermediates with a
stern-brocot tree, custom aggregates, and btree/hash indices.
The primary motivation was
On Sat, Feb 8, 2020 at 5:05 AM Chapman Flack wrote:
>
> On 2/7/20 2:55 PM, Andres Freund wrote:
>
> >> If the file needs to have 0600 permissions, should there be
> >> a note in the nonexclusive-mode backup docs to say so?
> >
> > I'm not convinced that that's useful. The default is that everythin
Hi,
I am migrating my applications that use postgres client from msvc 2010
(32bits) to msvc 2019 (32 bits).
Compilation using msvc 2019 (64 bits), works very well.
But the build using msvc 2019 (32 bit) is not working.
The 32-bit Platform variable is set to x86, resulting in the first error.
"Proj
Hi.
UNION query problem.(server crash)
When creating an INCREMENTAL MATERIALIZED VIEW,
the server process crashes if you specify a query with a UNION.
(commit id = 23151be7be8d8f8f9c35c2d0e4e5353aedf2b31e)
execute log.
```
[ec2-user@ip-10-0-1-10 ivm]$ psql testdb -e -f union_query_crash.sql
DR
After looking more closely at these modules, I'm kind of inclined
*not* to put the trusted marker on intagg. That module is just
a backwards-compatibility wrapper around functionality that
exists in the core code nowadays. So I think what we ought to be
doing with it is deprecating and eventually
On Tue, Feb 04, 2020 at 01:58:20PM +0900, Masahiko Sawada wrote:
> Here is the comment for v16 patch:
>
> 2.
> I think we can set the error context for heap scan again after
> freespace map vacuum finishing, maybe after reporting the new phase.
> Otherwise the user will get confused if an error oc
Hi,
I'm currently fighting with a race I'm observing in about 1/4 of the
runs. I get:
@@ -361,16 +361,18 @@
locktype mode granted
speculative tokenShareLock f
speculative tokenExclusiveLock t
step controller_unlock_2_4: SELECT pg_advisory_unlock(2, 4);
pg_advisory_unloc
Daniel Gustafsson writes:
> My name is misspelled master 7d0bcb047 s/Gustaffson/Gustafsson/. Nothing else
> stood out from skimming the diff.
Ah, looks like I copied and pasted that from the commit log. Sorry,
will fix in next draft.
regards, tom lane
Peter Eisentraut writes:
> On 2020-02-03 20:32, Tom Lane wrote:
>> This is showing us at least two distinct problems. Now as for
>> "gtest30_1", what we have is that in the parent table "gtest30", column b
>> exists but it has no default; the generated property is only added
>> at the child table
> On 7 Feb 2020, at 22:56, Tom Lane wrote:
> Please send comments before Sunday.
My name is misspelled master 7d0bcb047 s/Gustaffson/Gustafsson/. Nothing else
stood out from skimming the diff.
cheers ./daniel
See
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=388d4351f78dfa6082922074127d496e6f525033
(Note: these cover through 9710d3d4a, but not the additional partitioning
fix I see Alvaro just pushed.)
Please send comments before Sunday.
regards, tom lane
On Fri, Feb 07, 2020 at 03:22:12PM +, Alexey Bashtanov wrote:
Hello,
It took me a while to figure out what those names mean. "unfetched",
as you call it on the code, may be more descriptive than "avoided" for
the new label. However I think the other two are more confusing. It
may be a go
On Sat, Feb 8, 2020 at 10:00 AM Thomas Munro wrote:
> On Tue, Jan 21, 2020 at 1:45 PM Thomas Munro wrote:
> > Here are some patches to get rid of frequent system calls.
>
> Here is one more case that I was sitting on because I wasn't sure how
> to do it: walreceiver.c. To make that work, libpq n
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2020-02-07 14:56:47 -0500, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> > > Maybe that's looking too far into the future, but I'd like to see
> > > improvements to pg_basebackup that make it integrate with root r
On Tue, Jan 21, 2020 at 1:45 PM Thomas Munro wrote:
> Here are some patches to get rid of frequent system calls.
Here is one more case that I was sitting on because I wasn't sure how
to do it: walreceiver.c. To make that work, libpq needs to be able to
tell you when the socket has changed, which
Hi,
On 2020-02-07 14:56:47 -0500, Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
> > Maybe that's looking too far into the future, but I'd like to see
> > improvements to pg_basebackup that make it integrate with root requiring
> > tooling, to do more efficient base backups. E.
On 2/7/20 2:55 PM, Andres Freund wrote:
>> If the file needs to have 0600 permissions, should there be
>> a note in the nonexclusive-mode backup docs to say so?
>
> I'm not convinced that that's useful. The default is that everything
> needs to be writable by postgres. The exceptions should be no
Greetings,
(Moving to -hackers, changing thread title)
* Andres Freund (and...@anarazel.de) wrote:
> Maybe that's looking too far into the future, but I'd like to see
> improvements to pg_basebackup that make it integrate with root requiring
> tooling, to do more efficient base backups. E.g. havi
Hi,
On 2020-02-07 11:08:48 -0500, Chapman Flack wrote:
> Just saw this in a PG 11.6 cluster starting a recovery:
>
> 2020-02-07 10:45:40 EST FATAL: 42501: could not open file
> "backup_label": Permission denied
> 2020-02-07 10:45:40 EST LOCATION: fsync_fname_ext, fd.c:3531
Well, we generally a
Hi,
On 2020-02-07 20:02:01 +0100, Tomas Vondra wrote:
> On Fri, Feb 07, 2020 at 10:33:48AM -0800, Andres Freund wrote:
> > Hi,
> >
> > On 2020-02-04 10:15:01 +0530, Kuntal Ghosh wrote:
> > > And, the issue got reproduced with the same error:
> > > WARNING: problem in Generation Tuples: number of
Hi,
On 2020-01-11 23:20:56 -0500, Tom Lane wrote:
> Tomas Vondra writes:
> Nah, don't think I believe that: the test inserts a bunch of tuples,
> but they look like they will all be *exactly* the same size.
>
> CREATE TABLE decoding_test(x integer, y text);
> ...
>
> FOR i IN 1..10 LOOP
>
On Fri, Feb 07, 2020 at 10:33:48AM -0800, Andres Freund wrote:
Hi,
On 2020-02-04 10:15:01 +0530, Kuntal Ghosh wrote:
And, the issue got reproduced with the same error:
WARNING: problem in Generation Tuples: number of free chunks 0 in
block 0x7fe9e9e74010 exceeds 1018 allocated
That seems lik
On Thu, 6 Feb 2020 at 09:44, Amit Kapila wrote:
>
> On Thu, Feb 6, 2020 at 1:57 AM Mahendra Singh Thalor
wrote:
> >
> > On Wed, 5 Feb 2020 at 12:07, Masahiko Sawada
wrote:
> > >
> > > On Mon, Feb 3, 2020 at 8:03 PM Amit Kapila
wrote:
> > > >
> > > > On Tue, Jun 26, 2018 at 12:47 PM Masahiko Saw
Hi,
On 2020-02-04 10:15:01 +0530, Kuntal Ghosh wrote:
> I performed the same test in pg11 and reproduced the issue on the
> commit prior to a4ccc1cef5a04 (Generational memory allocator).
>
> ulimit -s 1024
> ulimit -v 30
>
> wal_level = logical
> max_replication_slots = 4
>
> [...]
> After
pá 7. 2. 2020 v 18:28 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 07.02.2020 18:15, Robert Haas wrote:
> > On Wed, Feb 5, 2020 at 10:48 AM Konstantin Knizhnik
> > wrote:
> > My answer is - yes.
> >> Just because:
> >> - Such behavior is compatible with regular tab
Hi,
On 2020-02-04 10:15:01 +0530, Kuntal Ghosh wrote:
> And, the issue got reproduced with the same error:
> WARNING: problem in Generation Tuples: number of free chunks 0 in
> block 0x7fe9e9e74010 exceeds 1018 allocated
That seems like a problem in generation.c - because this should be
unreacha
Hi,
On 2020-02-07 09:44:34 +0100, Antonin Houska wrote:
> Those Gather nodes still have non-zero num_workers, see this part of
> standard_planner:
>
> if (force_parallel_mode != FORCE_PARALLEL_OFF && top_plan->parallel_safe)
> {
> ...
> gather->num_workers = 1;
> gather-
Hi,
On 2020-02-07 20:44:31 +0900, Masahiko Sawada wrote:
> Yeah I'm not going to use pgcrypto for transparent data encryption.
> The KMS patch includes the new basic infrastructure for cryptographic
> functions (mainly AES-CBC). I'm thinking we can expand that
> infrastructure so that we can also
Hi,
On 2020-02-07 17:17:21 +0900, Amit Langote wrote:
> I did some tests using two relatively recent compilers: gcc 8 and
> clang-7 and here are the results:
Hm, these very much look like they've been done in an unoptimized build?
> 40.62% postgres postgres [.] ExecInterpExpr
>
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 first
On Fri, Feb 7, 2020 at 12:28 PM Konstantin Knizhnik
wrote:
> But in any case, if we agree that we can control thus behavior using GUC
> or index property,
> then it is ok for me.
Nope, I am not going to agree to that, and I don't believe that any
other committer will, either.
--
Robert Haas
Ent
Fix GTT index initialization.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/contrib/pg_prewarm/pg_prewarm.c b/contrib/pg_prewarm/pg_prewarm.c
index 33e2d28..93059ef 100644
--- a/contrib/pg_prewarm/pg_prewarm.c
+++ b/contrib/pg_
Late last year, I did some work to make it possible to use simplehash
in frontend code.[1] However, a hash table is not much good unless one
also has some hash functions that one can use to hash the keys that
need to be inserted into that hash table. I initially thought that
solving this problem wa
On 07.02.2020 18:15, Robert Haas wrote:
On Wed, Feb 5, 2020 at 10:48 AM Konstantin Knizhnik
wrote:
My answer is - yes.
Just because:
- Such behavior is compatible with regular tables. So it will not
confuse users and doesn't require some complex explanations.
- It is compatible with Oracle.
On Tue, Jan 3, 2017 at 1:05 PM Peter Eisentraut
wrote:
>
> On 11/7/16 5:31 PM, Merlin Moncure wrote:
> > Regardless, it seems like you might be on to something, and I'm
> > inclined to patch your change, test it, and roll it out to production.
> > If it helps or at least narrows the problem down,
> On Thu, Feb 06, 2020 at 09:22:20PM +0900, Kyotaro Horiguchi wrote:
> At Thu, 6 Feb 2020 11:57:07 +0100, Dmitry Dolgov <9erthali...@gmail.com>
> wrote in
> > > On Thu, Feb 06, 2020 at 10:24:50AM +0900, Kyotaro Horiguchi wrote:
> > > At Wed, 5 Feb 2020 17:37:30 +0100, Dmitry Dolgov <9erthali...@g
Hi
rebase
Regards
Pavel
0002-transactional-variables-20200207.patch.gz
Description: application/gzip
0001-schema-variables-20200207.patch.gz
Description: application/gzip
Just saw this in a PG 11.6 cluster starting a recovery:
2020-02-07 10:45:40 EST FATAL: 42501: could not open file
"backup_label": Permission denied
2020-02-07 10:45:40 EST LOCATION: fsync_fname_ext, fd.c:3531
The label file was written with mode 0400 by a script that got
the contents from pg_st
Hi Andy,
What might help is to add more description to your email message like
giving examples to explain your idea.
Anyway, I looked at the testcases you added for examples.
+create table select_distinct_a(a int, b char(20), c char(20) not null, d
int, e int, primary key(a, b));
+set enable_mer
Hello,
It took me a while to figure out what those names mean. "unfetched",
as you call it on the code, may be more descriptive than "avoided" for
the new label. However I think the other two are more confusing. It
may be a good idea to change them together with this.
It'll be sad if this pa
On Wed, Feb 5, 2020 at 4:49 AM Antonin Houska wrote:
> I can't figure out why ExecGather/ExecGatherMerge do check whether num_workers
> is non-zero. I think the code would be a bit clearer if these tests were
> replaced with Assert() statements, as the attached patch does.
Hmm. There are some cas
On Wed, Feb 5, 2020 at 10:48 AM Konstantin Knizhnik
wrote:
> > I don't understand. A global temporary table, as I understand it, is a
> > table for which each session sees separate contents. So you would
> > never need to populate it with existing data.
> Session 1:
> create global temp table gtt(
> > 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 first.
>
> I'd first like to see some actual evi
On Thu, Feb 06, 2020 at 02:24:47PM -0300, Alvaro Herrera wrote:
> On 2020-Feb-06, Justin Pryzby wrote:
>
> > I wondered if it wouldn't be better if CLUSTER ON was stored in pg_class as
> > the
> > Oid of a clustered index, rather than a boolean in pg_index.
>
> Maybe. Do you want to try a patch
On Wed, Feb 5, 2020 at 10:23 PM Andres Freund wrote:
> I still don't get what reason there is to not use T_MemoryContext as the
> magic number, instead of something randomly new. It's really not
> problematic to expose those numerical values. And it means that the
> first bit of visual inspection
> Fwiw, also tried the patch that Kuroda-san had posted yesterday.
I run the same test case too:
clang version 7.0.0:
HEAD 2548.119 ms
with patch 2320.974 ms
clang version 8.0.0:
HEAD 2431.766 ms
with patch 2419.439 ms
clang version 9.0.0:
HEAD 2477.493 ms
with patch 2365.509 ms
gcc version
On Fri, Feb 7, 2020 at 10:09 PM Fujii Masao wrote:
> Pushed! Thanks!
Thanks Fujii.
--
Tatsuhito Kasahara
kasahara.tatsuhito _at_ gmail.com
On Wed, Feb 5, 2020 at 10:09 PM Andres Freund wrote:
> I wasn't advocating for making plannodes.h etc frontend usable. I think
> that's a fairly different discussion than making enum NodeTag,
> pg_list.h, memutils.h available. I don't see them having access to the
> numerical value of node tag fo
Hello
Patch ba79cb5 (for full discussion see [1]) introduces a feature to log
bind parameter values on error,
which greatly helps to reproduce errors artificially having only server
log -- thanks everyone who
reviewed and improved it!
However, it cuts the values, as some of the reviewers were
On 2020/02/07 17:28, Kasahara Tatsuhito wrote:
Hi,
On Fri, Feb 7, 2020 at 5:02 PM Fujii Masao wrote:
BTW, commit 147e3722f7 causing the issue changed currtid_byreloid()
and currtid_byrelname() so that they also call table_beginscan().
I'm not sure what those functions are, but probably we s
On Thu, Feb 6, 2020 at 3:55 AM Mark Dilger wrote:
> The patches apply and pass all tests. A review of the patch vs. master looks
> reasonable.
Thanks for the review!
> The partition_join.sql test has multiple levels of partitioning, but when
> your patch extends that test with “advanced parti
On Thu, Feb 6, 2020 at 2:03 AM Mark Dilger wrote:
> > On Feb 5, 2020, at 4:51 AM, Etsuro Fujita wrote:
> >> On Tue, Jan 28, 2020 at 1:39 PM Mark Dilger
> >> wrote:
> >>> I have added tests checking correctness and showing some partition
> >>> pruning limitations. Find three patches, attached.
On Tue, Feb 4, 2020 at 2:40 PM Amit Kapila wrote:
>
> I don't think we can just back-patch that part of code as it is linked
> to the way we are maintaining a cache (~8MB) for frequently allocated
> objects. See the comments around the definition of
> max_cached_tuplebufs. But probably, we can d
On Fri, 7 Feb 2020 at 11:36, Andres Freund wrote:
>
> Hi,
>
> On 2020-02-07 11:18:29 +0900, Masahiko Sawada wrote:
> > Another idea we discussed is to internally integrate pgcrypto with the
> > key management system.
>
> Perhaps this has already been discussed (I only briefly looked): I'd
> strong
On Fri, Feb 07, 2020 at 01:00:00PM +1300, Thomas Munro wrote:
> Hello,
>
> Here's a rebase of a refactoring patch that got lost behind a filing
> cabinet on another thread even though there seemed to be some
> agreement that we probably want something like this[1]. It introduces
> a new type Segme
On Wed, Feb 5, 2020 at 4:05 PM Amit Kapila wrote:
>
> On Wed, Feb 5, 2020 at 9:46 AM Dilip Kumar wrote:
> >
> > Fixed in the latest version sent upthread.
> >
>
> Okay, thanks. I haven't looked at the latest version of patch series
> as I was reviewing the previous version and I think all of the
On Thu, Feb 06, 2020 at 02:59:09PM -0500, Robert Haas wrote:
> On Wed, Feb 5, 2020 at 9:32 AM Julien Rouhaud wrote:
> > There's also the possibility to reserve 1 bit of the hash to know if
> > this is a utility command or not, although I don't recall right now
> > all the possible issues with util
Hello Hackers,
While working on some issue in logical decoding, I found some
inconsistencies in the comment for defining max_cached_tuplebufs in
reorderbuffer.c. It only exists till PG10 because after that the
definition got removed by the generational memory allocator patch. The
variable is defin
Richard Guo wrote:
> Hi,
>
> I've been looking at the 'make_join_rel()' part of the patch, and I'm
> aware that, if we are joining A and B, a 'grouped join rel (AB)' would
> be created besides the 'plain join rel (AB)', and paths are added by 1)
> applying partial aggregate to the paths of the '
Fwiw, also tried the patch that Kuroda-san had posted yesterday.
On Fri, Feb 7, 2020 at 5:17 PM Amit Langote wrote:
> Latency and profiling results:
>
> gcc 8 (gcc (GCC) 8.3.1 20190311 (Red Hat 8.3.1-3))
>
>
> 11.6
>
> latency average = 463.968 ms
>
> 40.62% postgres postgres
Andres Freund wrote:
> Hi,
>
> On 2020-02-05 10:50:05 +0100, Antonin Houska wrote:
> > I can't figure out why ExecGather/ExecGatherMerge do check whether
> > num_workers
> > is non-zero. I think the code would be a bit clearer if these tests were
> > replaced with Assert() statements, as the at
On Fri, Feb 7, 2020 at 2:24 AM Alvaro Herrera wrote:
> On 2020-Feb-06, Justin Pryzby wrote:
> > I wondered if it wouldn't be better if CLUSTER ON was stored in pg_class as
> > the
> > Oid of a clustered index, rather than a boolean in pg_index.
>
> Maybe. Do you want to try a patch?
+1
Thanksm
At Fri, 7 Feb 2020 17:01:59 +0900, Fujii Masao
wrote in
>
>
> On 2020/02/07 15:07, Kasahara Tatsuhito wrote:
> > Hi,
> > On Fri, Feb 7, 2020 at 1:27 PM Kyotaro Horiguchi
> > wrote:
> >> It seems that nkeys and key are useless. Since every table_beginscan_*
> >> functions have distinct paramet
Hi,
On Fri, Feb 7, 2020 at 5:02 PM Fujii Masao wrote:
> BTW, commit 147e3722f7 causing the issue changed currtid_byreloid()
> and currtid_byrelname() so that they also call table_beginscan().
> I'm not sure what those functions are, but probably we should fix them
> so that table_beginscan_tid()
On Fri, Apr 12, 2019 at 1:44 PM Michael Paquier wrote:
>
> On Thu, Apr 11, 2019 at 02:06:13PM -0400, Tom Lane wrote:
> > Yeah, if we could simplify the tableam API, that would be sufficient
> > reason to remove the stuff in v12, IMO. But if it is outside of that
> > API, I'd counsel waiting till
On Fri, Feb 7, 2020 at 4:54 PM Andres Freund wrote:
> On February 6, 2020 11:42:30 PM PST, keisuke kuroda
> wrote:
> >Hi,
> >
> >I have been testing with newer compiler (clang-7)
> >and result is a bit different at least with clang-7.
> >Compiling PG 12.1 (even without patch) with clang-7
> >res
On 2020/02/07 15:07, Kasahara Tatsuhito wrote:
Hi,
On Fri, Feb 7, 2020 at 1:27 PM Kyotaro Horiguchi
wrote:
It seems that nkeys and key are useless. Since every table_beginscan_*
functions have distinct parameter sets, don't we remove them from
table_beginscan_tid?
Yeah, actually, when call
69 matches
Mail list logo
