Re: pgsql: Include permissive/enforcing state in sepgsql log messages.

://postgr.es/m/CA+OCxowsQoLEYc=jN7OtNvOdX0Jg5L7nMYt++=k0x78hgq-...@mail.gmail.com > > Branch > -- > master > > Details > --- > https://git.postgresql.org/pg/commitdiff/134d9746364425e437a6d8eb1e2de0f3c59bfd2b Is that a bug fix to be backpatched, or a new/changed feature

Re: pgsql: Allow numeric scale to be negative or greater than precision.

On Tue, 27 Jul 2021 at 17:22, Tom Lane wrote: > > Simon Riggs writes: > > This is for migration? > > Yeah, compatibility with some other DBMSes that allow this. > > > Or does it mean very small values now occupy less space since we store > > fewer zeros? >

Re: pgsql: Allow numeric scale to be negative or greater than precision.

> src/test/regress/expected/numeric.out | 63 ++ > src/test/regress/expected/sanity_check.out | 1 + > src/test/regress/sql/numeric.sql | 34 > 7 files changed, 251 insertions(+), 43 deletions(-) > -- Simon Riggshttp://www.EnterpriseDB.com/

Re: pgsql: Document a few caveats in synchronous logical replication.

to the top of a huge discussion, so isn't useful in locating the actual discussion. -- Simon Riggshttp://www.EnterpriseDB.com/

Re: pgsql: Allow insert and update tuple routing and COPY for foreign table

On Wed, 24 Apr 2019 at 12:55, Etsuro Fujita wrote: > > My point is that this should not be necessary. > > In my opinion, I think this is necessary... > Could we decide by looking at what FDWs are known to exist? I hope we are trying to avoid breakage in the smallest number of F

Re: pgsql: Compute XID horizon for page level index vacuum on primary.

On Fri, 29 Mar 2019 at 16:32, Andres Freund wrote: > On 2019-03-29 16:20:54 +0000, Simon Riggs wrote: > > On Fri, 29 Mar 2019 at 16:12, Andres Freund wrote: > > > > > > > On 2019-03-29 15:58:14 +, Simon Riggs wrote: > > > > On Fri, 29

Re: pgsql: Compute XID horizon for page level index vacuum on primary.

On Fri, 29 Mar 2019 at 16:12, Andres Freund wrote: > On 2019-03-29 15:58:14 +0000, Simon Riggs wrote: > > On Fri, 29 Mar 2019 at 15:29, Andres Freund wrote: > > > That's far from a trivial feature imo. It seems quite possible that > we'd > > > end up wi

Re: pgsql: Compute XID horizon for page level index vacuum on primary.

On Fri, 29 Mar 2019 at 15:29, Andres Freund wrote: > On 2019-03-29 09:37:11 +0000, Simon Riggs wrote: > > > While trying to understand this, I see there is an even better way to > > optimize this. Since we are removing dead index tuples, we could alter > the > > k

Re: pgsql: Compute XID horizon for page level index vacuum on primary.

perform when we delete the page - it's possible we optimize that away completely by doing this. Since this point of the code is clearly going to be a performance issue it seems like something we should do now. -- Simon Riggshttp://www.2ndQuadrant.com/ <http://www.2ndquadrant.co

pgsql: Remove AELs from subxids correctly on standby

for multi-node isolationtester to improve test coverage for this and other HS cases. Reported-by: Simon Riggs Author: Simon Riggs Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/15378c1a15390a2b4c315f19f1644af46c7e3a15 Modified Files -- src/backend/access

pgsql: Remove spurious code comments in standby related code

Remove spurious code comments in standby related code GetRunningTransactionData() suggested that subxids were not worth optimizing away if overflowed, yet they have already been removed for that case. Changes to LogAccessExclusiveLock() API forgot to remove the prior comment when it was copied

pgsql: Remove cut-off bug from RunningTransactionData

