Re: COPY FROM WHEN condition

On 2019-04-03 18:44:32 +1300, David Rowley wrote: > (Fixed all of what you mentioned) > > On Wed, 3 Apr 2019 at 06:57, Andres Freund wrote: > > > +/* > > > + * CopyMultiInsertInfo_Flush > > > + * Write out all stored tuples in all buffers out to the > > > tables. > > > + * > > > + *

Re: Ordered Partitioned Table Scans

On Wed, 3 Apr 2019 at 14:01, Amit Langote wrote: > I don't have any more comments. Great. Many thanks for having a look at this. Going by [1], Julien also seems pretty happy, so I'm going to change this over to ready for committer. [1]

Re: COPY FROM WHEN condition

(Fixed all of what you mentioned) On Wed, 3 Apr 2019 at 06:57, Andres Freund wrote: > > +/* > > + * CopyMultiInsertInfo_Flush > > + * Write out all stored tuples in all buffers out to the tables. > > + * > > + * To save us from ending up with buffers for 1000s of partitions we remove >

Re: pg_basebackup ignores the existing data directory permissions

On Fri, Mar 29, 2019 at 9:05 PM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2019-03-26 03:26, Michael Paquier wrote: > > Do we really want to extend the replication protocol to control that? > > Perhaps we are losing sight of the original problem, which is that if > you

Re: New vacuum option to do only freezing

On Wed, Apr 3, 2019 at 1:17 PM Kyotaro HORIGUCHI wrote: > > At Wed, 3 Apr 2019 12:10:03 +0900, Masahiko Sawada > wrote in > > > And in the following part: > > > > > > + /* Set index cleanup option based on reloptions */ > > > + if (params->index_cleanup == VACUUM_OPTION_DEFAULT) >

Re: Transaction commits VS Transaction commits (with parallel) VS query mean time

On Wed, Apr 3, 2019 at 1:59 PM Amit Kapila wrote: > On Thu, Mar 28, 2019 at 11:43 AM Haribabu Kommi > wrote: > > > > On Wed, Mar 27, 2019 at 11:27 PM Amit Kapila > wrote: > >> > >> On Wed, Mar 27, 2019 at 6:53 AM Haribabu Kommi < > kommi.harib...@gmail.com> wrote: > >> > On Tue, Mar 26, 2019

Re: Re: A separate table level option to control compression

