Re: PG 12 beta 1 segfault during analyze

Steve Singer writes: > The attached patch fixes the issue. Hmm, that's a pretty obvious mistake :-( but after some fooling around I've not been able to cause a crash with it. I wonder what test case you were using, on what platform? regards, tom lane

Re: idea: log_statement_sample_rate - bottom limit for sampling

Hi po 17. 6. 2019 v 22:40 odesílatel Pavel Stehule napsal: > Hi > > čt 6. 6. 2019 v 10:48 odesílatel Gilles Darold napsal: > >> Le 06/06/2019 à 10:38, Pavel Stehule a écrit : >> > Hi >> > >> > I like the idea of sampling slow statements via >> > log_statement_sample_rate. But I miss some

Re: PG 12 beta 1 segfault during analyze

On 6/15/19 10:18 PM, Tom Lane wrote: Steve Singer writes: I encountered the following segfault when running against a PG 12 beta1 during a analyze against a table. Nobody else has reported this, so you're going to have to work on producing a self-contained test case, or else debugging it

Re: Race conditions with TAP test for syncrep

On Mon, Jun 17, 2019 at 10:50:39AM -0400, Alvaro Herrera wrote: > Hmm, this introduces a bit of latency: it waits for each standby to be > fully up before initializing the next standby. Maybe it would be more > convenient to split the primitives: keep the current one to start the > standby, and

Re: Fix typos and inconsistencies for v11+

On Mon, Jun 17, 2019 at 10:32:13AM +0300, Alexander Lakhin wrote: > Then I will go deeper for v10 and beyond. If older versions are not > going to be fixed, I will prepare patches only for the master branch. When it comes to fixing typos in in anything which is not directly user-visible like the

Re: SQL/JSON path issues/questions

On 6/17/19 4:13 PM, Alexander Korotkov wrote: > On Mon, Jun 17, 2019 at 8:40 PM Thom Brown wrote: "is unknown" suggests a boolean output, but the example shows an output of "infinity". While I understand what it does, this appears inconsistent with all other "is..." functions

Re: idea: log_statement_sample_rate - bottom limit for sampling

Hi čt 6. 6. 2019 v 10:48 odesílatel Gilles Darold napsal: > Le 06/06/2019 à 10:38, Pavel Stehule a écrit : > > Hi > > > > I like the idea of sampling slow statements via > > log_statement_sample_rate. But I miss some parameter that can ensure > > so every query executed over this limit is

Re: SQL/JSON path issues/questions

On Mon, Jun 17, 2019 at 8:40 PM Thom Brown wrote: > On Fri, 14 Jun 2019 at 08:16, Kyotaro Horiguchi > wrote: > > > > Hi, Thom. > > > > At Thu, 13 Jun 2019 14:59:51 +0100, Thom Brown wrote > > in > > > Hi, > > > > > > I've been reading through the documentation regarding jsonpath and > > >

Re: Fix up grouping sets reorder

> "Andres" == Andres Freund writes: >> During the reorder of grouping sets into correct prefix order, if >> only one aggregation pass is needed, we follow the order of the >> ORDER BY clause to the extent possible, to minimize the chance that >> we add unnecessary sorts. This is

Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2019-06-17 14:34:58 -0400, Stephen Frost wrote: > > * Andres Freund (and...@anarazel.de) wrote: > > > On 2019-06-14 23:14:09 +0100, Andrew Gierth wrote: > > > > So here is my current proposed fix. > > > > > > Before pushing a commit

Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)

Hi, On 2019-06-17 14:34:58 -0400, Stephen Frost wrote: > * Andres Freund (and...@anarazel.de) wrote: > > On 2019-06-14 23:14:09 +0100, Andrew Gierth wrote: > > > So here is my current proposed fix. > > > > Before pushing a commit that's controversial - and this clearly seems to > > somewhat be -

Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2019-06-14 23:14:09 +0100, Andrew Gierth wrote: > > So here is my current proposed fix. > > Before pushing a commit that's controversial - and this clearly seems to > somewhat be - it'd be good to give others a heads up that you intend

Re: SQL/JSON path issues/questions

On Fri, 14 Jun 2019 at 08:16, Kyotaro Horiguchi wrote: > > Hi, Thom. > > At Thu, 13 Jun 2019 14:59:51 +0100, Thom Brown wrote > in > > Hi, > > > > I've been reading through the documentation regarding jsonpath and > > jsonb_path_query etc., and I have found it lacking explanation for > > some

Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)