Remove cut-off bug from RunningTransactionData 32ac7a118fc17f5 tried to fix a Hot Standby issue reported by Greg Stark, but in doing so caused a different bug to appear, noted by Andres Freund. Revoke the core changes from 32ac7a118fc17f5, leaving in its place a minor change in code ordering and

pgsql: Revert MERGE patch

Revert MERGE patch This reverts commits d204ef63776b8a00ca220adec23979091564e465, 83454e3c2b28141c0db01c7d2027e01040df5249 and a few more commits thereafter (complete list at the end) related to MERGE feature. While the feature was fully functional, with sufficient test coverage and necessary

pgsql: Improve parse representation for MERGE

Improve parse representation for MERGE Separation of parser data structures from executor, as requested by Tom Lane. Further improvements possible. While there, implement error for multiple VALUES clauses via parser to allow line number of error, as requested by Andres Freund. Author: Pavan

Re: pgsql: MERGE INSERT allows only one VALUES clause

On 5 April 2018 at 17:15, Andrew Gierth <and...@tao11.riddles.org.uk> wrote: >>>>>> "Simon" == Simon Riggs <si...@2ndquadrant.com> writes: > > Simon> MERGE INSERT allows only one VALUES clause > > That can't possibly be right; you've chan

pgsql: MERGE syntax diagram correction

MERGE syntax diagram correction Reported-by: Andrew Gierth Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ddb4158579e052ee35313c333256cb1f16ee65fa Modified Files -- doc/src/sgml/ref/merge.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

pgsql: Allow cpluspluscheck to pass by renaming variable

Allow cpluspluscheck to pass by renaming variable Use of a C++ keyword as a function name caused problems Reported-by: Álvaro Herrera Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/530e69e59b07cf94a65cfde7dd1a8b1c62b44228 Modified Files --

pgsql: MERGE minor errata

MERGE minor errata Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/01b88b4df5e2df0365cceaf79a039214d9f05273 Modified Files -- src/backend/executor/README | 4 ++-- src/backend/executor/execMerge.c | 2 +- src/backend/executor/execPartition.c

pgsql: MERGE fix variable warning in non-assert builds

MERGE fix variable warning in non-assert builds Author: Jesper Pedersen Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3af7b2b0d497cfc240ffc8098ef068adb30048a2 Modified Files -- src/backend/executor/execMerge.c | 6 ++ 1 file changed, 2

pgsql: MERGE INSERT allows only one VALUES clause

MERGE INSERT allows only one VALUES clause Doc syntax and brief mention of restriction Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a5d86181ecc9c441d4c327771c43134de59549cd Modified Files -- doc/src/sgml/ref/merge.sgml | 3 ++- 1 file changed, 2

pgsql: MERGE post-commit review

mt_merge_subcommands flags into execMerge.h * Rename opt_and_condition to opt_merge_when_and_condition * Wordsmith various comments Author: Pavan Deolasee Reviewer: Simon Riggs Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4b2d44031f8c005f6f86364d7663858b6b5bdd14 Modified Files

pgsql: Tab completion for MERGE

Tab completion for MERGE Author: Pavan Deolasee Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4923550c20ae6d122ae0867480a7de8b040f7d80 Modified Files -- src/bin/psql/tab-complete.c | 87 + 1 file changed, 81

pgsql: WITH support in MERGE

WITH support in MERGE Author: Peter Geoghegan Recursive support removed, no tests Docs added by me Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/aa3faa3c7a7a49b3318059ccaf79bc1886a64707 Modified Files -- doc/src/sgml/ref/merge.sgml | 15 +++-

pgsql: New files for MERGE

New files for MERGE Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/83454e3c2b28141c0db01c7d2027e01040df5249 Modified Files -- doc/src/sgml/ref/merge.sgml| 603 +++ src/backend/executor/nodeMerge.c | 575

pgsql: MERGE SQL Command following SQL:2016

