Hello.
While looking a patch, I found that a standby with archive_mode=always
fails to archive segments under certain conditions.
A. Walreceiver is gracefully terminated just after a segment is
finished.
B. Walreceiver is gracefully terminated while receiving filling chunks
for a segment sw
On 2020/06/26 13:45, Amit Kapila wrote:
On Fri, Jun 26, 2020 at 4:54 AM Alvaro Herrera wrote:
On 2020-Jun-26, Michael Paquier wrote:
On Thu, Jun 25, 2020 at 11:24:27AM -0400, Alvaro Herrera wrote:
I don't understand the proposal. Michael posted a patch that adds
pg_wal_oldest_lsn(), and
On Tue, Jun 30, 2020 at 2:54 PM Amit Langote wrote:
> On Tue, Jun 30, 2020 at 1:22 PM Ashutosh Bapat
> wrote:
> > On Tue, 30 Jun 2020 at 08:47, Etsuro Fujita wrote:
> >> On Mon, Jun 29, 2020 at 7:52 PM Ashutosh Bapat
> >> wrote:
> >> > On Sun, Jun 28, 2020 at 8:40 PM Tomas Vondra
> >> > wrote:
On 2020-05-04 07:50, Michael Paquier wrote:
Yeah. The years have visibly proved that the README had updates when
it came to the general descriptions of the libpqwalreceiver interface,
but that we had better consolidate the header to give some
documentation to whoever plays with this interface.
The first commitfest of the v14 cycle, 2020-07 is just around the corner now
and the trend of growing the list of patches has continued, so there is a lot
to go through.
If you have a patch registered in the commitfest, make sure it still applies
and that the tests pass. Looking at the Patch Test
Thanks Vignesh and Rushabh for reviewing this.
I've added this patch to commitfest - https://commitfest.postgresql.org/28/.
Request community take this patch further if there are no further issues.
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com
On Sat, Jun 27, 2020 a
‐‐‐ Original Message ‐‐‐
On Saturday, June 20, 2020 3:15 PM, vignesh C wrote:
> On Tue, Jun 16, 2020 at 6:13 PM Georgios gkokola...@protonmail.com wrote:
>
> > > Few comments:
> > >
> > > - if (pset.sversion >= 12)
> > >
> > > - appendPQExpBufferStr(&buf,
> > >
> > > - "\n LEF
On Mon, Jun 29, 2020 at 7:02 PM Bharath Rupireddy
wrote:
> > It doesn't cost out the plan of pushing the DISTINCT ON down to the foreign
> > side, which is probably the best way to run the query. I guess it makes
> > sense that FDW machinery in general doesn't want to try to push a
> > Postgre
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
The patch looks good to me.
The new status of this patch is: Rea
On 2020-06-30 06:24, David Rowley wrote:
On Tue, 30 Jun 2020 at 16:20, Tom Lane wrote:
There is a fairly widespread issue that memory-size-related GUCs and
suchlike variables are limited to represent sizes that fit in a "long".
Although Win64 is the *only* platform where that's an issue, maybe
On Tue, 30 Jun 2020 at 08:43, Fujii Masao
wrote:
> > The problem looks to be that spinlocks are terrible with overloaded
> CPU and a contended spinlock. A process holding the spinlock might easily
> get scheduled out leading to excessive spinning by everybody. I think a
> simple thing to try woul
On Tue, Jun 30, 2020 at 10:13 AM Dilip Kumar wrote:
>
> On Tue, Jun 30, 2020 at 9:20 AM Amit Kapila wrote:
> >
> > Can't we name the last parameter as 'commit_lsn' as that is how
> > documentation in the patch spells it and it sounds more appropriate?
>
> You are right commit_lsn seems more appro
On Mon, Jun 29, 2020 at 04:56:16PM +0900, Michael Paquier wrote:
> On Fri, Jun 26, 2020 at 02:00:37PM +0200, Peter Eisentraut wrote:
>> We should be more accurate about things like this:
>>
>> +# The following tests test symlinks. Windows may not have symlinks, so
>> +# skip there.
>>
>> The issu
On Fri, Jun 26, 2020 at 09:59:30AM +0900, Michael Paquier wrote:
> Thanks. This list is provided by OBJS_FRONTEND in
> src/common/Makefile, and pgcommonfrontendfiles in Mkvcbuild.pm. Let's
> see if others have comments, as it just looks like something that was
> forgotten in bf5bb2e and fc9a62a w
> On 29 Jun 2020, at 08:57, Michael Paquier wrote:
>
> On Fri, Jun 26, 2020 at 02:26:50PM +0200, Daniel Gustafsson wrote:
>> On 26 Jun 2020, at 10:11, Michael Paquier wrote:
>>> + /* TODO is nreferenced a reasonable allocation of slots? */
>>> + slot = palloc(sizeof(TupleTableSlot *) * nrefe
On Tue, 30 Jun 2020 at 02:17, Madan Kumar wrote:
> We already have pg_xact_commit_timestamp() that returns the timestamp of
> the commit.
Yes, pg_xact_commit_origin() is a good name for an additional function. +1
for this.
> It may be better to have one single function returning both
> times
On 2020/06/30 20:30, Ants Aasma wrote:
On Tue, 30 Jun 2020 at 08:43, Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
> The problem looks to be that spinlocks are terrible with overloaded CPU
and a contended spinlock. A process holding the spinlock might easily get
scheduled out
On 2020/06/30 7:29, Peter Geoghegan wrote:
On Mon, Jun 29, 2020 at 3:23 PM Peter Geoghegan wrote:
+1 -- this regression seems unacceptable to me.
I added an open item to track this.
Thanks!
I'm thinking to change the default value of track_planning to off for v13.
Ants and Andres sugges
This feature adds RESPECT NULLS and IGNORE NULLS syntax to several
window functions, according to the SQL Standard.
Unlike the last time this was attempted[1], my version does not hardcode
the spec's list of functions that this applies to. Instead, it accepts
it for all true window functions (tha
Peter Eisentraut writes:
> There are three subplots:
> 1. Changing the return type of load_external_function() and
> lookup_external_function() from PGFunction to a generic pointer type,
> which is what the discussion in [0] started out about.
I feel like what you propose to do here is just sh
On 2020/06/30 17:07, Fujii Masao wrote:
On 2020/06/26 13:45, Amit Kapila wrote:
On Fri, Jun 26, 2020 at 4:54 AM Alvaro Herrera wrote:
On 2020-Jun-26, Michael Paquier wrote:
On Thu, Jun 25, 2020 at 11:24:27AM -0400, Alvaro Herrera wrote:
I don't understand the proposal. Michael posted
Hi,
When I talked about max_slot_wal_keep_size as new feature in v13
at the conference, I received the question like "Why are the units of
setting values in max_slot_wal_keep_size and wal_keep_segments different?"
from audience. That difference looks confusing for users and
IMO it's better to use
Hello,
You changed the query strings to use "\n" instead of " ". I would not have
changed that, because it departs from the style around, and I do not think
it improves readability at the C code level.
This was the style that was introduced by
daa9fe8a5264a3f192efa5ddee8fb011ad9da365.
Yep
On 2020/06/30 19:54, Asif Rehman wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
The patch looks good
On Tue, Jun 30, 2020 at 12:23:28PM +0900, Masahiko Sawada wrote:
> > I propose to have a new session level GUC called
> > "enable_connectioncache"(name can be changed if it doesn't correctly
> > mean the purpose) with the default value being true which means that
> > all the remote connections are
On 6/28/20 6:00 PM, Tom Lane wrote:
> Joe Conway writes:
>> All good stuff -- I believe the attached checks all the boxes.
>
> Looks okay to me, except I think you want
>
> ! if (bytes_to_read > 0)
>
> to be
>
> ! if (bytes_to_read >= 0)
Yep -- thanks.
I did some performance testing
Vik Fearing writes:
> The second patch adds some new window functions in order to test that
> the null treatment works correctly for cases that aren't covered by the
> standard functions but that custom functions might want to use. It is
> *not* intended to be committed; I am only submitting the
Buildfarm member hyrax has shown this failure twice recently:
---
/home/buildfarm/buildroot/HEAD/pgsql.build/src/test/regress/expected/brin.out
2020-01-23 11:10:05.730014075 -0500
+++
/home/buildfarm/buildroot/HEAD/pgsql.build/src/test/regress/results/brin.out
2020-06-30 03:50:23.
On Mon, Jun 29, 2020 at 04:22:15PM +0530, Ashutosh Bapat wrote:
On Sun, Jun 28, 2020 at 8:40 PM Tomas Vondra
wrote:
FDW batching: 4584 ms
So, rather nice improvement, I'd say ...
Very nice.
Before I spend more time hacking on this, I have a couple open questions
about the design, re
Jeff Janes writes:
> It doesn't cost out the plan of pushing the DISTINCT ON down to the foreign
> side, which is probably the best way to run the query. I guess it makes
> sense that FDW machinery in general doesn't want to try to push a
> PostgreSQL specific construct.
Well, that's an unimplem
This adds support for writing CREATE FUNCTION and CREATE PROCEDURE
statements for language SQL with a function body that conforms to the
SQL standard and is portable to other implementations.
Instead of the PostgreSQL-specific AS $$ string literal $$ syntax,
this allows writing out the SQL stat
On Tue, Jun 30, 2020 at 1:49 PM Peter Eisentraut
wrote:
> This adds support for writing CREATE FUNCTION and CREATE PROCEDURE
> statements for language SQL with a function body that conforms to the
> SQL standard and is portable to other implementations.
With what other implementations is it compa
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> Hmm, this all seems like a pretty big semantic change. IIUC, right
> now, a SQL function can only contain one statement, but it seems like
> with this patch you can have a block in there with a bunch of
> statements, sorta like plpgsql.
Fr
On 2020-Jun-30, Fujii Masao wrote:
> Sorry this is not true. That distance can be calculated without those
> operators.
> For example,
>
> SELECT restart_lsn - pg_current_wal_lsn() + (SELECT setting::numeric * 1024 *
> 1024 FROM pg_settings WHERE name = 'max_slot_wal_keep_size') distance FROM
út 30. 6. 2020 v 19:58 odesílatel Robert Haas
napsal:
> On Tue, Jun 30, 2020 at 1:49 PM Peter Eisentraut
> wrote:
> > This adds support for writing CREATE FUNCTION and CREATE PROCEDURE
> > statements for language SQL with a function body that conforms to the
> > SQL standard and is portable to o
Robert Haas writes:
> On Tue, Jun 30, 2020 at 1:49 PM Peter Eisentraut
> wrote:
>> This adds support for writing CREATE FUNCTION and CREATE PROCEDURE
>> statements for language SQL with a function body that conforms to the
>> SQL standard and is portable to other implementations.
> With what oth
On 2020-Jun-30, Michael Paquier wrote:
> Another question that has popped up when doing this review is what
> would be the use-case of adding this information at SQL level knowing
> that logical replication exists since 10?
Logical replication in core is a far cry from a fully featured
replicatio
I think there are two very large patches here. One adds checking of
heapam tables to amcheck, and the other adds a binary that eases calling
amcheck from the command line. I think these should be two separate
patches.
I don't know what to think of a module contrib/pg_amcheck. I kinda lean
towar
I wrote:
> Replicating the creation-time search path will be a big headache for
> pg_dump, I bet.
On further thought, we probably don't have to. Re-parsing the function
body the same way is exactly the same problem as re-parsing a view or
matview body the same way. I don't want to claim that tha
Hi,
On 2020-06-30 14:43:39 +0900, Fujii Masao wrote:
> > I did a prototype patch that replaces spinlocks with futexes, but was not
> > able to find a workload where it mattered.
>
> I'm not familiar with futex, but could you tell me why you used futex instead
> of LWLock that we already have? Is
Hi,
On 2020-06-30 14:30:03 +0300, Ants Aasma wrote:
> Futex is a Linux kernel call that allows to build a lock that has
> uncontended cases work fully in user space almost exactly like a spinlock,
> while falling back to syscalls that wait for wakeup in case of contention.
> It's not portable, but
Hi,
On 2020-06-30 08:47:56 +0200, Peter Eisentraut wrote:
> Some time ago, there were some discussions about gcc warnings produced by
> -Wcast-function-type [0]. To clarify, while that thread seemed to imply
> that the warnings appear by default in some compiler version, this is not
> the case AF
Hi,
On 2020-06-30 10:15:05 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > There are three subplots:
>
> > 1. Changing the return type of load_external_function() and
> > lookup_external_function() from PGFunction to a generic pointer type,
> > which is what the discussion in [0] started
Hi,
On 2020-06-30 19:49:04 +0200, Peter Eisentraut wrote:
> The function body is parsed at function definition time and stored as
> expression nodes in probin. So at run time, no further parsing is
> required.
As raw parse tree or as a parse-analysed tree? I assume the latter?
Isn't a consequen
Hi,
On 2020-06-29 21:27:48 -0400, Tom Lane wrote:
> I wrote:
> > Andres Freund writes:
> >> The way that pg_bsd_indent defines its variables isn't standard C, as
> >> far as I can tell, which explains the errors I was getting. All the
> >> individual files include indent_globs.h, which declares/d
Andres Freund writes:
> On 2020-06-30 10:15:05 -0400, Tom Lane wrote:
>> I feel like what you propose to do here is just shifting the problem
>> around: we're still casting from a function pointer that describes one
>> concrete call ABI to a function pointer that describes some other concrete
>> c
Andres Freund writes:
> On 2020-06-30 19:49:04 +0200, Peter Eisentraut wrote:
>> The function body is parsed at function definition time and stored as
>> expression nodes in probin. So at run time, no further parsing is
>> required.
> Isn't a consequence of that that we'd get a lot more errors i
> On Jun 30, 2020, at 11:44 AM, Alvaro Herrera wrote:
>
> I think there are two very large patches here. One adds checking of
> heapam tables to amcheck, and the other adds a binary that eases calling
> amcheck from the command line. I think these should be two separate
> patches.
contrib/a
On 12/11/18 5:24 PM, David Steele wrote:
Attached is the patch.
I was a bit surprised by how much code went away. There was a lot of
code dedicated to making sure that backup_label got renamed on shutdown,
that there was not an exclusive backup running, etc.
There were no tests for exclusive
On 2020-Jun-30, Mark Dilger wrote:
> I'm guessing that hardening the backend would be a separate patch? Or
> did you want that as part of this one?
Lately, to me the foremost criterion to determine what is a separate
patch and what isn't is the way the commit message is structured. If it
looks
Greetings,
* David Steele (da...@pgmasters.net) wrote:
> Lastly, there is some concern about getting the backup label too late when
> doing snapshots or using traditional backup software. It would certainly be
> possible to return the backup_label and tablespace_map from
> pg_start_backup() and le
I wrote:
> I poked into that and found that the problem is in estimate_num_groups,
> which effectively just disregards any relation that has rel->tuples = 0.
> That is the case for a postgres_fdw foreign table if use_remote_estimate
> is true, because postgres_fdw never bothers to set any other val
On 6/30/20 6:13 PM, Stephen Frost wrote:
Greetings,
* David Steele (da...@pgmasters.net) wrote:
Lastly, there is some concern about getting the backup label too late when
doing snapshots or using traditional backup software. It would certainly be
possible to return the backup_label and tablespa
On Tue, Jun 30, 2020 at 6:40 AM Fujii Masao wrote:
> Ants and Andres suggested to replace the spinlock used in pgss_store() with
> LWLock. I agreed with them and posted the POC patch doing that. But I think
> the patch is an item for v14. The patch may address the reported performance
> issue, but
On 6/30/20 12:13 AM, Amit Kapila wrote:
> On Mon, Jun 29, 2020 at 8:48 PM Andrew Dunstan
> wrote:
>>
>>
>>
>> It needs to be a path from the Windows POV, not an Msys virtualized
>> path. So c:/tmp or just /tmp should work, but /c/tmp or similar probably
>> will not. The directory needs to exist.
Greetings,
* David Steele (da...@pgmasters.net) wrote:
> On 6/30/20 6:13 PM, Stephen Frost wrote:
> >* David Steele (da...@pgmasters.net) wrote:
> >>Lastly, there is some concern about getting the backup label too late when
> >>doing snapshots or using traditional backup software. It would certain
On Tue, Jun 30, 2020 at 07:10:46PM -0400, Stephen Frost wrote:
> De-deprecating the exclusive backup mode and returning that info at the
> start and telling users "put this anywhere EXCEPT this specific place,
> and make sure you DO put these files in that exact place when you
> restore" would perh
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Jun 30, 2020 at 07:10:46PM -0400, Stephen Frost wrote:
> > De-deprecating the exclusive backup mode and returning that info at the
> > start and telling users "put this anywhere EXCEPT this specific place,
> > and make sure you DO put
Hello,
Melanie and me will be posting a separate thread with the scanCols patch
listed here, a patch to capture the set of cols in RETURNING and a group
of patches to pass down the list of cols to various table AM functions
together as a patch set. This will take some time. Thus, we are
deregister
Attached is a POC patch that teaches nbtree to delete old duplicate
versions from unique indexes. The optimization targets non-HOT
duplicate version bloat. Although the patch is rather rough, it
nevertheless manages to more or less eliminate a whole class of index
bloat: Unique index bloat from non
At Tue, 30 Jun 2020 23:51:40 +0900, Fujii Masao
wrote in
> Hi,
>
> When I talked about max_slot_wal_keep_size as new feature in v13
> at the conference, I received the question like "Why are the units of
> setting values in max_slot_wal_keep_size and wal_keep_segments
> different?"
> from audie
On Thu, 25 Jun 2020 at 21:15, David Rowley wrote:
> I've attached a small patch that changes the Hash Aggregate behaviour
> to always show these properties for non-text formats.
I've pushed this change for HashAgg only and marked the open item as
completed for hash agg. I'll leave it up to Justi
On Tue, Jun 30, 2020 at 07:32:47PM -0400, Stephen Frost wrote:
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Tue, Jun 30, 2020 at 07:10:46PM -0400, Stephen Frost wrote:
> > > De-deprecating the exclusive backup mode and returning that info at the
> > > start and telling users "
At Tue, 30 Jun 2020 23:23:30 +0900, Fujii Masao
wrote in
> >> Can we consider an option to "Remove min_safe_lsn; document how a user
> >> can monitor the distance"? We have a function to get current WAL
> >> insert location and other things required are available either via
> >> view or as guc
On Tue, Jun 30, 2020 at 01:13:39PM +0900, Michael Paquier wrote:
> I looked at the patch, and can confirm that client_wrongperms_tmp.key
> remains around after running 001_ssltests.pl, and client_tmp.key after
> running 002_scram.pl. The way the patch does its cleanup looks fine
> to me, so I'll a
Hi,
While working on 40efbf870 I noticed that when performing a Hash Join
that we always start out by setting nbatch to 1. That seems
reasonable as it's hard to imagine being able to complete any non-zero
amount of work in fewer than 1 batch.
In the HashAgg case, since 40efbf870, we'll display:
On 2020-Jun-30, Fujii Masao wrote:
> Hi,
>
> When I talked about max_slot_wal_keep_size as new feature in v13
> at the conference, I received the question like "Why are the units of
> setting values in max_slot_wal_keep_size and wal_keep_segments different?"
> from audience. That difference looks
On 2020-Jun-30, Tom Lane wrote:
> SELECT brin_desummarize_range('brinidx', 0);
> +WARNING: leftover placeholder tuple detected in BRIN index "brinidx",
> deleting
> I think the "crash" actually was the forced autovac cancellation we see
> here. Thus, the fact that both these animals use CLOBB
Greetings,
Among the changes made to PG's recovery in v12 was to set
recovery_target_timeline to be 'latest' by default. That's handy when
you're flipping back and forth between replicas and want to have
everyone follow that game, but it's made doing some basic things like
restoring from a backup
>> The point is this data inconsistency is
>> lead by an inconsistent read but not by an inconsistent commit
>> results. I think there are kinds of possibilities causing data
>> inconsistency but atomic commit and atomic visibility eliminate
>> different possibilities. We can eliminate all possibil
On Tue, 30 Jun 2020 at 22:23, Tomas Vondra
wrote:
> >I didn't get this. We are executing an INSERT on the foreign server,
> >so we get the number of rows INSERTed from that server. We should just
> >add those up across batches. If there's a failure, it would abort the
> >transaction, local as wel
On Mon, Jun 29, 2020 at 3:13 PM Fujii Masao
wrote:
Could you add this patch to Commitfest 2020-07?
Thanks for notifying, I've added it.
BTW, I registered you as an author because this patch used
lots of pg_cheat_funcs' codes.
https://commitfest.postgresql.org/28/2622/
This patch provide
On Fri, Jun 26, 2020 at 9:36 PM Amit Langote wrote:
> I would like to discuss a refactoring patch that builds on top of the
> patches at [1] to address $subject.
I forgot to update a place in postgres_fdw causing one of its tests to crash.
Fixed in the attached updated version.
--
Amit Langote
On Tue, Jun 30, 2020, 7:04 PM David Rowley wrote:
> Does anyone have any objections to that being changed?
>
That's OK with me. By the way, I'm on vacation and will catch up on these
HashAgg threads next week.
Regards,
Jeff Davis
74 matches
Mail list logo