On 2019-06-14 23:14:09 +0100, Andrew Gierth wrote: > So here is my current proposed fix. Before pushing a commit that's controversial - and this clearly seems to somewhat be - it'd be good to give others a heads up that you intend to do so, so they can object. Rather than just pushing less than

Re: assertion at postmaster start

Andres Freund writes: > On 2019-06-15 12:09:50 -0400, Alvaro Herrera wrote: >> Once in a blue moon I get this assertion failure on server start: >> TRAP: FailedAssertion(«!(AbortStartTime == 0)», Archivo: >> «/pgsql/source/master/src/backend/postmaster/postmaster.c», Línea: 2957) > And "server

Re: initial random incompatibility

Alvaro Herrera writes: > On 2019-Jun-17, Darafei "Komяpa" Praliaskouski wrote: >> I cannot find traces, but I believe there was a Twitter poll on which >> random do people get after setseed() in postgres, and we found at least >> three distinct sequences across different builds. > In different

Re: Fix up grouping sets reorder

Hi, On 2019-06-17 17:23:11 +0800, Richard Guo wrote: > During the reorder of grouping sets into correct prefix order, if only > one aggregation pass is needed, we follow the order of the ORDER BY > clause to the extent possible, to minimize the chance that we add > unnecessary sorts. This is

Re: assertion at postmaster start

Hi, On 2019-06-15 12:09:50 -0400, Alvaro Herrera wrote: > Once in a blue moon I get this assertion failure on server start: > > 2019-06-15 12:00:29.650 -04 [30080] LOG: iniciando PostgreSQL 12beta1 on > x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0, > 64-bit >

Re: initial random incompatibility

On 2019-Jun-17, Darafei "Komяpa" Praliaskouski wrote: > I cannot find traces, but I believe there was a Twitter poll on which > random do people get after setseed() in postgres, and we found at least > three distinct sequences across different builds. In different machines or different build

Re: how to run encoding-dependent tests by default

Hi, On 2019-06-17 16:56:00 +0200, Peter Eisentraut wrote: > There is a fair amount of collation-related functionality that is only > being tested by sql/collate.icu.utf8.sql and sql/collate.linux.utf8.sql, > which are not run by default. There is more functionality planned in > this area, so

Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions

Greetings, * Ian Barwick (ian.barw...@2ndquadrant.com) wrote: > On 6/15/19 1:08 AM, Stephen Frost wrote: > > * Ian Barwick (ian.barw...@2ndquadrant.com) wrote: > >> Consider the following cascading standby setup with PostgreSQL 12: > >> > >> - there exists a running primary "A" > >> - standby "B"

how to run encoding-dependent tests by default

There is a fair amount of collation-related functionality that is only being tested by sql/collate.icu.utf8.sql and sql/collate.linux.utf8.sql, which are not run by default. There is more functionality planned in this area, so making the testing more straightforward would be useful. The reason

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On Mon, Jun 17, 2019 at 10:33:11AM -0400, Stephen Frost wrote: Greetings, * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote: In any case, if we end up with a more complex/advanced design, I've already voiced my opinion that binding the keys to tablespaces is the wrong abstraction, and I

Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions

On 6/17/19 2:58 AM, Magnus Hagander wrote: On Sun, Jun 16, 2019 at 7:43 PM Stephen Frost mailto:sfr...@snowman.net>> wrote: * Tom Lane (t...@sss.pgh.pa.us ) wrote: > Stephen Frost mailto:sfr...@snowman.net>> writes: > > what we should do is clean them

Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions

Hi On 6/15/19 1:08 AM, Stephen Frost wrote: > Greetings, > > * Ian Barwick (ian.barw...@2ndquadrant.com) wrote: >> Consider the following cascading standby setup with PostgreSQL 12: >> >> - there exists a running primary "A" >> - standby "B" is cloned from primary "A" using "pg_basebackup

Re: Race conditions with TAP test for syncrep

On 2019-Jun-17, Michael Paquier wrote: > Attached is a patch to improve the stability of the test. The fix I > am proposing is very simple: in order to make sure that a standby is > added into the WAL sender array of the primary, let's check after > pg_stat_replication after a standby is

Re: pg_log_fatal vs pg_log_error

On 2019-06-17 14:19, Antonin Houska wrote: > Can anyone please give me a hint (and possibly add some comments to the code) > when pg_log_fatal() should be used in frontend code and when it's appropriate > to call pg_log_error()? The current use does not seem very consistent. For a program that

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Greetings, * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote: > In any case, if we end up with a more complex/advanced design, I've > already voiced my opinion that binding the keys to tablespaces is the > wrong abstraction, and I think we'll regret it eventually. For example, > why have we

