[HACKERS] RemoveSubscriptionRel uses simple_heap_delete

Hi, Currently $subject but should we use CatalogTupleDelete() instead? It's actually the same behavior though. Other functions use CatalogTupleXXX(). Attached patch. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center change_to_use_CatalogTupl

[HACKERS] improve release-note for pg_current_logfile()

Hi, When I am reading the PG 10 release-notes, I found the following item. > Add function pg_current_logfile() to read syslog's current stderr and csvlog > output file names (Gilles Darold) This confused me because "syslog" is one of method for logging as well as stderr and csvlog. I guess it i

Re: [HACKERS] pgrowlocks relkind check

On 2017/06/13 22:53, Peter Eisentraut wrote: > On 6/12/17 21:10, Amit Langote wrote: >> On 2017/06/13 0:29, Peter Eisentraut wrote: >>> On 4/24/17 21:22, Amit Langote wrote: >> create extension pgrowlocks; >> create view one as select 1; >> select pgrowlocks('one'); >> -- ERROR: co

Re: [HACKERS] Dropping partitioned table drops a previously detached partition

On Wed, Jun 14, 2017 at 10:21 AM, Ashutosh Bapat wrote: > On Tue, Jun 13, 2017 at 7:14 PM, Rahila Syed wrote: >> I reviewed and tested >> 0001-Dependency-between-partitioned-table-and-partition_v1.patch >> It applies cleanly on master and make check passes. >> >> Following are few comments: >> >>

Re: [HACKERS] Dropping partitioned table drops a previously detached partition

On Tue, Jun 13, 2017 at 9:23 PM, Robert Haas wrote: > On Tue, Jun 13, 2017 at 9:44 AM, Rahila Syed wrote: >> I have added tests to the >> 0001-Dependency-between-partitioned-table-and-partition_v1.patch. Please >> find attached the v2 patch. > > Thanks. Committed. Thanks. > I don't think the 0

[HACKERS] type of release note of PG10

Hi, I found a typo in the PG10 release note and attached is a patch to fix it. Regards, -- Yugo Nagata diff --git a/doc/src/sgml/release-10.sgml b/doc/src/sgml/release-10.sgml index b10086bd..f3e4a70 100644 --- a/doc/src/sgml/release-10.sgml +++ b/doc/src/sgml/release-10.sgml @@ -525,7 +525,7

Re: [HACKERS] Dropping partitioned table drops a previously detached partition

