Re: pg_stat_statements issue with parallel maintenance (Was Re: WAL usage calculation patch)

On Sun, 29 Mar 2020 at 14:23, Amit Kapila wrote: > > On Sat, Mar 28, 2020 at 8:47 PM Julien Rouhaud wrote: > > > > On Sat, Mar 28, 2020 at 02:38:27PM +0100, Julien Rouhaud wrote: > > > On Sat, Mar 28, 2020 at 04:14:04PM +0530, Amit Kapila wrote: > > > > > > > > I see some basic problems with the

Re: Planning counters in pg_stat_statements (using pgss_store)

On Fri, Mar 27, 2020 at 03:42:50PM +0100, Julien Rouhaud wrote: > On Fri, Mar 27, 2020 at 2:01 PM Fujii Masao > wrote: > > > > > So what I'd like to say is that the information that users are interested > > in would vary on each situation and case. At least for me it seems > > enough for pgss to

Re: error context for vacuum to include block number

On Sun, Mar 29, 2020 at 9:04 AM Masahiko Sawada wrote: > > On Sat, 28 Mar 2020 at 13:23, Amit Kapila wrote: > > > > > > Please find attached the updated patch with all the changes discussed. > > Let me know if I have missed anything? > > > > Thank you for updating the patch! Looks good to me. >

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Sun, Mar 29, 2020 at 6:29 AM Tomas Vondra wrote: > > On Sat, Mar 28, 2020 at 03:29:34PM +0530, Amit Kapila wrote: > >On Sat, Mar 28, 2020 at 2:19 PM Dilip Kumar wrote: > > > >How about if instead of writing an XLOG_XACT_ASSIGNMENT WAL, we set a > >flag in TransactionStateData and then log that

Re: pgbench - refactor init functions with buffers

Hello Andres, That being the case, I'd think a better design principle is "make your new code look like the code around it", which would tend to weigh against introducing StringInfo uses into pgbench when there's none there now and a bunch of PQExpBuffer instead. So I can't help thinking the a

Re: WAL usage calculation patch

On Sat, Mar 28, 2020 at 7:08 PM Julien Rouhaud wrote: > > On Sat, Mar 28, 2020 at 04:14:04PM +0530, Amit Kapila wrote: > > > > Basically, > > I don't know changes done in ExecInitParallelPlan and friends allow us > > to compute WAL for parallel operations. Those will primarily cover > > parallel

Re: pg_stat_statements issue with parallel maintenance (Was Re: WAL usage calculation patch)

On Sat, Mar 28, 2020 at 8:47 PM Julien Rouhaud wrote: > > On Sat, Mar 28, 2020 at 02:38:27PM +0100, Julien Rouhaud wrote: > > On Sat, Mar 28, 2020 at 04:14:04PM +0530, Amit Kapila wrote: > > > > > > I see some basic problems with the patch. The way it tries to compute > > > WAL usage for parallel

snapper vs. HEAD