Re: Binary support for pgoutput plugin

On Fri, 14 Jun 2019 at 15:42, Dave Cramer wrote: > > Dave Cramer > > > On Fri, 14 Jun 2019 at 14:36, Tomas Vondra > wrote: > >> On Wed, Jun 12, 2019 at 10:35:48AM -0400, Dave Cramer wrote: >> >On Mon, 10 Jun 2019 at 07:49, Petr Jelinek > > >> >wrote: >> > >> >> Hi, >> >> >> >> On 10/06/2019

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On Mon, Jun 17, 2019 at 08:29:02AM -0400, Joe Conway wrote: On 6/17/19 8:12 AM, Stephen Frost wrote: But there's about 0% chance we'll get that in v1, of course, so we need s "minimum viable product" to build on anyway. There seems like a whole lot of space between something very elaborate

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On Mon, Jun 17, 2019 at 08:39:27AM -0400, Joe Conway wrote: On 6/17/19 8:29 AM, Masahiko Sawada wrote: From perspective of cryptographic, I think the fine grained TDE would be better solution. Therefore if we eventually want the fine grained TDE I wonder if it might be better to develop the

Re: POC: Cleaning up orphaned files using undo logs

On Mon, Jun 17, 2019 at 6:03 AM Amit Kapila wrote: > The idea was that it could be use for multiple purposes like 'rolling > back complete xact', 'rolling back subxact', 'rollback at page-level' > or any similar future need even though not all code paths use that > function. I am not wedded to

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Antonin Houska wrote: > Masahiko Sawada wrote: > > > The cluster-wide TDE eventually encrypts SLRU data and all WAL > > including non-user data related WAL while table/tablespace TDE doesn't > > unless we develop such functionality. In addition, the cluster-wide > > TDE also encrypts system

Re: pg_log_fatal vs pg_log_error

On Mon, Jun 17, 2019 at 03:39:49PM +0200, Antonin Houska wrote: > I'd understand this if pg_log_fatal() called exit() itself, but it does not > (unless I miss something). Oops. My apologies. I have my own wrapper of pg_log_fatal() for an internal tool which does an exit on top of the logging in

Re: pg_log_fatal vs pg_log_error

Michael Paquier wrote: > On Mon, Jun 17, 2019 at 02:19:30PM +0200, Antonin Houska wrote: > > I'd expect that the pg_log_fatal() should be called when the error is > > serious > > enough to cause premature exit, but I can see cases where even > > pg_log_error() > > is followed by exit(1).

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Masahiko Sawada wrote: > The cluster-wide TDE eventually encrypts SLRU data and all WAL > including non-user data related WAL while table/tablespace TDE doesn't > unless we develop such functionality. In addition, the cluster-wide > TDE also encrypts system catalogs but in table/tablespace TDE

Re: Batch insert in CTAS/MatView code

