Race conditions with TAP test for syncrep

Hi all, Alvaro has reported a rather rare buildfarm failure involving 007_sync_rep.pl to which I have responded here: https://www.postgresql.org/message-id/20190613060123.gc1...@paquier.xyz The buildfarm failure is here:

Re: proposal: new polymorphic types - commontype and commontypearray

Hi pá 14. 6. 2019 v 6:09 odesílatel Pavel Stehule napsal: > > > čt 13. 6. 2019 v 2:37 odesílatel Tom Lane napsal: > >> Greg Stark writes: >> > The proposals I see above are "commontype", "supertype", >> "anycommontype", >> > and various abbreviations of those. I would humbly add

Re: Problem with default partition pruning

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, passed Spec compliant: not tested Documentation:not tested Hi Hosoya-san, I tested different types of key values, and

RE: Speed up transaction completion faster after many relations are accessed in a transaction

From: David Rowley [mailto:david.row...@2ndquadrant.com] > I've revised the patch to add a new constant named > LOCKMETHODLOCALHASH_SHRINK_SIZE. I've set this to 64 for now. Once the hash Thank you, and good performance. The patch passed make check. I'm OK with the current patch, but I have a

Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock

On Sun, Jun 16, 2019 at 10:27:25PM -0400, Tom Lane wrote: > Alvaro Herrera writes: >> On 2019-Jun-17, Michael Paquier wrote: >>> Could you revert asap please then? > >> Done. > > Thanks. Thanks, Alvaro. -- Michael signature.asc Description: PGP signature

Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock

Alvaro Herrera writes: > On 2019-Jun-17, Michael Paquier wrote: >> Could you revert asap please then? > Done. Thanks. regards, tom lane

Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock

On 2019-Jun-17, Michael Paquier wrote: > On Sun, Jun 16, 2019 at 09:10:13PM -0400, Tom Lane wrote: > > Yeah, let's do that. I don't want to risk shipping broken code. > > We can try again for the next updates. > > Could you revert asap please then? Done. I initially thought to keep the test

Re: nbtdesc.c and nbtpage.c are inconsistent with XLOG_BTREE_META_CLEANUP (11~)

On Sun, Jun 16, 2019 at 7:05 PM Michael Paquier wrote: > I would have supposed that more people scan WAL records using the > description callbacks. The WAL record in question, XLOG_BTREE_META_CLEANUP, is certainly one of the less common record types used by nbtree. I agree that this should have

Re: nbtdesc.c and nbtpage.c are inconsistent with XLOG_BTREE_META_CLEANUP (11~)

On Sun, Jun 16, 2019 at 06:54:57PM -0700, Peter Geoghegan wrote: > On Sun, Jun 16, 2019 at 6:31 PM Michael Paquier wrote: >> I think that we could just patch nbtpage.c so as we fetch the >> metadata using XLogRecGetBlockData(), and log its data. > > Don't you mean nbtdesc.c? Yeah I meant

Re: nbtdesc.c and nbtpage.c are inconsistent with XLOG_BTREE_META_CLEANUP (11~)

On Sun, Jun 16, 2019 at 6:31 PM Michael Paquier wrote: > I think that we could just patch nbtpage.c so as we fetch the > metadata using XLogRecGetBlockData(), and log its data. Don't you mean nbtdesc.c? > The error > comes from 3d92796, which is one year-old and has been visibly > committed

Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock

On Sun, Jun 16, 2019 at 09:10:13PM -0400, Tom Lane wrote: > Yeah, let's do that. I don't want to risk shipping broken code. > We can try again for the next updates. Could you revert asap please then? -- Michael signature.asc Description: PGP signature

nbtdesc.c and nbtpage.c are inconsistent with XLOG_BTREE_META_CLEANUP (11~)

Hi all, (Adding in CC relevant committer and author, Teodor and Alexander) I have been looking today at a crash of pg_waldump on one of the test builds keeping running in some internal environment. Luckily, I have been able to put my hands on a core file with 11.2 running. The backtrace is not

Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock

Alvaro Herrera writes: > On 2019-Jun-16, Tom Lane wrote: >> If you're going to push anything before tomorrow's wrap, please do it >> *now* not later. We're running out of time to get a full sample of >> buildfarm results. > Yeah, I had to bail out earlier today, so the only thing I'm confident

Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock

On 2019-Jun-16, Tom Lane wrote: > Alvaro Herrera writes: > > I'm going to push the change of lifetime of the variable for now. > > If you're going to push anything before tomorrow's wrap, please do it > *now* not later. We're running out of time to get a full sample of > buildfarm results.

Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock

Alvaro Herrera writes: > I'm going to push the change of lifetime of the variable for now. If you're going to push anything before tomorrow's wrap, please do it *now* not later. We're running out of time to get a full sample of buildfarm results. regards, tom lane

Re: range_agg

On Wed, May 8, 2019 at 9:54 PM Paul A Jungwirth wrote: > Here is an initial patch. I'd love to have some feedback! :-) Here is a v2 rebased off current master. No substantive changes, but it does fix one trivial git conflict. After talking with David in Ottawa and hearing a good use-case from

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

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

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

On Sun, Jun 16, 2019 at 02:10:23PM -0400, Stephen Frost wrote: Greetings, * Joe Conway (m...@joeconway.com) wrote: On 6/16/19 9:45 AM, Bruce Momjian wrote: > On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote: >> In any case it doesn't address my first point, which is limiting the >>

Re: $host_cpu -> $target_cpu in configure?