tation, including full isolation tests to demonstrate the concurrent behavior. This version written from scratch in 2017 by Simon Riggs, using docs and tests originally written in 2009. Later work from Pavan Deolasee has been both complex and deep, leaving the lead author credit now in his

Re: pgsql: Modified files for MERGE

On 2 April 2018 at 21:54, Andres Freund <and...@anarazel.de> wrote: > Hi, > > On 2018-04-02 21:50:28 +0100, Simon Riggs wrote: >> I didn't think it mattered, but clearly does. Reverted before you >> asked. > > I don't think the BF failures were related to the spli

pgsql: Revert "MERGE SQL Command following SQL:2016"

Revert "MERGE SQL Command following SQL:2016" This reverts commit e6597dc3533946b98acba7871bd4ca1f7a3d4c1d. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/aa5877bb26347c58a34aee4e460eb1e1123bb096 Modified Files -- doc/src/sgml/ref/merge.sgml

pgsql: Revert "Modified files for MERGE"

Revert "Modified files for MERGE" This reverts commit 354f13855e6381d288dfaa52bcd4f2cb0fd4a5eb. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7cf8a5c302735d193dcf901b87e03e324903c632 Modified Files -- contrib/test_decoding/expected/ddl.out| 46

pgsql: Modified files for MERGE

Modified files for MERGE Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/354f13855e6381d288dfaa52bcd4f2cb0fd4a5eb Modified Files -- contrib/test_decoding/expected/ddl.out| 46 contrib/test_decoding/sql/ddl.sql | 16 ++

pgsql: MERGE SQL Command following SQL:2016

tation, including full isolation tests to demonstrate the concurrent behavior. This version written from scratch in 2017 by Simon Riggs, using docs and tests originally written in 2009. Later work from Pavan Deolasee has been both complex and deep, leaving the lead author credit now in his

Re: pgsql: Optimize btree insertions for common case of increasing values

time on this. It would be nice to get > a second opinion on some of this, if at all possible. I don't see any need to change any of these things. This is a tuning patch and none of the above affects correctness of what has been committed. If you can find non-performant cases that require fur

Re: pgsql: Add documentation for the JIT feature.

een in use for many years in a range of concepts. particularly in manufacturing/logistics and project management. The feature is JIT compilation, not just "JIT". If we had replication with eager consensus, it would be silly to call the feature simply "eager" with no ot

pgsql: Store 2PC GID in commit/abort WAL recs for logical decoding

patch 0003 in the logical decoding 2PC series.) Authors: Nikhil Sontakke, Stas Kelvich Reviewed-by: Simon Riggs, Andres Freund Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1eb6d6527aae264b3e0b9c95aa70bb7a594ad1cf Modified Files -- src/backend/access

pgsql: Use pg_stat_get_xact* functions within xacts

Use pg_stat_get_xact* functions within xacts Resolve build farm failures from c203d6cf81b4d7e43, diagnosed by Tom Lane. The output of pg_stat_get_xact_tuples_hot_updated() and friends is not guaranteed to show anything after the transaction completes. Data is flushed slowly to stats collector,

Re: pgsql: Allow HOT updates for some expression indexes

On 27 March 2018 at 20:11, Simon Riggs <si...@2ndquadrant.com> wrote: > Buildfarm failure seen, investigating Error on FreeBSD only , perhaps timing-related as a result of using pg_stat_get_xact_tuples_hot_updated() in tests. Will wait to collect other failures -- Si

Re: pgsql: Improve ANALYZE's strategy for finding MCVs.

rs in both > cases. In addition, the algorithm responds better to increasing the > statistics target, allowing more values to be included in the MCV list > when more of the table is sampled. > > Jeff Janes, substantially modified by me. Reviewed by John Naylor and > Tomas Vondra

pgsql: Default monitoring roles - errata