Hi all, I've been working other things until recently I restarted the work, profiling & refactoring the code. It's been a long time since the last patch was proposed. The new patch has now been firstly refactored due to 4da597edf1bae0cf0453b5ed6fc4347b6334dfe1 (Make TupleTableSlots extensible,

Re: pg_log_fatal vs pg_log_error

On Mon, Jun 17, 2019 at 02:19:30PM +0200, Antonin Houska wrote: > I'd expect that the pg_log_fatal() should be called when the error is serious > enough to cause premature exit, but I can see cases where even pg_log_error() > is followed by exit(1). pg_waldump makes me feel that pg_log_error() is

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 6/17/19 8:29 AM, Masahiko Sawada wrote: > From perspective of cryptographic, I think the fine grained TDE would > be better solution. Therefore if we eventually want the fine grained > TDE I wonder if it might be better to develop the table/tablespace TDE > first while keeping it simple as

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On Fri, Jun 14, 2019 at 7:41 AM Tomas Vondra wrote: > I personally find the idea of encrypting tablespaces rather strange. > Tablespaces are meant to define hysical location for objects, but this > would also use them to "mark" objects as encrypted or not. That just > seems misguided and would

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 6/17/19 8:12 AM, Stephen Frost wrote: >> But there's about 0% chance we'll get that in v1, of course, so we need >> s "minimum viable product" to build on anyway. > > There seems like a whole lot of space between something very elaborate > and only supporting one key. I think this is exactly

pg_log_fatal vs pg_log_error

Can anyone please give me a hint (and possibly add some comments to the code) when pg_log_fatal() should be used in frontend code and when it's appropriate to call pg_log_error()? The current use does not seem very consistent. I'd expect that the pg_log_fatal() should be called when the error is

Re: CREATE STATISTICS documentation bug

On Sat, Jun 15, 2019 at 7:22 PM Tomas Vondra wrote: > I've pushed a fix for the docs issue. Thanks. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)

Re: Tom Lane 2019-06-14 <26948.1560517...@sss.pgh.pa.us> > > /usr/lib/postgresql/12/bin/initdb -D pgdata > > $ grep timezone pgdata/postgresql.conf > > log_timezone = 'Etc/UTC' > > timezone = 'Etc/UTC' > > That's what I'd expect. Do you think your upthread report of HEAD > picking "Etc/UCT" was

Re: SQL/JSON path issues/questions

On 6/17/19 11:36 AM, Alexander Korotkov wrote: I'm going to push attached 3 patches if no objections. Regarding 0003-Separate-two-distinctive-json-errors.patch, I think it requires more thoughts. RETURN_ERROR(ereport(ERROR,

Re: POC: Cleaning up orphaned files using undo logs

On Thu, Jun 13, 2019 at 3:13 AM Robert Haas wrote: > > On Mon, May 27, 2019 at 5:59 AM Amit Kapila wrote: > > Apart from fixing the above comments, the patch is rebased on latest > > undo patchset. As of now, I have split the binaryheap.c changes into > > a separate patch. We are stilll

Re: Generating partitioning tuple conversion maps faster

Hi, Any chance for a backport to PG 11? cherry-pick apply cleanly and with a 100 columns table it improves performance nicely (20%). Regards Didier On Sat, Jul 14, 2018 at 1:25 AM David Rowley wrote: > > On 14 July 2018 at 04:57, Heikki Linnakangas wrote: > > Pushed, thanks! > > Thanks for

Fix up grouping sets reorder

Hi all, During the reorder of grouping sets into correct prefix order, if only one aggregation pass is needed, we follow the order of the ORDER BY clause to the extent possible, to minimize the chance that we add unnecessary sorts. This is implemented in preprocess_grouping_sets -->

Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3

Bruce Momjian wrote: > On Mon, Jun 3, 2019 at 12:04:54PM -0400, Robert Haas wrote: > > > > What I'm talking about here is that it also has to be reasonably > > possible to write an encryption key command that does something > > useful. I don't have a really clear vision for how that's going

Re: SQL/JSON path issues/questions

I'm going to push attached 3 patches if no objections. Regarding 0003-Separate-two-distinctive-json-errors.patch, I think it requires more thoughts. RETURN_ERROR(ereport(ERROR, (errcode(ERRCODE_SINGLETON_JSON_ITEM_REQUIRED),

Strange error message in xlog.c

Hello, I had an trouble report that the reporter had the following error messages. FATAL: XX000: requested timeline 175 is not a child of this server's history DETAIL: Latest checkpoint is at 1A/D628 on timeline 172, but in the history of the requested timeline, the server forked off from

RE: [PATCH] Speedup truncates of relation forks

Hi all, Attached is the v2 of the patch. I added the optimization that Sawada-san suggested for DropRelFileNodeBuffers, although I did not acquire the lock when comparing the minBlock and target block. There's actually a comment written in the source code that we could pre-check buffer tag for

Still some references to configure-time WAL segment size option in msvc scripts

Hi all, I have just bumped into $subject, which makes no sense now as this is an init-time option. Any objections if I remove this code as per the attached? Thanks, -- Michael diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm index 33ba15c15e..cbe019e524 100644 ---

Re: Fix typos and inconsistencies for v11+

17.06.2019 10:16, Michael Paquier wrote: > On Sat, Jun 15, 2019 at 06:00:00PM +0300, Alexander Lakhin wrote: >> Two summary patches for REL_11_STABLE and master are attached. > Thanks. I have committed to HEAD most of the inconsistencies you have > pointed out. Thank you, Michael. Then I will go

Re: Do we expect tests to work with default_transaction_isolation=serializable

On Sat, Jun 15, 2019 at 11:47:39AM -0700, Noah Misch wrote: > On Sun, May 19, 2019 at 03:55:06PM -0700, Andres Freund wrote: >> Currently that's not the case. When running check-world with PGOPTIONS >> set to -c default_transaction_isolation=serializable I get easy to fix >> failures (isolation,

Re: Fix typos and inconsistencies for v11+

On Sat, Jun 15, 2019 at 06:00:00PM +0300, Alexander Lakhin wrote: > Two summary patches for REL_11_STABLE and master are attached. Thanks. I have committed to HEAD most of the inconsistencies you have pointed out. -- Michael signature.asc Description: PGP signature