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.
Though
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 writte
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 t
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 Sarkuni
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 reproduced
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) >= FirstNormalObj
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 h
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
> DecodingContextFindStartpoin
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 defined
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 wr
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 imp
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 Pryzb
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 to
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 this
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 yokoha
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 static
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 dum
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 then
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 that
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 algorith
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
Takay
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 wit
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 in
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 g
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 used,
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:
>> postgr
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