Buildfarm member snapper has been crashing in the core regression tests since commit 17a28b0364 (well, there's a bit of a range of uncertainty there, but 17a28b0364 looks to be the only such commit that could have affected code in gistget.c where the crash is). Curiously, its sibling skate is *not

Re: backup manifests

On Fri, Mar 27, 2020 at 01:53:54PM -0400, Robert Haas wrote: > - Replace a doc paragraph about the advantages and disadvantages of > CRC-32C with one by Stephen Frost, with a slightly change by me that I > thought made it sound more grammatical. Defaulting to CRC-32C seems prudent to me: - As And

Re: Improving connection scalability: GetSnapshotData()

Hi, On 2020-03-28 18:39:32 -0700, Peter Geoghegan wrote: > I have heard quite a few complaints about the scalability of snapshot > acquisition in Postgres. Generally from very large users that are not > well represented on the mailing lists, for a variety of reasons. The > GetSnapshotData() bottle

Re: error context for vacuum to include block number

On Sat, 28 Mar 2020 at 13:23, Amit Kapila wrote: > > On Sat, Mar 28, 2020 at 7:04 AM Justin Pryzby wrote: > > > > On Sat, Mar 28, 2020 at 06:59:10AM +0530, Amit Kapila wrote: > > > On Sat, Mar 28, 2020 at 6:46 AM Justin Pryzby > > > wrote: > > > > > > > > On Sat, Mar 28, 2020 at 06:28:38AM +053

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Sat, Mar 28, 2020 at 11:14 PM Tomas Vondra wrote: > > On Sat, Mar 28, 2020 at 10:47:49PM -0400, James Coleman wrote: > >On Sat, Mar 28, 2020 at 6:59 PM Tomas Vondra > > wrote: > >> > >> Hi, > >> > >> Attached is my take on simplification of the useful pathkeyes thing. It > >> keeps the function

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Sat, Mar 28, 2020 at 10:47:49PM -0400, James Coleman wrote: On Sat, Mar 28, 2020 at 6:59 PM Tomas Vondra wrote: Hi, Attached is my take on simplification of the useful pathkeyes thing. It keeps the function, but it truncates query_pathkeys to only members with EC members in the relation. I

Re: Berserk Autovacuum (let's save next Mandrill)

On Sun, 29 Mar 2020 at 10:30, David Rowley wrote: > > On Sun, 29 Mar 2020 at 06:26, Tom Lane wrote: > > > > David Rowley writes: > > > On Sat, 28 Mar 2020 at 17:12, Laurenz Albe > > > wrote: > > >> In the light of that, I have no objections. > > > > > Thank you. Pushed. > > > > It seems like

Re: Improving connection scalability: GetSnapshotData()

On Sat, Mar 28, 2020 at 06:39:32PM -0700, Peter Geoghegan wrote: > On Sun, Mar 1, 2020 at 12:36 AM Andres Freund wrote: > > The workload is a pgbench readonly, with pgbench -M prepared -c $conns > > -j $conns -S -n for each client count. This is on a machine with 2 > > Intel(R) Xeon(R) Platinum 8

Re: Improving connection scalability: GetSnapshotData()

On Sun, Mar 1, 2020 at 12:36 AM Andres Freund wrote: > The workload is a pgbench readonly, with pgbench -M prepared -c $conns > -j $conns -S -n for each client count. This is on a machine with 2 > Intel(R) Xeon(R) Platinum 8168, but virtualized. > > conns tps master tps pgxact-spli

Can we get rid of GetLocaleInfoEx() yet?

Commit 0fb54de9a ("Support building with Visual Studio 2015") introduced a hack in chklocale.c's win32_langinfo() to make it use GetLocaleInfoEx() in place of _create_locale(). There's a problem with this, which is that if I'm reading the docs correctly, GetLocaleInfoEx() accepts a smaller set of

Re: Improving connection scalability: GetSnapshotData()

On Sun, Mar 29, 2020 at 1:49 PM Andres Freund wrote: > > 13. is -> are > > > > * accessed data is stored contiguously in memory in as few cache lines as > > Oh? 'data are stored' sounds wrong to me, somehow. In computer contexts it seems pretty well established that we treat "data" as an uncounta

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Sat, Mar 28, 2020 at 03:29:34PM +0530, Amit Kapila wrote: On Sat, Mar 28, 2020 at 2:19 PM Dilip Kumar wrote: On Sat, Mar 28, 2020 at 11:56 AM Amit Kapila wrote: > > > I have looked at the solution proposed and I would like to share my > findings. I think calling ProcArrayApplyXidAssignmen

Re: Improving connection scalability: GetSnapshotData()

Hi, On 2020-03-17 23:59:14 +1300, David Rowley wrote: > Nice performance gains. Thanks. > On Sun, 1 Mar 2020 at 21:36, Andres Freund wrote: > 2. I don't quite understand your change in > UpdateSubscriptionRelState(). snap seems unused. Drilling down into > SearchSysCacheCopy2, in SearchCatCach

Minor bug in suffix truncation of non-key attributes from INCLUDE indexes

During a stress test of an experimental patch (which implements a new technique for managing B-Tree index bloat caused by non-HOT updates), I noticed a minor bug in _bt_truncate(). The issue affects Postgres 12 + master. The problem is that INCLUDE indexes don't have their non-key attributes physi

Re: fix for BUG #3720: wrong results at using ltree

Nikita Glukhov writes: > On 24.01.2020 21:29, Tomas Vondra wrote: >> Unfortunately, the current code is somewhat undercommented :-( > The main problem is that no one really understands how it works now. Indeed. I was disturbed to realize that lquery_op.c, despite being far from trivial code, co

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

Hi, Attached is my take on simplification of the useful pathkeyes thing. It keeps the function, but it truncates query_pathkeys to only members with EC members in the relation. I think that's essentially the optimization you've proposed. I've also noticed an issue in explain output. EXPLAIN ANAL

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Sat, Mar 28, 2020 at 5:30 PM Tomas Vondra wrote: > > On Sat, Mar 28, 2020 at 10:19:04AM -0400, James Coleman wrote: > >On Fri, Mar 27, 2020 at 10:58 PM Tomas Vondra > > wrote: > >> > >> ... > >> > >> The more I look at pathkeys_useful_for_ordering() the more I think the > >> get_useful_pathkeys

debian bugrept involving fast default crash in pg11.7

I happened across this bugreport, which seems to have just enough information to be interesting. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953204 |Version: 11.7-0+deb10u1 |2020-03-05 16:55:55.511 UTC [515] LOG: background worker "parallel worker" (PID 884) was terminated by signal 11: Se

[PATCH] Redudant initilization

Hi, This patch fixes some redundant initilization, that are safe to remove. best regards, Ranier Vilela redudant_initialization.patch Description: Binary data

Re: Berserk Autovacuum (let's save next Mandrill)

On Sun, 29 Mar 2020 at 06:26, Tom Lane wrote: > > David Rowley writes: > > On Sat, 28 Mar 2020 at 17:12, Laurenz Albe wrote: > >> In the light of that, I have no objections. > > > Thank you. Pushed. > > It seems like this commit has resulted in some buildfarm instability: > > https://buildfarm.

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Sat, Mar 28, 2020 at 10:19:04AM -0400, James Coleman wrote: On Fri, Mar 27, 2020 at 10:58 PM Tomas Vondra wrote: ... The more I look at pathkeys_useful_for_ordering() the more I think the get_useful_pathkeys_for_relation() function should look more like it than the postgres_fdw one ... I

Potential (low likelihood) wraparound hazard in heap_abort_speculative()

Hi, heap_abort_speculative() does: /* * The tuple will become DEAD immediately. Flag that this page * immediately is a candidate for pruning by setting xmin to * RecentGlobalXmin. That's not pretty, but it doesn't seem worth * inventing a nicer API for

Re: Catalog invalidations vs catalog scans vs ScanPgRelation()

Hi, On 2020-03-28 12:30:40 -0700, Andres Freund wrote: > On 2020-02-28 22:10:52 -0800, Andres Freund wrote: > > On 2020-02-28 21:24:59 -0800, Andres Freund wrote: > > So, um. What happens is that doDeletion() does a catalog scan, which > > sets a snapshot. The results of that catalog scan are then

Re: ssl passphrase callback

On 3/28/20 1:45 PM, Tom Lane wrote: > Andreas Karlsson writes: >> On 3/22/20 1:08 AM, Andrew Dunstan wrote: >>> Latest patch attached, I think all comments have been addressed. I >>> propose to push this later this coming week if there are no more comments. >> I do not have any objections. > Thi

Re: pgbench - refactor init functions with buffers

On 2020-03-28 15:16:21 -0400, Tom Lane wrote: > Andres Freund writes: > > - both stringinfo and pqexpbuffer are performance relevant in some uses, > > needing to optimize both is wasted effort > > I'm not aware that anybody is trying to micro-optimize either. https://postgr.es/m/5450.157879703

Re: Catalog invalidations vs catalog scans vs ScanPgRelation()

Hi, On 2020-02-28 22:10:52 -0800, Andres Freund wrote: > On 2020-02-28 21:24:59 -0800, Andres Freund wrote: > > Turns out that I am to blame for that. All the way back in 9.4. For > > logical decoding I needed to make ScanPgRelation() use a specific type > > of snapshot during one corner case of l

Re: Memory-Bounded Hash Aggregation

On Fri, 2020-03-27 at 02:31 +0100, Tomas Vondra wrote: > On Thu, Mar 26, 2020 at 05:56:56PM +0800, Richard Guo wrote: > > If nbatches is some number between 1.0 and 2.0, we would have a > > negative > > depth. As a result, we may have a negative cost for hash > > aggregation > > plan node, as descr

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Sat, Mar 28, 2020 at 2:54 PM Tomas Vondra wrote: > ... > >> >> >9. optimizer/path/allpaths.c get_useful_pathkeys_for_relation: > >> >> >* Considering query_pathkeys is always worth it, because it might let > >> >> >us > >> >> >* avoid a local sort. > >> >> > > >> >> >That originally was a copy

Re: pgbench - refactor init functions with buffers

Andres Freund writes: > On 2020-03-28 14:49:31 -0400, Tom Lane wrote: >> Why? I'm not aware of any intention to deprecate/remove PQExpBuffer, >> and I doubt it'd be a good thing to try. It does some things that >> StringInfo won't, notably cope with OOM without crashing. > - code using it canno

Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at end-of-transaction

Justin Pryzby writes: > On Sat, Mar 28, 2020 at 01:13:54PM -0400, Tom Lane wrote: >> so I propose that we fix these directory-scanning functions to silently >> ignore ENOENT failures from stat(). Are there any for which we should not do >> that? > Maybe we should lstat() the file to determine if

Re: pgbench - refactor init functions with buffers

On 2020-03-28 14:49:31 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2020-03-27 19:57:12 -0400, Tom Lane wrote: > >> That being the case, I'd think a better design principle is "make your > >> new code look like the code around it", which would tend to weigh against > >> introducing String

Re: [PATCH] Finally split StdRdOptions into HeapOptions and ToastOptions

A new version of the patch. Autovacuum options were extended in b07642db So I added that options to the current patch.diff --git a/src/backend/access/common/reloptions.c b/src/backend/access/common/reloptions.c index e136116..55bd1ec 100644 --- a/src/backend/access/common/reloptions.c +++ b/src/ba

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Sat, Mar 28, 2020 at 10:19:04AM -0400, James Coleman wrote: On Fri, Mar 27, 2020 at 10:58 PM Tomas Vondra wrote: ... >> As a side note here, I'm wondering if this (determining useful pathkeys) >> can be made a bit smarter by looking both at query_pathkeys and pathkeys >> useful for merging,

Re: pgbench - refactor init functions with buffers

Andres Freund writes: > On 2020-03-27 19:57:12 -0400, Tom Lane wrote: >> That being the case, I'd think a better design principle is "make your >> new code look like the code around it", which would tend to weigh against >> introducing StringInfo uses into pgbench when there's none there now and >

Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at end-of-transaction

On Sat, Mar 28, 2020 at 01:13:54PM -0400, Tom Lane wrote: > The buildfarm just showed up another instability in the test cases > we added: Yea, as you said, this is an issue with the *testcase*. The function behavior didn't change, we just weren't previously exercising it. > select (w).size = :

Re: pgbench - refactor init functions with buffers

Hi, On 2020-03-27 19:57:12 -0400, Tom Lane wrote: > Fabien COELHO writes: > >>> Ok. I find it strange to mix PQExpBuffer & StringInfo in the same file. > > >> Agreed, but we'd rather use StringInfo going forward. However, I don't > >> think > >> that puts you on the hook for updating all the

Re: ssl passphrase callback

Andreas Karlsson writes: > On 3/22/20 1:08 AM, Andrew Dunstan wrote: >> Latest patch attached, I think all comments have been addressed. I >> propose to push this later this coming week if there are no more comments. > I do not have any objections. This CF entry is still open, should it not be c

Re: Berserk Autovacuum (let's save next Mandrill)

David Rowley writes: > On Sat, 28 Mar 2020 at 17:12, Laurenz Albe wrote: >> In the light of that, I have no objections. > Thank you. Pushed. It seems like this commit has resulted in some buildfarm instability: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lousyjack&dt=2020-03-28%20

Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at end-of-transaction

Justin Pryzby writes: > Thanks for fixing my test case and pushing. The buildfarm just showed up another instability in the test cases we added: === regression.diffs diff -U3 /home/bf/build/buildfarm-idiacanthus/HEAD/pgsql.build/../pgsql/src/test/regress

Re: [PATCH] postgresql.conf.sample->postgresql.conf.sample.in

Patch - yes, a good way. but 1) requires invasion to the makefile 2) makes changes in the file stored on git.. in case postgresql.conf.sample.in is a template, there are no such problems. and this does not bother those who if someone assumes the existence of the postgres.conf.sample file >Even m

Re: [PATCH] postgresql.conf.sample->postgresql.conf.sample.in

"Ivan N. Taranov" writes: > This is usable for build installable postgresql.conf.SAMPLE. At the > configure phase, it is possible to include / exclude parameters in the > sample depending on the selected options (--enable - * / - disable- * > etc ..) I'm with Peter on this: you're proposing to co

pg_stat_statements issue with parallel maintenance (Was Re: WAL usage calculation patch)

On Sat, Mar 28, 2020 at 02:38:27PM +0100, Julien Rouhaud wrote: > On Sat, Mar 28, 2020 at 04:14:04PM +0530, Amit Kapila wrote: > > > > I see some basic problems with the patch. The way it tries to compute > > WAL usage for parallel stuff doesn't seem right to me. Can you share > > or point me to

Re: proposal \gcsv

On 2020-03-28 15:06, Daniel Verite wrote: Erik Rijkers wrote: 2. let the psql command-line option '--csv' honour the value given by psql -F/--field-separator (it does not do so now) or 3. add an psql -commandline option: --csv-field-separator Setting the field separator on the command l

Re: pgbench - refactor init functions with buffers

On 3/27/20 9:52 PM, Alvaro Herrera wrote: On 2020-Mar-27, Tom Lane wrote: That being the case, I'd think a better design principle is "make your new code look like the code around it", which would tend to weigh against introducing StringInfo uses into pgbench when there's none there now and a b

Re: improve transparency of bitmap-only heap scans

On Fri, Mar 27, 2020 at 9:24 PM Amit Kapila wrote: > > On Wed, Mar 25, 2020 at 5:44 PM James Coleman wrote: > > > > On Tue, Mar 24, 2020 at 11:02 PM Amit Kapila > > wrote: > > > > > > On Wed, Mar 25, 2020 at 12:44 AM Tom Lane wrote: > > > > > > > > I took a quick look through this patch. Whil

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Fri, Mar 27, 2020 at 10:58 PM Tomas Vondra wrote: > ... > >> As a side note here, I'm wondering if this (determining useful pathkeys) > >> can be made a bit smarter by looking both at query_pathkeys and pathkeys > >> useful for merging, similarly to what truncate_useless_pathkeys() does. > >> B

Re: proposal \gcsv

so 28. 3. 2020 v 15:06 odesílatel Daniel Verite napsal: > Erik Rijkers wrote: > > > 2. let the psql command-line option '--csv' honour the value given by > > psql -F/--field-separator (it does not do so now) > > > > or > > > > 3. add an psql -commandline option: > > --csv-field-separa

Re: proposal \gcsv

Erik Rijkers wrote: > 2. let the psql command-line option '--csv' honour the value given by > psql -F/--field-separator (it does not do so now) > > or > > 3. add an psql -commandline option: > --csv-field-separator Setting the field separator on the command line is already supporte

Re: base backup client as auxiliary backend process

On 2020-Jan-14, Peter Eisentraut wrote: > On 2020-01-14 07:32, Masahiko Sawada wrote: > > - Replication slot name used by this WAL receiver > > + > > + Replication slot name used by this WAL receiver. This is only set > > if a > > + permanent replication slot is set using > +

Re: WAL usage calculation patch

On Sat, Mar 28, 2020 at 04:14:04PM +0530, Amit Kapila wrote: > > I see some basic problems with the patch. The way it tries to compute > WAL usage for parallel stuff doesn't seem right to me. Can you share > or point me to any test done where we have computed WAL for parallel > operations like P

[PATCH'] Variables assigned with values that is never used.

Hi, Theses variables, are assigned with values that never is used and, can safely have their values removed. best regards, Ranier Vilela variables_assigned_unused_value.patch Description: Binary data

GSoC Proposal

Hi! Can I get some review on my GSoC proposal ? https://docs.google.com/document/d/1EiIHZjOjf6yWfGzKeHCbu8bJ6K1tCEcmPsD3i8lPXbg/edit?usp=sharing Thanks.

Re: [PATCH] Fix CommitTransactionCommand() to CallXactCallbacks() in TBLOCK_ABORT_END

From Gilles Darold on 2020-03-26T16:09:04. > Actually the callback function is called when the error is thrown: > psql:eat_rollback2.sql:20: INFO: 0: myTransactionCallback() XactEvent 2 > (is abort) level 1 <- > LOCATION: myTransactionCallback, eat_rollback.c:52 > psql:eat_

Re: PATCH: add support for IN and @> in functional-dependency statistics use

On Wed, 25 Mar 2020 at 00:28, Tomas Vondra wrote: > > Seems OK to me. > > I'd perhaps name deps_clauselist_selectivity differently, it's a bit too > similar to dependencies_clauselist_selectivity. Perhaps something like > clauselist_apply_dependencies? But that's a minor detail. > OK, I've pushed

Re: Online checksums verification in the backend

On Sat, Mar 28, 2020 at 12:28:27PM +0900, Masahiko Sawada wrote: > On Wed, 18 Mar 2020 at 19:11, Julien Rouhaud wrote: > > > > v5 attached > > Thank you for updating the patch. I have some comments: Thanks a lot for the review! > 1. > + > +pg_check_relation(relation > oid, fork >

Re: [PATCH] postgresql.conf.sample->postgresql.conf.sample.in

This is usable for build installable postgresql.conf.SAMPLE. At the configure phase, it is possible to include / exclude parameters in the sample depending on the selected options (--enable - * / - disable- * etc ..) On Sat, Mar 28, 2020 at 2:21 PM Peter Eisentraut wrote: > > On 2020-03-28 10:00,

Re: Allow some recovery parameters to be changed with reload

Hello I want to return to this discussion, since primary_conninfo is now PGC_SIGHUP (and I hope will not be reverted) > On 2019-02-08 09:19:31 +0900, Michael Paquier wrote: >>  On Thu, Feb 07, 2019 at 11:06:27PM +0100, Peter Eisentraut wrote: >>  > Probably right. I figured it would be useful to

Re: [PATCH] postgresql.conf.sample->postgresql.conf.sample.in

On 2020-03-28 10:00, i.tara...@postgrespro.ru wrote: A patch for converting postgresql.conf.sample to postgresql.conf.sample.in . This feature allows you to manage the contents of postgresql.conf.sample at the configure phase. Usage example: ./configure --enable-foo configure.in:

Re: allow online change primary_conninfo

Hello Thank you very much! I attached updated patch: walreceiver will use configured primary_slot_name as temporary slot name if wal_receiver_create_temp_slot is enabled. regards, Sergeidiff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 2de21903a1..8983cb5f5e 100644 --- a/do

Re: Possible copy and past error? (\usr\backend\commands\analyze.c)

Em sex., 27 de mar. de 2020 às 20:49, Tom Lane escreveu: > Ranier Vilela writes: > > Can someone check if there is a copy and paste error, at file: > > \usr\backend\commands\analyze.c, at lines 2225 and 2226? > > int num_mcv = stats->attr->attstattarget; > > int num_bins = stats->attr->attstatta

Re: WAL usage calculation patch

On Sat, Mar 28, 2020 at 12:54 AM Julien Rouhaud wrote: > > On Fri, Mar 27, 2020 at 8:21 PM Kirill Bychik wrote: > > > > > > All these are really valuable objections. Unfortunately, I won't be > > able to get all sorted out soon, due to total lack of time. I would be > > very glad if somebody coul

Re: doc: vacuum full, fillfactor, and "extra space"

On Wed, Jan 29, 2020 at 9:10 PM Peter Eisentraut wrote: > > On 2020-01-20 06:30, Justin Pryzby wrote: > > About your patch, I don't think this is clearer. The fillfactor stuff > is valid to be mentioned, but the way it's being proposed makes it sound > like the main purpose of VACUUM FULL is to b

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Sat, Mar 28, 2020 at 2:19 PM Dilip Kumar wrote: > > On Sat, Mar 28, 2020 at 11:56 AM Amit Kapila wrote: > > > > > > I have looked at the solution proposed and I would like to share my > > findings. I think calling ProcArrayApplyXidAssignment for each > > subtransaction is not a good idea for

Re: pgbench - refactor init functions with buffers

Hello Tom, I cannot say that I "want" to fix something which already works the same way, because it is against my coding principles. [...] I counted nearly 3500 calls under src/bin. Yeah, that's the problem. If someone does come forward with a patch to do that, I think it'd be summarily rej

Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is (fwd)

Hello Tom, Thanks for your feedback, I'd be rather unclear about what the actual feedback is, though. I'd interpret it as "pg does not care much about code coverage". Most clients are in the red on coverage.postgresql.org. I'd like pgbench at least to be in the green, but it does not look that

Re: Berserk Autovacuum (let's save next Mandrill)

On Sat, 28 Mar 2020 at 19:21, David Rowley wrote: > Thank you. Pushed. I'm unsure yet if this has caused an instability on lousyjack's run in [1]. I see that table does have 30,000 rows inserted, so it does seem probable that it may receive an autovacuum now when didn't before. I did a quick loc

Re: A bug when use get_bit() function for a long bytea string

I want to resent the mail, because last one is in wrong format and hardly to read. In addition, I think 'Size' or 'size_t' is rely on platform, they may can't work on 32bit system. So I choose 'int64' after ashutosh's review. >>I think the second argument indicates the bit position, which would

[PATCH] postgresql.conf.sample->postgresql.conf.sample.in

A patch for converting postgresql.conf.sample to postgresql.conf.sample.in . This feature allows you to manage the contents of postgresql.conf.sample at the configure phase. Usage example: ./configure --enable-foo configure.in: foo_params=$(cat <<-END foo_param1 = on foo

Re: A bug when use get_bit() function for a long bytea string

>I think the second argument indicates the bit position, which would be max >bytea length * 8. If max bytea length covers whole int32, the second argument >>needs to be wider i.e. int64. Yes, it makes sence and followed. >I think we need a similar change in byteaGetBit() and byteaSetBit() as wel

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Sat, Mar 28, 2020 at 11:56 AM Amit Kapila wrote: > > On Wed, Mar 4, 2020 at 9:14 AM Dilip Kumar wrote: > > > > On Wed, Mar 4, 2020 at 3:16 AM Tomas Vondra > > wrote: > > > > > > > > > The first thing I realized that WAL-logging of assignments in v12 does > > > both the "old" logging (using de