On Tue, Jun 13, 2017 at 7:14 PM, Rahila Syed wrote: > I reviewed and tested > 0001-Dependency-between-partitioned-table-and-partition_v1.patch > It applies cleanly on master and make check passes. > > Following are few comments: > >>/* >> * Drop the dependency created by StoreCatalogInheritance1 (

Re: [HACKERS] v10beta pg_catalog diagrams

2017-06-14 5:53 GMT+02:00 Peter Eisentraut : > On 6/13/17 17:08, Andres Freund wrote: > > I wondered before if we shouldn't introduce "information only" > > unenforced foreign key constraints for the catalogs. We kind of > > manually do that via oidjoins, it'd be nicer if we'd a function > > rech

Re: [HACKERS] pg_receivewal and messages printed in non-verbose mode

On Tue, Jun 13, 2017 at 4:50 PM, Craig Ringer wrote: > On 13 June 2017 at 14:33, Michael Paquier wrote: >> Those come from stop_streaming in pg_receivewal.c. Shouldn't those >> messages only show up to the user if --verbose is used? It seems >> strange to me that at least the first one is written

Re: [HACKERS] outfuncs.c utility statement support

On 2017/06/14 12:49, Peter Eisentraut wrote: > On 6/13/17 11:25, Peter Eisentraut wrote: >> Running with --debug-print-parse=on, executing >> >> create table test1 (a int, b text); >> >> gives output that is truncated somewhere in the middle (possibly a null >> byte) > > So this seems to be a pret

Re: [HACKERS] v10beta pg_catalog diagrams

On 6/13/17 17:08, Andres Freund wrote: > I wondered before if we shouldn't introduce "information only" > unenforced foreign key constraints for the catalogs. We kind of > manually do that via oidjoins, it'd be nicer if we'd a function > rechecking fkeys, and the fkeys were in the catalog... I do

Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition()

On 2017/06/14 5:36, Robert Haas wrote: > On Tue, Jun 13, 2017 at 10:24 AM, Robert Haas wrote: >> I think that's going to come as an unpleasant surprise to more than >> one user. I'm not sure exactly how we need to restructure things here >> so that this works properly, and maybe modifying >> pred

Re: [HACKERS] outfuncs.c utility statement support

On 6/13/17 11:25, Peter Eisentraut wrote: > Running with --debug-print-parse=on, executing > > create table test1 (a int, b text); > > gives output that is truncated somewhere in the middle (possibly a null > byte) So this seems to be a pretty basic bug. Some node fields of type char may be zer

Re: [HACKERS] Detection of IPC::Run presence in SSL TAP tests

On Tue, Jun 13, 2017 at 11:14 PM, Tom Lane wrote: > Certainly, it's pointless to have a defense only here. And I know very > well that make check falls over in an ugly, hard-to-interpret-if-you've- > not-seen-it-before fashion if you do --enable-tap-tests and don't have > IPC::Run installed. > >

Re: [HACKERS] ICU support on Windows

On Tue, Jun 13, 2017 at 6:45 PM, Peter Eisentraut wrote: > On 6/12/17 14:03, Ashutosh Sharma wrote: >>> I noticed that this only works if you use the "Win32" download of ICU, >>> because the "Win64" download uses "lib64" paths. I'm not sure what the >>> impact of this is in practice. >> >> Yes, t

Re: [HACKERS] Document bug regarding read only transactions

> Your modification does not look completely correct to me either. > Temporary sequences can be updated in read-only transactions. Not sure. Temporary sequences are meaningless on standby because "create temporary sequence" command cannot be executed on standby anyway (and temporary sequence are n

Re: [HACKERS] Document bug regarding read only transactions

On Wed, Jun 14, 2017 at 11:08 AM, Tatsuo Ishii wrote: > > In normal operation, read-only transactions are allowed to > -update sequences and to use LISTEN, UNLISTEN, and > +use LISTEN, UNLISTEN, and > NOTIFY, so Hot Standby sessions operate under slightly > tighter > r

Re: [HACKERS] ICU support on Windows

On 13 June 2017 at 05:47, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Tue, Jun 13, 2017 at 3:13 AM, Alvaro Herrera >> wrote: >> > Ashutosh Sharma wrote: > >> >> Yes, that's right, Win64 download uses lib64 path and in my case i had >> >> renamed lib64-> lib and bin64-> bin which i guess

Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition()

On 2017/06/13 23:24, Robert Haas wrote: > On Mon, Jun 12, 2017 at 4:09 AM, Amit Langote > wrote: >> On 2017/06/09 20:49, Ashutosh Bapat wrote: >>> May be we should pass a flag to predicate_implied_by() to handle NULL >>> behaviour for CHECK constraints. Partitioning has shown that it needs >>> to

[HACKERS] Document bug regarding read only transactions

In https://www.postgresql.org/docs/10/static/hot-standby.html#hot-standby-users It is explained that read only transactions (not in standby) allow to update sequences. In normal operation, read-only transactions are allowed to update sequences and to use LISTEN, UNLISTEN, and NOTIFY,

Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition()

On Tue, Jun 13, 2017 at 5:28 PM, Tom Lane wrote: > Robert Haas writes: >> OK, I think I see the problem here. predicate_implied_by() and >> predicate_refuted_by() differ in what they assume about the predicate >> evaluating to NULL, but both of them assume that if the clause >> evaluates to NULL

Re: [HACKERS] PG10 Partitioned tables and relation_is_updatable()

Hi Dean, On 2017/06/14 2:29, Dean Rasheed wrote: > On 13 June 2017 at 05:50, Ashutosh Bapat > wrote: >> On Tue, Jun 13, 2017 at 12:03 AM, Dean Rasheed >> wrote: >>> Barring objections, I'll push my original patch and work up patches >>> for the other couple of issues I found. >> >> No objection

Re: [HACKERS] WIP: Data at rest encryption

Bruce, * Bruce Momjian (br...@momjian.us) wrote: > On Tue, Jun 13, 2017 at 03:20:12PM -0400, Stephen Frost wrote: > > > OK, so let's go back. You are saying there are no security benefits to > > > this vs. file system encryption. > > > > I'm not sure that I can see any, myself.. Perhaps I'm wro

Re: [HACKERS] WIP: Data at rest encryption

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 6/13/17 15:20, Stephen Frost wrote: > > And then you would need openssl on the other system to decrypt it. > > Or make the USB file system encrypted as well? If you're in that kind > of environment, that would surely be fea

Re: [HACKERS] WIP: Data at rest encryption

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 6/13/17 15:20, Stephen Frost wrote: > > No, the benefit is that the database administrator can configure it and > > set it up and not have to get an OS-level administrator involved. There > > may also be other reasons why fi

Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition()

Robert Haas writes: > OK, I think I see the problem here. predicate_implied_by() and > predicate_refuted_by() differ in what they assume about the predicate > evaluating to NULL, but both of them assume that if the clause > evaluates to NULL, that's equivalent to false. So there's actually no >

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

Piotr Stefaniak writes: > On 2017-06-13 22:23, Tom Lane wrote: >> I could not find any places where reverting this change made the >> results worse, so I'm unclear on why you made it. > I must admit I'm a bit confused about why it's not fixed yet, but I'll > have to analyze that later this week.

Re: [HACKERS] fix possible optimizations in ATExecAttachPartition()

On Wed, Jun 14, 2017 at 2:12 AM, Robert Haas wrote: > On Tue, Jun 13, 2017 at 5:22 AM, Amit Langote > wrote: > > Yeah, I was thinking the same while writing the patch posted on the > thread > > "A bug in mapping attributes in ATExecAttachPartition()" [1]. That patch > > adds the break you menti

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

On 2017-06-13 22:23, Tom Lane wrote: > I could not find any places where reverting this change made the > results worse, so I'm unclear on why you made it. I must admit I'm a bit confused about why it's not fixed yet, but I'll have to analyze that later this week. But the idea was to convince inde

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

On Tue, Jun 13, 2017 at 05:00:31PM -0400, Tom Lane wrote: > Anyway, it is now time to fish or cut bait. I don't think we can wait > much longer to decide whether we're going to adopt this new indent > version for PG 10. I think we should. The floor is open for votes. Works for me. -- Bruce

Re: [HACKERS] v10beta pg_catalog diagrams

Hi, On 2017-06-12 11:28:39 -0400, Neil Anderson wrote: > I'm cross posting from general. I did some work to diagram the relationships > in pg_catalog for v10. I would like to add it to the developer FAQ here > https://wiki.postgresql.org/wiki/Developer_FAQ#Is_there_a_diagram_of_the_system_catalog

Re: [HACKERS] RTE_NAMEDTUPLESTORE, enrtuples and comments

On Wed, Jun 14, 2017 at 4:22 AM, Robert Haas wrote: > I'm just trying to understand your comments so that I can have an > intelligent opinion about what we should do from here. Given that the > replan wouldn't happen anyway, there seems to be no reason to tinker > with the location of enrtuples f

Re: [HACKERS] WIP: Data at rest encryption

On Tue, Jun 13, 2017 at 10:28:14AM -0400, Peter Eisentraut wrote: > On 6/13/17 09:24, Stephen Frost wrote: > > but there are use-cases where it'd be really nice to be able to > > have PG doing the encryption instead of the filesystem because > > then you can do things like backup the database, copy

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

On 2017-06-13 18:22, Tom Lane wrote: > The Makefile is still BSD-ish of course, but I think > we'll just agree to disagree there. For compiling indent under Linux I use bmake(1). I have no problem with including a Makefile for GNU Make in my repository. As I understand it, there will be a copy of

Re: [HACKERS] fix possible optimizations in ATExecAttachPartition()

On Tue, Jun 13, 2017 at 5:22 AM, Amit Langote wrote: > Yeah, I was thinking the same while writing the patch posted on the thread > "A bug in mapping attributes in ATExecAttachPartition()" [1]. That patch > adds the break you mention in 2, but didn't do anything about point 1. > > In any case, +1

Re: [HACKERS] v10beta pg_catalog diagrams

On Tue, Jun 13, 2017 at 3:14 PM, Neil Anderson wrote: > There were a few relationships that I couldn't capture. Like where in > pg_extension extconfig is an array of oids that refer to pg_class or where > pg_depends could refer to basically any other system catalog, but it's > mostly there and has

Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition()

On Tue, Jun 13, 2017 at 10:24 AM, Robert Haas wrote: > I think that's going to come as an unpleasant surprise to more than > one user. I'm not sure exactly how we need to restructure things here > so that this works properly, and maybe modifying > predicate_implied_by() isn't the right thing at a

Re: [HACKERS] GSoC 2017 weekly progress reports (week 2)

On Tue, Jun 13, 2017 at 1:02 PM, Andrew Borodin wrote: > 2017-06-13 18:00 GMT+05:00 Shubham Barai : > Good job! +1! :-) > So, in current HEAD test predicate_gist_2.spec generate false > positives, but with your patch, it does not? Keep in mind, that false positives do not break *correctness*

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

I've now done a round of comparisons of results of our old indent with your current version. There's still one serious bug in the latter: it continues to misformat enum typedefs, for instance *** PG_FUNCTION_INFO_V1(pg_prewarm); *** 33,40 typedef enum { PREWARM_PREFET

Re: [HACKERS] WIP: Data at rest encryption

On Tue, Jun 13, 2017 at 04:08:29PM -0400, Peter Eisentraut wrote: > On 6/13/17 15:51, Bruce Momjian wrote: > > Isn't the leakage controlled by OS permissions, so is it really leakage, > > i.e., if you can see the leakage, you probably have bypassed the OS > > permissions and see the key and data an

Re: [HACKERS] WIP: Data at rest encryption

On 6/13/17 15:51, Bruce Momjian wrote: > Isn't the leakage controlled by OS permissions, so is it really leakage, > i.e., if you can see the leakage, you probably have bypassed the OS > permissions and see the key and data anyway. One scenario (among many) is when you're done with the disk. If th

Re: [HACKERS] WIP: Data at rest encryption

On Tue, Jun 13, 2017 at 03:20:12PM -0400, Stephen Frost wrote: > Bruce, > > * Bruce Momjian (br...@momjian.us) wrote: > > On Tue, Jun 13, 2017 at 02:38:58PM -0400, Stephen Frost wrote: > > > It's good to discuss what the feature would bring and what cases it > > > doesn't cover, as well as discuss

Re: [HACKERS] Get stuck when dropping a subscription during synchronizing table

On 6/13/17 02:33, Noah Misch wrote: >> Steps to reproduce - >> X cluster -> create 100 tables , publish all tables (create publication pub >> for all tables); >> Y Cluster -> create 100 tables ,create subscription(create subscription sub >> connection 'user=centos host=localhost' publication pub;

Re: [HACKERS] WIP: Data at rest encryption

On 6/13/17 15:20, Stephen Frost wrote: > For example, you could simply do: > > cp -a /path/to/PG /mnt/usb > > and you're done. If you're using filesystem level encryption then you'd > have to re-encrypt the data, using something like: > > tar -cf - /path/to/PG | openssl -key private.key > > /

Re: [HACKERS] WIP: Data at rest encryption

On 6/13/17 15:20, Stephen Frost wrote: > No, the benefit is that the database administrator can configure it and > set it up and not have to get an OS-level administrator involved. There > may also be other reasons why filesystem-level encryption is difficult > to set up or use in a certain enviro

Re: [HACKERS] Broken hint bits (freeze)

On Mon, Jun 12, 2017 at 06:31:11PM +0300, Vladimir Borodin wrote: > What about the following sequence? > > 1. Run pg_upgrade on master, > 2. Start it in single-user mode and stop (to get right wal_level in > pg_control), > 3. Copy pg_control somewhere, > 4. Start master, run analyze and stop. > 5.

Re: [HACKERS] WIP: Data at rest encryption

Bruce, * Bruce Momjian (br...@momjian.us) wrote: > On Tue, Jun 13, 2017 at 02:38:58PM -0400, Stephen Frost wrote: > > It's good to discuss what the feature would bring and what cases it > > doesn't cover, as well as discussing how it can be designed to make sure > > that later improvements are abl

Re: [HACKERS] v10beta pg_catalog diagrams

On 2017-06-13 1:22 PM, Bruce Momjian wrote: On Mon, Jun 12, 2017 at 04:07:35PM -0400, Peter Eisentraut wrote: On 6/12/17 11:28, Neil Anderson wrote: I'm cross posting from general. I did some work to diagram the relationships in pg_catalog for v10. I would like to add it to the developer FAQ he

Re: [HACKERS] WIP: Data at rest encryption

On Tue, Jun 13, 2017 at 02:38:58PM -0400, Stephen Frost wrote: > It's good to discuss what the feature would bring and what cases it > doesn't cover, as well as discussing how it can be designed to make sure > that later improvements are able to be done without having to change it > around. I do t

Re: [HACKERS] WIP: Data at rest encryption

Bruce, * Bruce Momjian (br...@momjian.us) wrote: > On Tue, Jun 13, 2017 at 02:23:39PM -0400, Stephen Frost wrote: > > I'm not trying to shut down discussion, I'm simply pointing out where > > this feature will be helpful and where it won't be. If there's a way to > > make it better and able to ad

Re: [HACKERS] WIP: Data at rest encryption

On Tue, Jun 13, 2017 at 02:23:39PM -0400, Stephen Frost wrote: > I'm not trying to shut down discussion, I'm simply pointing out where > this feature will be helpful and where it won't be. If there's a way to > make it better and able to address an attack where the OS permission > system is bypass

Re: [HACKERS] WIP: Data at rest encryption

Bruce, * Bruce Momjian (br...@momjian.us) wrote: > On Tue, Jun 13, 2017 at 01:25:00PM -0400, Stephen Frost wrote: > > > I think the big win of Postgres doing the encryption is that the > > > user-visible file system is no longer a target (assuming OS permissions > > > are bypassed), while for file

Re: [HACKERS] WIP: Data at rest encryption

Bruce, * Bruce Momjian (br...@momjian.us) wrote: > On Tue, Jun 13, 2017 at 01:44:51PM -0400, Stephen Frost wrote: > > Just to be clear, I don't have any issue with discussing the idea that > > we want to get to a point where we can work with multiple keys and > > encrypt different tables with diff

Re: [HACKERS] GSoC 2017 weekly progress reports (week 2)

2017-06-13 18:00 GMT+05:00 Shubham Barai : > > Project: Explicitly support predicate locks in index AMs besides b-tree > Hi, Shubham Good job! So, in current HEAD test predicate_gist_2.spec generate false positives, but with your patch, it does not? I'd suggest keeping spec tests with your code in

Re: [HACKERS] WIP: Data at rest encryption

On Tue, Jun 13, 2017 at 01:44:51PM -0400, Stephen Frost wrote: > Just to be clear, I don't have any issue with discussing the idea that > we want to get to a point where we can work with multiple keys and > encrypt different tables with different keys (or not encrypt certain > tables, et al) with t

Re: [HACKERS] WIP: Data at rest encryption

Joe, * Joe Conway (m...@joeconway.com) wrote: > On 06/13/2017 10:20 AM, Stephen Frost wrote: > > * Joe Conway (m...@joeconway.com) wrote: > >> Except shell escaping issues, etc, etc > > > > That's not an issue- we're talking about reading the stdout of some > > other process, there's no shell esc

Re: [HACKERS] WIP: Data at rest encryption

On Tue, Jun 13, 2017 at 01:25:00PM -0400, Stephen Frost wrote: > > I think the big win of Postgres doing the encryption is that the > > user-visible file system is no longer a target (assuming OS permissions > > are bypassed), while for file system encryption it is the storage device > > that is en

Re: [HACKERS] PG10 Partitioned tables and relation_is_updatable()

On 13 June 2017 at 05:50, Ashutosh Bapat wrote: > On Tue, Jun 13, 2017 at 12:03 AM, Dean Rasheed > wrote: >> Barring objections, I'll push my original patch and work up patches >> for the other couple of issues I found. > > No objections, the patch is good to go as is. Sorry for high-jacking > t

Re: [HACKERS] WIP: Data at rest encryption

On 06/13/2017 10:20 AM, Stephen Frost wrote: > * Joe Conway (m...@joeconway.com) wrote: >> Except shell escaping issues, etc, etc > > That's not an issue- we're talking about reading the stdout of some > other process, there's no shell escaping that has to be done there. It could be an issue depe

Re: [HACKERS] WIP: Data at rest encryption

Bruce, * Bruce Momjian (br...@momjian.us) wrote: > On Tue, Jun 13, 2017 at 01:01:32PM -0400, Stephen Frost wrote: > > > Well, usually the symetric key is stored using RSA and a symetric > > > cipher is used to encrypt/decrypt the data. I was thinking of a case > > > where you encrypt a row using

Re: [HACKERS] v10beta pg_catalog diagrams

On Mon, Jun 12, 2017 at 04:07:35PM -0400, Peter Eisentraut wrote: > On 6/12/17 11:28, Neil Anderson wrote: > > I'm cross posting from general. I did some work to diagram the > > relationships in pg_catalog for v10. I would like to add it to the > > developer FAQ here > > https://wiki.postgresql.

Re: [HACKERS] Why are we restricting exported snapshots in subtransactions?

On 2017-06-13 13:15:57 -0400, Robert Haas wrote: > On Mon, Jun 12, 2017 at 11:04 PM, Andres Freund wrote: > > ExportSnapshot() has, right at the beginning, the following block: > > > > /* > > * We cannot export a snapshot from a subtransaction because there's no > > * easy way for im

Re: [HACKERS] WIP: Data at rest encryption

Joe, * Joe Conway (m...@joeconway.com) wrote: > Except shell escaping issues, etc, etc That's not an issue- we're talking about reading the stdout of some other process, there's no shell escaping that has to be done there. > > Let us, please, stop stressing over the right way to do key managemen

[HACKERS] Announcing Release 5 of the PostgreSQL Buildfarm Client

Release 5 of the PostgreSQL Buildfarm Client has been released and can be downloaded from In a similar move to PostgreSQL version numbering, with this release we move to a one part numbering system. In addition to a number

Re: [HACKERS] Why are we restricting exported snapshots in subtransactions?

On Mon, Jun 12, 2017 at 11:04 PM, Andres Freund wrote: > ExportSnapshot() has, right at the beginning, the following block: > > /* > * We cannot export a snapshot from a subtransaction because there's no > * easy way for importers to verify that the same subtransaction is still >

Re: [HACKERS] WIP: Data at rest encryption

On Tue, Jun 13, 2017 at 01:01:32PM -0400, Stephen Frost wrote: > > Well, usually the symetric key is stored using RSA and a symetric > > cipher is used to encrypt/decrypt the data. I was thinking of a case > > where you encrypt a row using a symetric key, then store RSA-encrypted > > versions of t

Re: [HACKERS] WIP: Data at rest encryption

On 06/13/2017 10:05 AM, Stephen Frost wrote: > Bruce, Joe, > > * Bruce Momjian (br...@momjian.us) wrote: >> On Tue, Jun 13, 2017 at 09:55:10AM -0700, Joe Conway wrote: >> > > That way, if the user wants to store the key in an unencrypted text >> > > file, they can set the encryption_key_command =

Re: [HACKERS] Transactional sequence stuff breaks pg_upgrade

On Tue, Jun 13, 2017 at 11:14:02AM -0400, Robert Haas wrote: > Also, I think that if we did it that way, it would be significantly > harder to debug. Right now, if something goes boom, you can look at > the old and new clusters and figure out what doesn't match, but if > pg_upgrade renumbered ever

Re: [HACKERS] WIP: Data at rest encryption

Bruce, Joe, * Bruce Momjian (br...@momjian.us) wrote: > On Tue, Jun 13, 2017 at 09:55:10AM -0700, Joe Conway wrote: > > > That way, if the user wants to store the key in an unencrypted text > > > file, they can set the encryption_key_command = 'cat /not/very/secure' > > > and call it a day. If th

Re: [HACKERS] WIP: Data at rest encryption

Bruce, * Bruce Momjian (br...@momjian.us) wrote: > On Tue, Jun 13, 2017 at 12:23:01PM -0400, Stephen Frost wrote: > > > Of course, if the > > > key stored in the database is visible to someone using the operating > > > system, we really haven't added much/any security --- I guess my point > > > is

Re: [HACKERS] WIP: Data at rest encryption

On Tue, Jun 13, 2017 at 09:55:10AM -0700, Joe Conway wrote: > > That way, if the user wants to store the key in an unencrypted text > > file, they can set the encryption_key_command = 'cat /not/very/secure' > > and call it a day. If they want to prompt the user on the console or > > request the ke

Re: [HACKERS] WIP: Data at rest encryption

On 06/13/2017 09:28 AM, Robert Haas wrote: > On Tue, Jun 13, 2017 at 12:23 PM, Stephen Frost wrote: >> Key management is an entirely independent discussion from this and the >> proposal from Ants, as I understand it, is that the key would *not* be >> in the database but could be anywhere that a sh

Re: [HACKERS] WIP: Data at rest encryption

On Tue, Jun 13, 2017 at 12:23:01PM -0400, Stephen Frost wrote: > > As I understand it, having encryption in the database means the key is > > stored in the database, while having encryption in the file system means > > the key is stored in the operating system somewhere. > > Key management is an

Re: [HACKERS] remove unnecessary flag has_null from PartitionBoundInfoData

On Mon, Jun 12, 2017 at 9:03 AM, Ashutosh Bapat wrote: > On Mon, Jun 12, 2017 at 3:50 PM, amul sul wrote: >> On Wed, May 17, 2017 at 10:22 PM, Robert Haas wrote: >> [...] >>> I committed this with fixes for those issues, plus I renamed the macro >>> to partition_bound_accepts_nulls, which I thin

Re: [HACKERS] Refreshing subscription relation state inside a transaction block

On Wed, Jun 14, 2017 at 1:02 AM, Masahiko Sawada wrote: > On Tue, Jun 13, 2017 at 4:53 PM, Petr Jelinek > wrote: >> On 13/06/17 09:06, Masahiko Sawada wrote: >>> Hi, >>> >>> The commit ddd7b22b225ae41d16ceb218b387645cb9becfdc makes table sync >>> workers stop when subscription relation entry is r

Re: [HACKERS] WIP: Data at rest encryption

On Tue, Jun 13, 2017 at 12:23 PM, Stephen Frost wrote: > Key management is an entirely independent discussion from this and the > proposal from Ants, as I understand it, is that the key would *not* be > in the database but could be anywhere that a shell command could get it > from, including possi

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

Piotr Stefaniak writes: >> There's also the portability issues: __FBSDID() and bcopy() and >> [and err.h]. > I think that's fixed as well. I just finished some preliminary portability testing and things look much improved. The Makefile is still BSD-ish of course, but I think we'll just agree t

Re: [HACKERS] WIP: Data at rest encryption

Bruce, * Bruce Momjian (br...@momjian.us) wrote: > On Tue, Jun 13, 2017 at 11:04:21AM -0400, Stephen Frost wrote: > > > Also, in the use case you describe, if you use pg_basebackup to make a > > > direct encrypted copy of a data directory, I think that would mean you'd > > > have to keep using the

Re: [HACKERS] RTE_NAMEDTUPLESTORE, enrtuples and comments

On Tue, Jun 13, 2017 at 12:04 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Jun 13, 2017 at 11:53 AM, Tom Lane wrote: >>> But it needs to be changeable, unless you like the proposition that we >>> can never replan a query inside a trigger on the basis of new information >>> about how big

Re: [HACKERS] memory fields from getrusage()

On Sat, Jun 10, 2017 at 9:31 PM, Tom Lane wrote: > We already do call getrusage(). The point of that comment is that the > contents of the resulting struct rusage are not very well standardized. > POSIX says only > > The header defines the rusage structure that includes > at least the fo

Re: [HACKERS] Typo in BRIN documentation

On Tue, Jun 13, 2017 at 11:29:30AM -0400, Peter Eisentraut wrote: > On 6/13/17 07:53, Julien Rouhaud wrote: > > I just found this typo while doing french translation, patch attached. > > fixed > Thanks ! -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers mailing

Re: [HACKERS] RTE_NAMEDTUPLESTORE, enrtuples and comments

Robert Haas writes: > On Tue, Jun 13, 2017 at 11:53 AM, Tom Lane wrote: >> But it needs to be changeable, unless you like the proposition that we >> can never replan a query inside a trigger on the basis of new information >> about how big the transition table is. Even if you're okay with that >

Re: [HACKERS] WIP: Data at rest encryption

On Tue, Jun 13, 2017 at 11:04:21AM -0400, Stephen Frost wrote: > > Also, in the use case you describe, if you use pg_basebackup to make a > > direct encrypted copy of a data directory, I think that would mean you'd > > have to keep using the same key for all copies. > > That's true, but that might

Re: [HACKERS] Refreshing subscription relation state inside a transaction block

On Tue, Jun 13, 2017 at 4:53 PM, Petr Jelinek wrote: > On 13/06/17 09:06, Masahiko Sawada wrote: >> Hi, >> >> The commit ddd7b22b225ae41d16ceb218b387645cb9becfdc makes table sync >> workers stop when subscription relation entry is removed. It doesn't >> work fine inside transaction block. I think

Re: [HACKERS] RTE_NAMEDTUPLESTORE, enrtuples and comments

On Tue, Jun 13, 2017 at 11:53 AM, Tom Lane wrote: >> How does it break those properties? I don't think enrtuples is being >> modified by planning or execution as things stand. > > But it needs to be changeable, unless you like the proposition that we > can never replan a query inside a trigger on

Re: [HACKERS] Dropping partitioned table drops a previously detached partition

On Tue, Jun 13, 2017 at 9:44 AM, Rahila Syed wrote: > I have added tests to the > 0001-Dependency-between-partitioned-table-and-partition_v1.patch. Please > find attached the v2 patch. Thanks. Committed. I don't think the 0002 patch is an improvement - sure, it keeps those things in sync, but i

Re: [HACKERS] RTE_NAMEDTUPLESTORE, enrtuples and comments

Robert Haas writes: > On Tue, Jun 13, 2017 at 10:05 AM, Tom Lane wrote: >> Well, the fundamental problem is that the RTE is a lousy place to keep >> rowcount estimates. That breaks assorted desirable properties like >> querytrees being readonly to planning/execution (not that we don't >> end up

Re: [HACKERS] WIP: Data at rest encryption

On Tue, Jun 13, 2017 at 11:35:03AM -0400, Robert Haas wrote: > I anticipate that one of the trickier problems here will be handling > encryption of the write-ahead log. Suppose you encrypt WAL a block at > a time. In the current system, once you've written and flushed a > block, you can consider

Re: [HACKERS] RTE_NAMEDTUPLESTORE, enrtuples and comments

On Tue, Jun 13, 2017 at 10:05 AM, Tom Lane wrote: > Robert Haas writes: >> Perhaps this is a silly question, but I don't particularly see what's >> wrong with: > >> 3. Do nothing. > > Well, the fundamental problem is that the RTE is a lousy place to keep > rowcount estimates. That breaks assorte

Re: [HACKERS] outfuncs.c utility statement support

Peter Eisentraut writes: > While debugging some other stuff, I was wondering to what extent node > types supporting utility statements should be supported in outfuncs.c. We've largely not tried too hard in that department. From a debugging standpoint it'd be useful to have more complete coverage

Re: [HACKERS] WIP: Data at rest encryption

On Mon, Jun 12, 2017 at 5:11 PM, Ants Aasma wrote: > Fundamentally there doesn't seem to be a big benefit of implementing > the encryption at PostgreSQL level instead of the filesystem. The > patch doesn't take any real advantage from the higher level knowledge > of the system, nor do I see much p

Re: [HACKERS] Typo in BRIN documentation

On 6/13/17 07:53, Julien Rouhaud wrote: > I just found this typo while doing french translation, patch attached. fixed -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgs

Re: [HACKERS] macOS Sierra & System Integrity Protection

On 13 June 2017 at 04:25, Robert Haas wrote: > I have a new MacBook Pro running Sierra. Congratulations. > 'make check' was failing: 'psql' repeatedly died with an abort > trap. Binaries worked fine when I ran them from the command line > (sometimes with DYLD_LIBRARY_PATH, if needed) but when

[HACKERS] outfuncs.c utility statement support

While debugging some other stuff, I was wondering to what extent node types supporting utility statements should be supported in outfuncs.c. Running with --debug-print-parse=on, executing create table test1 (a int, b text); gives output that is truncated somewhere in the middle (possibly a null b

Re: [HACKERS] macOS Sierra & System Integrity Protection

Simon Riggs writes: > On 13 June 2017 at 04:25, Robert Haas wrote: >> 'make check' was failing: 'psql' repeatedly died with an abort >> trap. Binaries worked fine when I ran them from the command line >> (sometimes with DYLD_LIBRARY_PATH, if needed) but when run via >> pg_regress, nothing worked

Re: [HACKERS] Transactional sequence stuff breaks pg_upgrade

On Tue, Jun 13, 2017 at 9:37 AM, Tom Lane wrote: > In the long run, it would certainly be cleaner if pg_upgrade dropped > the force-the-relfilenode-assignment approach and instead remapped > relfilenodes from old cluster to new. But I think it's just for > cleanliness rather to fix any live or fo

Re: [HACKERS] macOS Sierra & System Integrity Protection

On 6/12/17 23:38, Tom Lane wrote: > https://www.postgresql.org/message-id/26098.1446697...@sss.pgh.pa.us > >> My main purpose in writing this email is to pass along what I learned >> in the hopes of sparing somebody else some trouble, but perhaps there >> is a way to modify our regression test set

Re: [HACKERS] WIP: Data at rest encryption

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > I wonder what the proper extent of "encryption at rest" should be. If > you encrypt just on a file or block level, then someone looking at the > data directory or a backup can still learn a number of things about the > number o

Re: [HACKERS] Fix a typo in shm_mq.c

On 6/12/17 21:32, Masahiko Sawada wrote: > Attached the patch for $subject. > > s/Whem/When/ committed -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@post

Re: [HACKERS] tablesync.c - comment improvements

On 6/10/17 04:52, Erik Rijkers wrote: > tablesync.c - comment improvements Committed, thanks! -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

  1   2   >