Default monitoring roles - errata 25fff40798fc4ac11a241bfd9ab0c45c085e2212 introduced default monitoring roles. Apply these corrections: * Allow access to pg_stat_get_wal_senders() by role pg_read_all_stats * Correct comment in pg_stat_get_wal_receiver() to show it is no longer

pgsql: Fix typo in recent commit

Fix typo in recent commit Typo in 9c7d06d60680c7f00d931233873dee81fdb311c6 Reported-by: Masahiko Sawada Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4e54dd2e0a750352ce2a5c45d1cc9183e887eec3 Modified Files -- src/backend/replication/slotfuncs.c | 2

pgsql: Ability to advance replication slots

phase (after we reached SNAPBUILD_FULL_SNAPSHOT) of replication slot creation faster, especially when there are big transactions as the reorder buffer does not have to deal with data changes and does not have to spill to disk. Author: Petr Jelinek Reviewed-by: Simon Riggs Branch -- master

Re: pgsql: Implement channel binding tls-server-end-point for SCRAM

anual emails every time. We do know who the commits are coming from and we have their email address. It would be useful to get automatic message giving a summary of buildfarm results at 15, 30 and 60 minute intervals, even if it is just ALL CLEAR. -- Simon Riggshttp://www.

pgsql: Add TIMELINE to backup_label file

Add TIMELINE to backup_label file Allows new test to confirm timelines match Author: Michael Paquier Reviewed-by: David Steele Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6271fceb8a4f07dafe9d67dcf7e849b319bb2647 Modified Files --

pgsql: Set es_output_cid in replication worker

Set es_output_cid in replication worker Allows triggers to operate correctly Author: Petr Jelinek Reported-by: Konstantin Knizhnik Branch -- REL_10_STABLE Details ---

pgsql: Additional docs for toast_tuple_target changes

Additional docs for toast_tuple_target changes Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/117469006bf525c6e8dc84cb9fcbdc4c1a050878 Modified Files -- doc/src/sgml/storage.sgml | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-)

pgsql: Pad XLogReaderState's per-buffer data_bufsz more aggressively.

Pad XLogReaderState's per-buffer data_bufsz more aggressively. Originally, we palloc'd this buffer just barely big enough to hold the largest xlog backup block seen so far. We now MAXALIGN the palloc size. The original coding could result in many repeated palloc cycles, in the worst case where

Re: pgsql: Generational memory allocator

On 27 November 2017 at 06:42, Tom Lane <t...@sss.pgh.pa.us> wrote: > Simon Riggs <si...@2ndquadrant.com> writes: >> On 27 November 2017 at 05:53, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Well, let's not overthink this, because anything under 8K is going to >

Re: pgsql: Generational memory allocator

On 27 November 2017 at 05:53, Tom Lane <t...@sss.pgh.pa.us> wrote: > Simon Riggs <si...@2ndquadrant.com> writes: >> On 27 November 2017 at 04:46, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Well, I'm concerned about the possibility of a lot of palloc thrashi

Re: pgsql: Generational memory allocator

On 27 November 2017 at 04:46, Tom Lane <t...@sss.pgh.pa.us> wrote: > Simon Riggs <si...@2ndquadrant.com> writes: >> On 26 November 2017 at 08:46, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I've confirmed that the attached is sufficient to stop the valgrind crash

Re: pgsql: Generational memory allocator

aces make it look unrelated >> to the GenerationContext changes, but if it's not related, how come >> skink was passing before that patch went in? > > I've pushed fixes for everything that I could find wrong in generation.c > (and there was a lot :-(). Thanks very much for doing that. I

Re: pgsql: Generational memory allocator

sight and hardly >> Andres' fault. >> > > A fix for this will be in the next buildfarm release. Thanks -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: pgsql: Generational memory allocator

typical size for the "main data" part > of a WAL record? We reuse the buffer and only pfree/palloc when we need to enlarge the buffer, so not sure we need to do the doubling thing and it probably doesn't matter what the typical size is. So I think we're just good to go with your patch. --

Re: pgsql: Generational memory allocator

ht not really work if size_t and void * are different sizes, > because then there could be additional padding in the struct; but > that seems very unlikely.) Oh, OK, thanks. It sunk in what was needed while flying, but that's better than my efforts. -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: pgsql: Generational memory allocator

