Hi,
I found that pg_basebackup -F plain -R *overwrites* postgresql.auto.conf
taken from the primary server with new primary_conninfo setting,
while pg_basebackup -F tar -R just *appends* it into the file. I think that
this is a bug and pg_basebackup -F plain -R should *append* the setting.
On Fri, Feb 7, 2020 at 11:43 PM 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
On Wed, 5 Feb 2020 at 21:36, Kirill Bychik wrote:
>
> Hello pgsql-hackers,
>
> Submitting a patch that would enable gathering of per-statement WAL
> generation statistics, similar to how it is done for buffer usage.
> Collected is the number of records added to WAL and number of WAL
> bytes
Hello Stephen,
From: Stephen Frost
> I disagree- it's a feature that's been asked for multiple times and does
> have value in some situations.
I'm rethinking the need for this feature although I think that it improves the
security.
You said that this feature has value in some situations.
Could
On Mon, Feb 10, 2020 at 11:55:09AM +0800, Craig Ringer wrote:
> I don't see any other members building for 32-bit. But it should work
> and as you say, nothing's been discussed about removing it.
Yes, it works normally AFAIK and there is no reason to remove this
support either. My guess is that
On Wed, 5 Feb 2020 at 22:28, Sehrope Sarkuni wrote:
>
> On Sat, Feb 1, 2020 at 7:02 PM Masahiko Sawada
> wrote:
> > On Sun, 2 Feb 2020 at 00:37, Sehrope Sarkuni wrote:
> > >
> > > On Fri, Jan 31, 2020 at 1:21 AM Masahiko Sawada
> > > wrote:
> > > > On Thu, 30 Jan 2020 at 20:36, Sehrope
On Mon, Feb 10, 2020 at 2:23 PM Masahiko Sawada
wrote:
> On Mon, 10 Feb 2020 at 14:09, Michael Paquier wrote:
> >
> > On Mon, Feb 10, 2020 at 01:16:30PM +0900, Amit Langote wrote:
> > > On Mon, Feb 10, 2020 at 1:06 PM Masahiko Sawada
> > > wrote:
> > >> How about having it as a macro like:
> >
Hello,
On Sat, Feb 8, 2020 at 1:18 AM Andres Freund wrote:
>
> 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
On Mon, 10 Feb 2020 at 14:09, Michael Paquier wrote:
>
> On Mon, Feb 10, 2020 at 01:16:30PM +0900, Amit Langote wrote:
> > On Mon, Feb 10, 2020 at 1:06 PM Masahiko Sawada
> > wrote:
> >> How about having it as a macro like:
> >>
> >> #define ObjectIdIsUserObject(oid) ((Oid)(oid) >=
On Sat, Feb 8, 2020 at 3:13 AM Andres Freund wrote:
> 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?
>
> >
On Mon, Feb 10, 2020 at 01:16:30PM +0900, Amit Langote wrote:
> On Mon, Feb 10, 2020 at 1:06 PM Masahiko Sawada
> wrote:
>> How about having it as a macro like:
>>
>> #define ObjectIdIsUserObject(oid) ((Oid)(oid) >= FirstNormalObjectId)
>
> I'm fine with a macro.
I am not sure that it is worth
On Mon, 10 Feb 2020 at 01:29, Arseny Sher wrote:
>
> Hi,
>
> While jumping around partically decoded xacts questions [1], I've read
> through the copy replication slots code (9f06d79ef) and found a couple
> of issues.
>
> 1) It seems quite reckless to me to dive into
>
Hi,
Attached is the latest patch (v13) to add support for Incremental
View Maintenance (IVM). Differences from the previous patch (v12)
include:
* Allow to maintain IMMVs containing user defined types
Previously, IMMVs (Incrementally Maintainable Materialized Views)
containing user
On 2/7/20 8:06 PM, Fujii Masao wrote:
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
On Sun, Feb 09, 2020 at 08:01:26PM -0800, Andres Freund wrote:
> Ugh, that indeed looks wrong. Did you check whether it can actively
> cause wrong query results? If so, did you do theoretically, or got to a
> query returning wrong results?
Actually .. I can "theoretically" prove that there's no
On Thu, 6 Feb 2020 at 11:09, 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 for
On Mon, Feb 10, 2020 at 1:06 PM Masahiko Sawada
wrote:
> On Mon, 10 Feb 2020 at 12:54, Amit Langote wrote:
> >
> > Sawada-san,
> >
> > On Mon, Feb 10, 2020 at 12:25 PM Masahiko Sawada
> > wrote:
> > > > > > On Thu, Feb 06, 2020 at 04:25:47PM +0900, Amit Langote wrote:
> > > > > > > About the
On Mon, 10 Feb 2020 at 12:54, Amit Langote wrote:
>
> Sawada-san,
>
> On Mon, Feb 10, 2020 at 12:25 PM Masahiko Sawada
> wrote:
> > > > > On Thu, Feb 06, 2020 at 04:25:47PM +0900, Amit Langote wrote:
> > > > > > About the implementation, how about defining a static inline
> > > > > > function,
On Fri, Feb 7, 2020 at 9:47 AM Justin Pryzby wrote:
>
> On Fri, Feb 07, 2020 at 09:26:04AM +0530, Amit Kapila wrote:
> > On Fri, Feb 7, 2020 at 8:41 AM Justin Pryzby wrote:
> > >
> > > On Fri, Feb 07, 2020 at 08:33:40AM +0530, Amit Kapila wrote:
> > > > On Thu, Feb 6, 2020 at 7:26 PM Justin
On Sun, Feb 09, 2020 at 08:01:26PM -0800, Andres Freund wrote:
> Ugh, that indeed looks wrong. Did you check whether it can actively
> cause wrong query results? If so, did you do theoretically, or got to a
> query returning wrong results?
No, I only noticed while reading code.
I tried briefly
Hi,
On 2020-02-09 21:25:47 -0600, Justin Pryzby wrote:
> I believe the 2nd hunk should reset node->hashnulls, rather than reset
> ->hashtable a 2nd time:
>
> @@ -505,7 +505,10 @@ buildSubPlanHash(SubPlanState *node, ExprContext
> *econtext)
> if (nbuckets < 1)
> nbuckets
On Sun, 9 Feb 2020 at 15:35, Amit Kapila wrote:
>
> On Sat, Feb 8, 2020 at 8:05 AM Ranier Vilela wrote:
> >
> > 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
Sawada-san,
On Mon, Feb 10, 2020 at 12:25 PM Masahiko Sawada
wrote:
> > > > On Thu, Feb 06, 2020 at 04:25:47PM +0900, Amit Langote wrote:
> > > > > About the implementation, how about defining a static inline function,
> > > > > say is_user_object(), next to FirstNormalObjectId's definition and
Thanks to reviewing those patches.
Ha, I believe you meant to say a "normal aggregate", because what's
> performed above gather is no longer "grouping sets", right?
>
> The group key idea is clever in that it helps "discriminate" tuples by
> their grouping set id. I haven't completely thought
Hi.
I understod that UNION is unsupported.
I also refer to the implementation of "./src/backend/commands/createas.c"
check_ivm_restriction_walker () to see if there are any other queries that
may be problematic.
2020年2月10日(月) 10:38 Yugo NAGATA :
> On Sat, 8 Feb 2020 11:15:45 +0900
> nuko
I believe the 2nd hunk should reset node->hashnulls, rather than reset
->hashtable a 2nd time:
@@ -505,7 +505,10 @@ buildSubPlanHash(SubPlanState *node, ExprContext *econtext)
if (nbuckets < 1)
nbuckets = 1;
- node->hashtable = BuildTupleHashTable(node->parent,
+
On Thu, 6 Feb 2020 at 17:18, Masahiko Sawada
wrote:
>
> On Thu, 6 Feb 2020 at 16:53, Amit Langote wrote:
> >
> > On Thu, Feb 6, 2020 at 4:31 PM Michael Paquier wrote:
> > > On Thu, Feb 06, 2020 at 04:25:47PM +0900, Amit Langote wrote:
> > > > About the implementation, how about defining a
On Sat, 8 Feb 2020 11:15:45 +0900
nuko yokohama wrote:
> Hi.
>
> UNION query problem.(server crash)
>
> When creating an INCREMENTAL MATERIALIZED VIEW,
> the server process crashes if you specify a query with a UNION.
Thank you for your report. As you noticed set operations including
UNION is
Hi Andres,
> Could you expand on what you mean here? Are you saying that you got
> significantly better optimization results by doing function optimization
> early on? That'd be surprising imo?
Sorry for the ambiguity, I meant that I had observed differences in the
sizes
of the bitcode files
Hi Andres,
> I've comitted a (somewhat evolved) version of this patch. I think it
> really improves the code!
Awesome! Thanks for taking it forward!
> I do wonder about adding a variadic wrapper like the one introduced here
> more widely, seems like it could simplify a number of places. If we
On Mon, Feb 10, 2020 at 12:16:44AM +0100, Vik Fearing wrote:
> There is a little bit of overlap within those three groups but among the
> minuscule percentage of our users that responded, the result is
> overwhelmingly in favor of this change.
Thanks Vik for handling that. So, it seems to me
On Mon, Dec 23, 2019 at 5:43 AM Maxence Ahlouche
wrote:
> On Wed, 27 Nov 2019 at 17:09, Tom Lane wrote:
>> Good idea, but I think you need to account for "visible" (ie, if the
>> newline is inside RL_PROMPT_START_IGNORE, it shouldn't change the width).
>> It might be best to add logic inside the
From: Andres Freund
> Perhaps this has already been discussed (I only briefly looked): I'd
> strongly advise against having any new infrastrure depend on
> pgcrypto. Its code quality imo is well below our standards and contains
> serious red flags like very outdated copies of cryptography
On Fri, Jan 31, 2020 at 4:35 PM Craig Ringer wrote:
>
> On Fri, 31 Jan 2020 at 13:27, Michael Paquier wrote:
> >
> > On Fri, Jan 31, 2020 at 12:47:29PM +1030, Andrew Dunstan wrote:
> > > When I was working on the test_json stuff yesterday, I noticed that
> > > there are some unexpected (by me at
From: Jose Luis Tallon
> Musing some other date-related things I stumbled upon the thought
> that naming the upcoming release PostgreSQL 20 might be preferrable to
> the current/expected "PostgreSQL 13".
+1
Users can easily know how old/new the release is that they are using.
Regards
On 06/02/2020 03:56, Vik Fearing wrote:
> On 06/02/2020 03:38, Michael Paquier wrote:
>> On Wed, Feb 05, 2020 at 10:21:11AM -0500, Tom Lane wrote:
>>> Robert Haas writes:
I'm not really against this change but, given how long it's been the
way that it is, I think we shouldn't make it
I kinda suspect one of the ressons why this got so little attention is
that it was never added to any CF.
Thanks Tomas, I've created a CF entry
https://commitfest.postgresql.org/27/2443/
Best, Alex
Jose Luis Tallon writes:
> Musing some other date-related things I stumbled upon the thought
> that naming the upcoming release PostgreSQL 20 might be preferrable to
> the current/expected "PostgreSQL 13".
Sorry, but it's not April 1st yet.
regards, tom lane
On 09/02/2020 19:28, Jose Luis Tallon wrote:
> * Simplified supportability assessment: PostgreSQL 20, released in
> 2020, would be supported until the release of PostgreSQL 25 (late 2025
> if release cadence is kept as today). Simple and straightforward.
How would you handle multiple releases
Hackers,
Musing some other date-related things I stumbled upon the thought
that naming the upcoming release PostgreSQL 20 might be preferrable to
the current/expected "PostgreSQL 13".
Cons:
* Discontinuity in versions. 12 -> 20. Now that we have the precedent
of 9.6 -> 10 (for very
Hi,
While jumping around partically decoded xacts questions [1], I've read
through the copy replication slots code (9f06d79ef) and found a couple
of issues.
1) It seems quite reckless to me to dive into
DecodingContextFindStartpoint without actual WAL reservation (donors
slot restart_lsn is
ne 9. 2. 2020 v 13:05 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 07.02.2020 21:37, Pavel Stehule wrote:
>
>
> What when session 2 has active transaction? Then to be correct, you should
> to wait with index creation to end of transaction.
>
>
>> Session1:
>>
On 07.02.2020 21:37, Pavel Stehule wrote:
What when session 2 has active transaction? Then to be correct, you
should to wait with index creation to end of transaction.
Session1:
postgres=# create unique index on gtt(x);
CREATE INDEX
Sessin2:
postgres=# explain select
43 matches
Mail list logo