On Tue, Apr 02, 2019 at 02:35:19PM +0900, Michael Paquier wrote: > + compress_tuple_threshold = RelationGetCompressTupleTarget(relation, > + toast_tuple_threshold); > + compress_tuple_threshold = Min(compress_tuple_threshold, > +

Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits

On Wed, Mar 27, 2019 at 9:47 AM Masahiko Sawada wrote: > > The patch looks good to me. There is no comment from me. > > Thanks for your review! Updated patch attached since patch failed to apply after recent changes in the master. Thanks, Pavan -- Pavan Deolasee

Re: Strange coding in _mdfd_openseg()

At Wed, 3 Apr 2019 17:14:36 +1300, Thomas Munro wrote in > Hello, > > I think the following conditional code is misleading, and I wonder if > it would be better like so: > > --- a/src/backend/storage/smgr/md.c > +++ b/src/backend/storage/smgr/md.c > @@ -1787,8 +1787,13 @@

Re: ToDo: show size of partitioned table

Hello. At Wed, 3 Apr 2019 12:55:06 +0900, Amit Langote wrote in > On 2019/04/03 12:02, Kyotaro HORIGUCHI wrote: > > \dPn doesn't show children because the are of 'r' relkind. And > > \dPn * doesn't show type for children. ... > I think it's intentional that leaf partitions are not shown,

Re: New vacuum option to do only freezing

At Wed, 3 Apr 2019 12:10:03 +0900, Masahiko Sawada wrote in > > And in the following part: > > > > + /* Set index cleanup option based on reloptions */ > > + if (params->index_cleanup == VACUUM_OPTION_DEFAULT) > > + { > > + if (onerel->rd_options == NULL || > > +

Strange coding in _mdfd_openseg()

Hello, I think the following conditional code is misleading, and I wonder if it would be better like so: --- a/src/backend/storage/smgr/md.c +++ b/src/backend/storage/smgr/md.c @@ -1787,8 +1787,13 @@ _mdfd_openseg(SMgrRelation reln, ForkNumber forknum, BlockNumber segno, if (fd < 0)

Re: ToDo: show size of partitioned table

Horiguchi-san, Thanks for taking a look. On 2019/04/03 12:02, Kyotaro HORIGUCHI wrote: > \dPn doesn't show children because the are of 'r' relkind. And > \dPn * doesn't show type for children. > > create table pa (a int, b int) partition by range (a); > create table c1 partition of pa for

Re: New vacuum option to do only freezing

On Wed, Apr 3, 2019 at 10:56 AM Kyotaro HORIGUCHI wrote: > > Hello. > > At Mon, 1 Apr 2019 14:26:15 +0900, Masahiko Sawada > wrote in > > On Sat, Mar 30, 2019 at 5:04 AM Robert Haas wrote: > > > > > > On Fri, Mar 29, 2019 at 12:27 PM Masahiko Sawada > > > wrote: > > > > Yeah, but since

Re: ToDo: show size of partitioned table

At Tue, 2 Apr 2019 22:49:25 -0300, Alvaro Herrera wrote in <20190403014925.GA9976@alvherre.pgsql> > Hi Amit > > On 2019-Apr-03, Amit Langote wrote: > > > Thanks. I'm getting an error while applying v12: > > > > patching file src/bin/psql/po/es.po > > Hunk #1 FAILED at 12. > > 1 out of 2

Re: Transaction commits VS Transaction commits (with parallel) VS query mean time

On Thu, Mar 28, 2019 at 11:43 AM Haribabu Kommi wrote: > > On Wed, Mar 27, 2019 at 11:27 PM Amit Kapila wrote: >> >> On Wed, Mar 27, 2019 at 6:53 AM Haribabu Kommi >> wrote: >> > On Tue, Mar 26, 2019 at 9:08 PM Amit Kapila >> > wrote: >> >> >> >> As part of this thread, maybe we can >> >>

Re: New vacuum option to do only freezing

Hello. At Mon, 1 Apr 2019 14:26:15 +0900, Masahiko Sawada wrote in > On Sat, Mar 30, 2019 at 5:04 AM Robert Haas wrote: > > > > On Fri, Mar 29, 2019 at 12:27 PM Masahiko Sawada > > wrote: > > > Yeah, but since multiple relations might be specified in VACUUM > > > command we need to process

Re: Problem with default partition pruning

Hosoya-san, On 2019/04/02 14:02, Yuzuko Hosoya wrote: > Hi, > >> Maybe we should have two patches as we seem to be improving two things: >> >> 1. Patch to fix problems with default partition pruning originally reported >> by Hosoya-san >> >> 2. Patch to determine if a given clause contradicts a

Re: ToDo: show size of partitioned table

Hi Amit On 2019-Apr-03, Amit Langote wrote: > Thanks. I'm getting an error while applying v12: > > patching file src/bin/psql/po/es.po > Hunk #1 FAILED at 12. > 1 out of 2 hunks FAILED -- saving rejects to file src/bin/psql/po/es.po.rej Uh, I certainly did not intend to send the es.po part of

Re: Progress reporting for pg_verify_checksums

On Tue, Apr 02, 2019 at 10:10:34AM +0200, Fabien COELHO wrote: > For online, we should want throttling so that the check can have a reduced > performance impact when scrubbing. Yes. Throttling is a necessary property in my opinion, perhaps in combination with some autovacuum-like options to only

Re: Progress reporting for pg_verify_checksums

On Tue, Apr 02, 2019 at 04:02:59PM +0200, Michael Banck wrote: > Can you explain in more detail how this would work? I thought we came to > the conclusion (and the documentation seems to indicate so), that you > should stop all participating instances of a cluster and then enable > checksums on

Re: Checksum errors in pg_stat_database

On Tue, Apr 02, 2019 at 07:06:35PM +0200, Magnus Hagander wrote: > I think having the count and hte last time make sense, but I'm very > sceptical about the rest. There may be other things which we are not considering on this thread. I don't know. > I can somewhat agree that splitting it on a

Re: ToDo: show size of partitioned table

Hi Alvaro, On 2019/04/03 4:42, Alvaro Herrera wrote: > On 2019-Apr-02, Alvaro Herrera wrote: > >> Something is not right: > > Another thing that was not right is that translated_columns was being > marked static, and modified in the function; so if you called \dP twice > where one called for

Re: Ordered Partitioned Table Scans

On 2019/04/03 3:10, David Rowley wrote: > On Wed, 3 Apr 2019 at 01:26, Amit Langote wrote: >> +#include "nodes/pathnodes.h" >> ... >> +partitions_are_ordered(struct RelOptInfo *partrel) >> >> Maybe, "struct" is unnecessary? > > I just left it there so that the signature matched the header file.

Re: [PATCH v20] GSSAPI encryption support

On 4/2/19 6:18 PM, Stephen Frost wrote: > Greetings, > > On Tue, Apr 2, 2019 at 18:10 Peter Eisentraut > > wrote: > > On 2019-02-23 17:27, Stephen Frost wrote: > >> About pg_hba.conf: The "hostgss" keyword seems a bit confusing.  > It only >

Re: [PATCH v20] GSSAPI encryption support

Greetings, On Tue, Apr 2, 2019 at 18:10 Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2019-02-23 17:27, Stephen Frost wrote: > >> About pg_hba.conf: The "hostgss" keyword seems a bit confusing. It only > >> applies to encrypted gss-using connections, not all of them. Maybe >

Re: [PATCH v20] GSSAPI encryption support

On 2019-02-23 17:27, Stephen Frost wrote: >> About pg_hba.conf: The "hostgss" keyword seems a bit confusing. It only >> applies to encrypted gss-using connections, not all of them. Maybe >> "hostgssenc" or "hostgsswrap"? > Not quite sure what you mean here, but 'hostgss' seems to be quite well >

Re: Pluggable Storage - Andres's take

Hi, On 2019-04-02 17:11:07 +1100, Haribabu Kommi wrote: > From a72cfcd523887f1220473231d7982928acc23684 Mon Sep 17 00:00:00 2001 > From: Hari Babu > Date: Tue, 2 Apr 2019 15:41:17 +1100 > Subject: [PATCH 1/2] tableam : doc update of table access methods > > Providing basic explanation of table

Re: amcheck verification for GiST

On Thu, Mar 28, 2019 at 11:30 PM Andrey Borodin wrote: > Here's updated patch with AccessShareLock. > I've tried to stress this with combination of random inserts, vaccuums and > checks. This process neither failed, nor deadlocked. > The patch intentionally contains one superflous line to make

Re: PostgreSQL pollutes the file system

It looks like this thread is featured on LWN under the article: Program names and "pollution". https://lwn.net/ https://lwn.net/Articles/784508/ (Subscription required) On Sat, Mar 30, 2019 at 12:27 PM Peter Eisentraut wrote: > > On 2019-03-29 20:32, Joe Conway wrote: > > pg_util > > How is

Re: Unified logging system for command-line programs

On 2019-Apr-02, Tom Lane wrote: > Alvaro Herrera writes: > > I don't much like the code that does > >pg_log_error("%s", something); > > > because then the string "%s" is marked for translation. > > Uh, surely we've got hundreds of instances of that in the system already? Actually, we

Re: Unified logging system for command-line programs

Alvaro Herrera writes: > I don't much like the code that does >pg_log_error("%s", something); > because then the string "%s" is marked for translation. Uh, surely we've got hundreds of instances of that in the system already? > Maybe we should > consider a variant that takes a straight

Re: Unified logging system for command-line programs

I don't much like the code that does pg_log_error("%s", something); because then the string "%s" is marked for translation. Maybe we should consider a variant that takes a straight string literal instead of a sprintf-style fmt to avoid this problem. We'd do something like

Re: ToDo: show size of partitioned table

On 2019-Apr-02, Alvaro Herrera wrote: > Something is not right: Another thing that was not right is that translated_columns was being marked static, and modified in the function; so if you called \dP twice where one called for translation and the second not, the second time we'd also translating

Re: Pluggable Storage - Andres's take

Hi, On 2019-04-02 17:11:07 +1100, Haribabu Kommi wrote: > + xreflabel="default_table_access_method"> > + default_table_access_method > (string) > + > + default_table_access_method configuration > parameter > + > + > + > + > +The value is

Re: ToDo: show size of partitioned table

Something is not right: alvherre=# \dP t List of partitioned tables or indexes Esquema | Nombre | Dueño | Tipo| On table

Re: ToDo: show size of partitioned table

On 2019-Mar-13, Amit Langote wrote: > + if (show_indexes) > + { > + objects_name = gettext_noop("indexes"); ... > + if (pattern) > + /* translator: objects_name is "index", "table" */ > + psql_error("Did not find any

Re: [HACKERS] generated columns

On 2019-04-02 15:36, Erik Rijkers wrote: On 2019-04-02 14:43, Peter Eisentraut wrote: On 2019-04-01 10:52, Peter Eisentraut wrote: On 2019-03-31 05:49, Erik Rijkers wrote: STORED in a file_fdw foreign table still silently creates the column which then turns out to be useless on SELECT, with

Re: Ordered Partitioned Table Scans

On Wed, 3 Apr 2019 at 01:26, Amit Langote wrote: > +#include "nodes/pathnodes.h" > ... > +partitions_are_ordered(struct RelOptInfo *partrel) > > Maybe, "struct" is unnecessary? I just left it there so that the signature matched the header file. Looking around for examples I see

Re: COPY FROM WHEN condition

Gah, ignore this mail - I've somehow accidentally sent this early. I'm not quite sure, but I miskeyed, and emacs sent it early, without going through mutt...

Re: [HACKERS] proposal: schema variables

se Regards Pavel > Regards > > Pavel > > >> Regards >> >> Pavel >> > schema-variables-20190402.patch.gz Description: application/gzip

Re: COPY FROM WHEN condition

On 2019-04-03 06:41:49 +1300, David Rowley wrote: > However, I've ended up not doing it that way as the patch requires > more than just an array of TupleTableSlots to be stored in the > ResultRelInfo, it'll pretty much need all of what I have in > CopyMultiInsertBuffer, which includes line numbers

Re: COPY FROM WHEN condition

On 2019-04-03 06:41:49 +1300, David Rowley wrote: > However, I've ended up not doing it that way as the patch requires > more than just an array of TupleTableSlots to be stored in the > ResultRelInfo, it'll pretty much need all of what I have in > CopyMultiInsertBuffer, which includes line numbers

Re: COPY FROM WHEN condition

On Tue, 2 Apr 2019 at 14:11, Andres Freund wrote: > Why do we need that list membership check? If you append the > ResultRelInfo to the list when creating the ResultRelInfo's slots array, > you don't need to touch the list after a partition lookup - you know > it's a member if the ResultRelInfo

Re: Checksum errors in pg_stat_database

On Tue, Apr 2, 2019 at 8:47 AM Michael Paquier wrote: > On Tue, Apr 02, 2019 at 07:43:12AM +0200, Julien Rouhaud wrote: > > On Tue, Apr 2, 2019 at 6:56 AM Michael Paquier > wrote: > >> One thing which is not > >> proposed on this patch, and I am fine with it as a first draft, is > >> that we

Re: Inadequate executor locking of indexes

David Rowley writes: > On Thu, 14 Mar 2019 at 21:52, Amit Langote > wrote: >> If the correct lock is taken in both cases by the current code, then maybe >> there's no need to change anything? > I'm aiming to fix the problem described by Tom when he started this > thread. It's pretty easy to get

Re: Compressed TOAST Slicing

Greetings, * Darafei "Komяpa" Praliaskouski (m...@komzpa.net) wrote: > > I'll plan to push this tomorrow with the above change (and a few > > additional comments to explain what all is going on..). > > Is everything ok? Can it be pushed? This has been pushed now. Thanks! Stephen

Re: [PATCH v22] GSSAPI encryption support

Greetings, * Robbie Harwood (rharw...@redhat.com) wrote: > Stephen Frost writes: > > * Robbie Harwood (rharw...@redhat.com) wrote: > >> Stephen Frost writes: > >> > >> I wanted to note a couple things about this approach. It now uses > >> one more buffer than before (in contrast to the

Re: Minimal logical decoding on standbys

Hi, On 2019-04-02 15:26:52 +0530, Amit Khandekar wrote: > On Thu, 14 Mar 2019 at 15:00, Amit Khandekar wrote: > > I managed to get a recovery conflict by : > > 1. Setting hot_standby_feedback to off > > 2. Creating a logical replication slot on standby > > 3. Creating a table on master, and

Re: Column lookup in a row performance

=?UTF-8?B?0J/QsNCy0LvRg9GF0LjQvSDQmNCy0LDQvQ==?= writes: >> (1) Backwards compatibility, and (2) it's not clear that a different >> layout would be a win for all cases. > I am curious regarding (2), for my understanding it is good to find > out at least one case when layout with lengths/offsets

Re: patch to allow disable of WAL recycling

On Mon, Apr 1, 2019 at 7:48 PM Thomas Munro wrote: > On Sat, Mar 30, 2019 at 11:18 AM Jerry Jelinek > wrote: > > I went through your new version of the patch and it all looks great to > me. > > I moved the error handling logic around a bit so we'd capture errno > immediately after the syscalls.

Re: partitioned tables referenced by FKs

Alvaro Herrera writes: > On 2019-Mar-29, Robert Haas wrote: >> I don't know why dependency.c doesn't handle this internally. If I >> say that I want to delete a list of objects, some of which can't be >> dropped without dropping certain other things, dependency.c ought to >> be able to suspend

Re: "could not reattach to shared memory" on buildfarm member dory

Noah Misch writes: > I can reproduce the 4 MiB allocations described > in https://postgr.es/m/29823.1525132...@sss.pgh.pa.us; a few times per > "vcregress check", they emerge in the middle of PGSharedMemoryReAttach(). > The 4 MiB allocations are stacks for new threads of the default thread >

Re: Progress reporting for pg_verify_checksums

Hi, Am Dienstag, den 02.04.2019, 15:56 +0900 schrieb Michael Paquier: > Regarding all this tooling around checksums. With v12, enabling > checksums with no actual downtime is doable with a primary-standby > deployment using physical replication and one planned failover Can you explain in more

Re: "could not reattach to shared memory" on buildfarm member dory

On Sun, Dec 02, 2018 at 09:35:06PM -0800, Noah Misch wrote: > On Tue, Sep 25, 2018 at 08:05:12AM -0700, Noah Misch wrote: > > On Mon, Sep 24, 2018 at 01:53:05PM -0400, Tom Lane wrote: > > > Overall, I agree that neither of these approaches are exactly attractive. > > > We're paying a heck of a lot

Re: partitioned tables referenced by FKs

Hi, On 4/1/19 4:03 PM, Alvaro Herrera wrote: I'm satisfied with this patch now, so I intend to push early tomorrow. Passes check-world, and my tests. Best regards, Jesper

Re: [HACKERS] generated columns

On 2019-04-02 14:43, Peter Eisentraut wrote: On 2019-04-01 10:52, Peter Eisentraut wrote: On 2019-03-31 05:49, Erik Rijkers wrote: STORED in a file_fdw foreign table still silently creates the column which then turns out to be useless on SELECT, with an error like: "ERROR: column

Re: [PROPOSAL] Temporal query processing with range types

I start looking at the patch, there is a couple of problems with the patch. The first one is the OID conflict, which I fixed on my machine. The second problem is assertion failure. I think you have not compiled the PostgreSQL code with the assertion. ... postgres=# SELECT * FROM (projects p1

Re: [HACKERS] generated columns

On 2019-04-01 10:52, Peter Eisentraut wrote: > On 2019-03-31 05:49, Erik Rijkers wrote: >> STORED in a >> file_fdw foreign table still silently creates the column which then >> turns out to be useless on SELECT, with an error like: >> >> "ERROR: column some_column_name is a generated column >>

Re: Ordered Partitioned Table Scans

Hi David, On Tue, Apr 2, 2019 at 8:49 PM David Rowley wrote: > I ended up rewording the entire thing and working on the header > comment for the function too. I think previously it wasn't that well > defined what "ordered" meant. I added a mention that we expect that > NULLs, if possible must

Re: Unified logging system for command-line programs

On 2019-04-02 05:05, Michael Paquier wrote: > I am a bit disappointed that this stuff is not reducing > the amount of diff code with ifdef FRONTEND in src/common/. That wasn't the purpose of the patch. If you have a concrete proposal for how to do what you describe, it would surely be welcome.

Re: Unified logging system for command-line programs

On 2019-04-01 20:55, Andres Freund wrote: > A written upthread, I think this should have had a uniform interface > with elog.h, and probably even share some code between the two. The purpose of this patch was to consolidate the existing zoo of logging routines in the frontend programs. That has

Re: Problems with plan estimates in postgres_fdw

(2019/03/29 22:18), Etsuro Fujita wrote: Attached is a new version. If there are no objections, I'll commit this version. Pushed after polishing the patchset a bit further: add an assertion, tweak comments, and do cleanups. Thanks for reviewing, Antonin and Jeff! Best regards, Etsuro

Re: Ordered Partitioned Table Scans

On Tue, 2 Apr 2019 at 14:26, Amit Langote wrote: > How about extending the sentence about when the optimization is disabled > as follows: > > "If we find a Datum in a partition that's greater than one previously > already seen, then values could become out of order and we'd have to > disable the

Re: GCoS2019--pgBackRest port to Windows (2019)

Hello Youssef, On 4/1/19 5:16 PM, Youssef Khedher wrote: Hello, I’m Youssef Khedher, 19 years old student from Tunisia. I’m a computer science student in Tunisia, and also an online student for Harvard CS50 Program. I’m interested in the ” pgBackRest port to Windows (2019)”. Excellent!

Re: [HACKERS] WAL logging problem in 9.4.3?

Thank you for reviewing. At Sun, 31 Mar 2019 15:31:58 -0700, Noah Misch wrote in <20190331223158.gb891...@rfd.leadboat.com> > On Sun, Mar 10, 2019 at 07:27:08PM -0700, Noah Misch wrote: > > On Mon, Mar 04, 2019 at 12:24:48PM +0900, Kyotaro HORIGUCHI wrote: > > > +/* > > > + *

Re: Refactoring the checkpointer's fsync request queue

On Wed, Mar 27, 2019 at 5:48 AM Shawn Debnath wrote: > On Tue, Mar 26, 2019 at 09:22:56AM -0400, Robert Haas wrote: > > On Tue, Mar 26, 2019 at 12:20 AM Thomas Munro > > wrote: > > > Here's a fixup patch. 0001 is the same as Shawn's v12 patch, and 0002 > > > has my proposed changes to switch

Re: Minimal logical decoding on standbys

On Thu, 14 Mar 2019 at 15:00, Amit Khandekar wrote: > I managed to get a recovery conflict by : > 1. Setting hot_standby_feedback to off > 2. Creating a logical replication slot on standby > 3. Creating a table on master, and insert some data. > 2. Running : VACUUM FULL; > > This gives WARNING

Re: minimizing pg_stat_statements performance overhead

Re: Raymond Martin 2019-04-01 > Thanks again Fabien. I am attaching the patch to this email in the hope of > getting it approved during the next commit fest. Raymond, you sent the patch as UTF-16, could you re-send it as plain ascii? Christoph

Re: [Patch] Mingw: Fix import library extension, build actual static libraries

Any chance these patches could be considered? Thanks Sandro On Thu, Mar 7, 2019 at 3:23 PM Sandro Mani wrote: > Currently building postgresql for Win32 with a mingw toolchain produces > import libraries with *.a extension, whereas the extension should be > *.dll.a. There are various downstream

Re: partitioned tables referenced by FKs

Hi Alvaro, On 2019/04/02 5:03, Alvaro Herrera wrote: > On 2019-Mar-29, Jesper Pedersen wrote: > >> I ran my test cases for this feature, and havn't seen any issues. >> >> Therefore I'm marking 1877 as Ready for Committer. If others have additional >> feedback feel free to switch it back. > >

Re: Progress reporting for pg_verify_checksums

For pg_checksums, probably some improvement patch will be submitted later, if someone feels like it. Let's see. I think that what we have now in v12 is good enough for checksum operations on an offline cluster. And my take is that we should focus more on online checksum verification for

RE: Transaction commits VS Transaction commits (with parallel) VS query mean time

On Thursday, March 28, 2019 3:13 PM (GMT+9), Haribabu Kommi wrote: > I tried the approach as your suggested as by not counting the actual parallel > work > transactions by just releasing the resources without touching the counters, > the counts are not reduced much. > > HEAD - With 4 parallel

GCoS2019--pgBackRest port to Windows (2019)

Hello, I’m Youssef Khedher, 19 years old student from Tunisia. I’m a computer science student in Tunisia, and also an online student for Harvard CS50 Program. I’m interested in the ” pgBackRest port to Windows (2019)”. I have a good knowledge in C and in IT in general, I believe that nothing is

RE: Planning counters in pg_stat_statements (using pgss_store)

Hi, >> >> case avg_tps pct_diff >> 089 278 -- >> 188 745 0,6% >> 288 282 1,1% >> 386 660 2,9% >> >> This means that even in this extrem test case, the worst degradation is less >> than 3% >> (this overhead can be removed using

Re: New vacuum option to do only freezing

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested I have read this patch. I like the concept and would like it to get

Re: Progress reporting for pg_verify_checksums

On Tue, Apr 02, 2019 at 08:11:45AM +0200, Fabien COELHO wrote: > Nope, this was way before I intervened. ISTM that a patch was submitted to > get per second or slower progress reporting on the initalization, and it was > rejected. Now that there are many SSD, maybe I could bring it back. An issue

Re: Checksum errors in pg_stat_database

On Tue, Apr 02, 2019 at 07:43:12AM +0200, Julien Rouhaud wrote: > On Tue, Apr 2, 2019 at 6:56 AM Michael Paquier wrote: >> One thing which is not >> proposed on this patch, and I am fine with it as a first draft, is >> that we don't have any information about the broken block number and >> the

Re: Compressed TOAST Slicing

Hi! > I'll plan to push this tomorrow with the above change (and a few > additional comments to explain what all is going on..). Is everything ok? Can it be pushed? I'm looking here, haven't found it pushed and worry about this. https://github.com/postgres/postgres/commits/master

Re: Progress reporting for pg_verify_checksums

Bonjour Michaël, Maybe it should be -P X where X is the expected delay in seconds. Pgbench progress reporting on initialization basically outputs 10 rows per second, probably it is too much. I cannot say for pgbench. I personally think that's a lot but you are the one who wrote it as such I

Re: Pluggable Storage - Andres's take

On Tue, Apr 2, 2019 at 11:53 AM Andres Freund wrote: > Hi, > > On 2019-04-02 11:39:57 +1100, Haribabu Kommi wrote: > > > What made you rename indexam.sgml to am.sgml, instead of creating a > > > separate tableam.sgml? Seems easier to just have a separate file? > > > > > > > No specific reason,