Noah Misch writes: > https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html > describes the intended usage. When cross-compiling, $host_cpu is the machine > able to run the resulting PostgreSQL installation, and $build_cpu is the > machine creating

Re: $host_cpu -> $target_cpu in configure?

On Sun, Jun 16, 2019 at 12:56:52PM -0400, Tom Lane wrote: > There are a few places in configure and the makefiles that are looking > at $host_cpu to decide what to do. As far as I can tell, almost all of > them are wrong and should be looking at $target_cpu instead. (The > lack of complaints

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

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Sun, Jun 16, 2019 at 12:42:55PM -0400, Joe Conway wrote: > > On 6/16/19 9:45 AM, Bruce Momjian wrote: > > > On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote: > > >> In any case it doesn't address my first point, which is limiting

Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock

On 2019-Jun-15, Alvaro Herrera wrote: > But that's not the danger ... with the current coding, it's initialized > to false every time through that block; that means the tuple lock will > never be skipped if we jump back to l3. So the danger is that the first > iteration sets the variable, then

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

On Sun, Jun 16, 2019 at 12:42:55PM -0400, Joe Conway wrote: > On 6/16/19 9:45 AM, Bruce Momjian wrote: > > On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote: > >> In any case it doesn't address my first point, which is limiting the > >> volume encrypted with the same key. Another valid

Re: Extracting only the columns needed for a query

On Sat, Jun 15, 2019 at 10:02 AM Tom Lane wrote: > > Approach B: after parsing and/or after planning > > If we wanted to do something about this, making the planner record > the set of used columns seems like the thing to do. We could avoid > the expense of doing it when it's not needed by

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

Greetings, * Joe Conway (m...@joeconway.com) wrote: > On 6/16/19 9:45 AM, Bruce Momjian wrote: > > On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote: > >> In any case it doesn't address my first point, which is limiting the > >> volume encrypted with the same key. Another valid reason is

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

On Sun, Jun 16, 2019 at 7:43 PM Stephen Frost wrote: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Stephen Frost writes: > > > > what we should do is clean them up (and possibly > > > throw a WARNING or similar at the user saying "something modified your > > > postgresql.auto.conf in an

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

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > Unless there's actually a use-case for duplicate entries in > > postgresql.auto.conf, > > There isn't --- guc.c will just discard the earlier duplicates. One might be able to argue for trying to create a stack or

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

Stephen Frost writes: > Unless there's actually a use-case for duplicate entries in > postgresql.auto.conf, There isn't --- guc.c will just discard the earlier duplicates. > what we should do is clean them up (and possibly > throw a WARNING or similar at the user saying "something modified your

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

Greetings, * Amit Kapila (amit.kapil...@gmail.com) wrote: > On Fri, Jun 14, 2019 at 9:38 PM Stephen Frost wrote: > > * Ian Barwick (ian.barw...@2ndquadrant.com) wrote: > > > > > > Note this issue is not specific to pg_basebackup, primary_conninfo (or > > > any other settings > > > formerly in

$host_cpu -> $target_cpu in configure?

There are a few places in configure and the makefiles that are looking at $host_cpu to decide what to do. As far as I can tell, almost all of them are wrong and should be looking at $target_cpu instead. (The lack of complaints indicates that nobody is trying very hard to test cross-compilation.)

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

On 6/16/19 9:46 AM, Bruce Momjian wrote: > On Sun, Jun 16, 2019 at 09:45:09AM -0400, Bruce Momjian wrote: >> On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote: >> > And although I'm not proposing this for the first implementation, yet >> > another reason is I might want to additionally

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

On 6/16/19 9:45 AM, Bruce Momjian wrote: > On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote: >> In any case it doesn't address my first point, which is limiting the >> volume encrypted with the same key. Another valid reason is you might >> have data at varying sensitivity levels and

Re: Extracting only the columns needed for a query

> > The thing that most approaches to this have fallen down on is triggers --- > that is, a trigger function might access columns mentioned nowhere in the > SQL text. (See 8b6da83d1 for a recent example :-() If you have a plan > for dealing with that, then ... > Well, if we had a trigger

Re: Index Skip Scan

> On Fri, Jun 14, 2019 at 9:20 AM David Rowley > wrote: > > The code in create_distinct_paths() I think should work a different > way. I think it would be much better to add a new field to Path and > allow a path to know what keys it is distinct for. This sort of goes > back to an idea I

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

On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote: > On 6/15/19 9:28 PM, Bruce Momjian wrote: > >> There are reasons other than performance to want more granular than > >> entire cluster encryption. Limiting the volume of encrypted data with > >> any one key for example. And not

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

On Sun, Jun 16, 2019 at 09:45:09AM -0400, Bruce Momjian wrote: > On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote: > > And although I'm not proposing this for the first implementation, yet > > another reason is I might want to additionally control "transparent > > access" to data based

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

On 6/15/19 9:28 PM, Bruce Momjian wrote: > On Fri, Jun 14, 2019 at 02:27:17PM -0400, Joe Conway wrote: >> On 6/13/19 11:07 AM, Bruce Momjian wrote: >> > On Thu, Jun 13, 2019 at 04:26:47PM +0900, Masahiko Sawada wrote: >> >> Yeah, in principle since data key of 2 tier key architecture should >> >>

Re: Performance issue in foreign-key-aware join estimation

On Sat, 25 May 2019 at 16:37, David Rowley wrote: > The only problem I see is that you're not performing a bms_copy() of > the parent's eclass_indexes in add_child_rel_equivalences(). You've > written a comment that claims it's fine to just point to the parent's > in: > > /* > * The child is now