t line 122, "there must not be any padding to reach a MAXALIGN boundary here!". So I'll wait for Tomas to comment. (I'm just about to catch a long flight, so will be offline for 24 hours, so we may need to revert this before I get back if it is difficult to resolve.) -- Simon Riggs

pgsql: Generational memory allocator

and improve performance. Author: Tomas Vondra Reviewed-by: Simon Riggs Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a4ccc1cef5a04cc054af83bc4582a045d5232cb3 Modified Files -- src/backend/replication/logical/reorderbuffer.c | 80 +-- src/backend/utils/mmgr

Re: [COMMITTERS] pgsql: Remove secondary checkpoint

On 20 November 2017 at 15:55, Andres Freund <and...@anarazel.de> wrote: > On 2017-11-20 15:50:40 -0500, Simon Riggs wrote: >> On 20 November 2017 at 08:38, Amit Kapila <amit.kapil...@gmail.com> wrote: >> > Your patch looks correct to me. I can reproduce the proble

pgsql: Fix pg_control_checkpoint from commit 4b0d28de06

Fix pg_control_checkpoint from commit 4b0d28de06 Author: Simon Riggs <si...@2ndquadrant.com> Reported-By: Andreas Seltenreich <seltenre...@gmx.de> Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2ede45c3a49e484edfa143850d55eb32dba296de Mo

Re: [COMMITTERS] pgsql: Remove secondary checkpoint

8. >> ` >> >> The attached patch fixes it for me. >> > > > Your patch looks correct to me. I can reproduce the problem and > verified that patch fixes the problem. It is better to track this in > CF if not already tracked. What email and patch is this referring to? -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: pgsql: Parameter toast_tuple_target controls TOAST for new rows

RAGE = EXTERNAL on the data column to disable > compression would help make things more stable, too. That was already set at line 350 -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: pgsql: Parameter toast_tuple_target controls TOAST for new rows

On 19 November 2017 at 19:52, Andres Freund <and...@anarazel.de> wrote: > On 2017-11-19 19:49:01 -0500, Tom Lane wrote: >> Andres Freund <and...@anarazel.de> writes: >> > On 2017-11-19 19:08:48 -0500, Simon Riggs wrote: >> >> Am investigating the few buil

Re: pgsql: Parameter toast_tuple_target controls TOAST for new rows

On 19 November 2017 at 19:49, Tom Lane <t...@sss.pgh.pa.us> wrote: > Andres Freund <and...@anarazel.de> writes: >> On 2017-11-19 19:08:48 -0500, Simon Riggs wrote: >>> Am investigating the few buildfarm failures > >> The tests look very sensitive to differ

pgsql: Reduce test variability for toast_tuple_target test

Reduce test variability for toast_tuple_target test Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/56f34686220731eef72dfd129519b25f28406db1 Modified Files -- src/test/regress/expected/strings.out | 50 ++-

Re: pgsql: Parameter toast_tuple_target controls TOAST for new rows

On 19 November 2017 at 17:52, Simon Riggs <si...@2ndquadrant.com> wrote: > Parameter toast_tuple_target controls TOAST for new rows > > Specifies the point at which we try to move long column values > into TOAST tables. > > No effect on existing rows. > > Discussion

pgsql: Parameter toast_tuple_target controls TOAST for new rows

Parameter toast_tuple_target controls TOAST for new rows Specifies the point at which we try to move long column values into TOAST tables. No effect on existing rows. Discussion: https://postgr.es/m/CANP8+jKsVmw6CX6YP9z7zqkTzcKV1+Uzr3XjKcZW=2ya00o...@mail.gmail.com Author: Simon Riggs <