Re: List of all* PostgreSQL EXTENSIONs in the world

On 2/23/22 09:33, Euler Taveira wrote: On Wed, Feb 23, 2022, at 6:00 AM, Joel Jacobson wrote: On Fri, Feb 11, 2022, at 04:46, Noah Misch wrote: > How did you make the list?  (I'd imagine doing it by searching for > repositories containing evidence like \bpgxs\b matches.) Searching Github for re

Re: List of all* PostgreSQL EXTENSIONs in the world

On 2/23/22 09:52, Aleksander Alekseev wrote: > What about scanning for "PG_MODULE_MAGIC"? An extension can be written without using C at all. BTW some extensions [1] are written in Rust these days. Sure, but scanning for PG_MODULE_MAGIC may well pick up repos that would otherwise have been

Re: [PATCH v2] use has_privs_for_role for predefined roles

On 3/3/22 11:26, Joshua Brindle wrote: On Thu, Feb 10, 2022 at 2:37 PM Joe Conway wrote: On 2/10/22 14:28, Nathan Bossart wrote: > On Wed, Feb 09, 2022 at 04:39:11PM -0500, Joe Conway wrote: >> On 2/9/22 13:13, Nathan Bossart wrote: >>> I do wonder if users find the d

Re: [PATCH v2] use has_privs_for_role for predefined roles

On 3/20/22 12:31, Joshua Brindle wrote: On Sun, Mar 20, 2022 at 12:27 PM Joe Conway wrote: On 3/3/22 11:26, Joshua Brindle wrote: > On Thu, Feb 10, 2022 at 2:37 PM Joe Conway wrote: >> >> On 2/10/22 14:28, Nathan Bossart wrote: >> > On Wed, Feb 09, 2022 at 04:39:11PM

Re: [PATCH v2] use has_privs_for_role for predefined roles

On 3/20/22 12:38, Stephen Frost wrote: Greetings, On Sun, Mar 20, 2022 at 18:31 Joshua Brindle mailto:joshua.brin...@crunchydata.com>> wrote: On Sun, Mar 20, 2022 at 12:27 PM Joe Conway mailto:m...@joeconway.com>> wrote: > > On 3/3/22 11:26, Joshua Brindle

Re: documentation fix for SET ROLE

On 2/17/21 2:12 PM, David G. Johnston wrote: > On Wednesday, February 17, 2021, Bossart, Nathan > wrote: > > >     postgres=# ALTER ROLE test1 SET ROLE test2; >     ALTER ROLE > > > I would not have expected this to work - “role” isn’t a > configuration_para

Re: "has_column_privilege()" issue with attnums and non-existent columns

On 3/3/21 8:50 AM, David Steele wrote: > On 1/29/21 4:56 AM, Joe Conway wrote: >> On 1/29/21 12:13 AM, Ian Lawrence Barwick wrote: >>> 2021年1月28日(木) 17:18 Peter Eisentraut: >>> I'm not convinced the current behavior is wrong.  Is there some >>> pr

Re: "has_column_privilege()" issue with attnums and non-existent columns

On 3/3/21 9:43 AM, Joe Conway wrote: > On 3/3/21 8:50 AM, David Steele wrote: >> On 1/29/21 4:56 AM, Joe Conway wrote: >>> On 1/29/21 12:13 AM, Ian Lawrence Barwick wrote: >>>> 2021年1月28日(木) 17:18 Peter Eisentraut: >>>> I'm not convince

Re: "has_column_privilege()" issue with attnums and non-existent columns

On 3/7/21 2:35 PM, Zhihong Yu wrote: > Joe: > I don't seem to find attachment. > > Maybe attach again ? Oops -- I did forget that, didn't I. This time patch is attached :-) Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Sour

Re: [PATCH] pg_permissions

On 3/6/21 2:03 PM, Joel Jacobson wrote: > ...but to answer the question... > >    - What permissions are there for a specific role in the database? > > you need to manually query all relevant pg_catalog or > information_schema.*_privileges views, > which is a O(n) mental effort, while the first q

Re: Procedures versus the "fastpath" API

On 3/9/21 2:15 PM, Tom Lane wrote: > So the question on the table is what to do about this. As far as > window functions go, it seems clear that fastpath.c should just reject > any attempt to call a window function that way (or an aggregate for > that matter; aggregates fail already, but with rela

Re: documentation fix for SET ROLE

On 3/12/21 1:16 PM, Bossart, Nathan wrote: On 3/12/21, 6:35 AM, "Laurenz Albe" wrote: On Fri, 2021-03-12 at 10:16 +0100, I wrote: After sleeping on it, I have come to think that it is excessive to write so much documentation for a feature that is that unimportant. It takes some effort to come

Re: "has_column_privilege()" issue with attnums and non-existent columns

On 3/16/21 1:42 AM, Chengxi Sun wrote: The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:not tested I tested the patch and it wo

Re: Should we document IS [NOT] OF?

On 11/19/20 2:03 AM, Tom Lane wrote: > "David G. Johnston" writes: >> Is there a feature code? I skimmed the standard and non-standard tables in >> our appendix and couldn’t find this in either. > > a19d9d3c4 seems to have thought it was S151. Here is a link to previous list discussions: https:

Re: Should we document IS [NOT] OF?

On 11/19/20 11:06 AM, Tom Lane wrote: > Let's just rip it out and be done. If anyone is ever > motivated to make it work per spec, they can resurrect > whatever seems useful from the git history. +1 Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulti

Re: Should we document IS [NOT] OF?

On 11/19/20 12:08 PM, Tom Lane wrote: > Bruce Momjian writes: >> On Thu, Nov 19, 2020 at 11:15:33AM -0500, Joe Conway wrote: >>> On 11/19/20 11:06 AM, Tom Lane wrote: >>>> Let's just rip it out and be done. If anyone is ever >>>> motivat

Re: "has_column_privilege()" issue with attnums and non-existent columns

On 1/29/21 12:13 AM, Ian Lawrence Barwick wrote: > 2021年1月28日(木) 17:18 Peter Eisentraut: > I'm not convinced the current behavior is wrong.  Is there some > practical use case that is affected by this behavior? > >   > I was poking around at the function with a view to using it for somethi

Re: "has_column_privilege()" issue with attnums and non-existent columns

On 3/16/21 2:45 PM, Joe Conway wrote: Ian, or anyone else, any comments/complaints on my changes? If not I will commit and push that version sooner rather than later. Any thoughts on back-patching this? On one hand, in my view it is clearly a bug. On the other hand, no one has complained

Re: "has_column_privilege()" issue with attnums and non-existent columns

On 3/21/21 12:27 PM, Tom Lane wrote: I think we may have to adjust the acl.c APIs, or maybe better provide new entry points, so that we can have variants of pg_xxx_aclcheck that won't throw a hard error upon not finding the row. We cheesily tried to avoid adjusting those APIs to support the sema

Re: "has_column_privilege()" issue with attnums and non-existent columns

On 3/30/21 3:37 PM, Joe Conway wrote: On 3/21/21 12:27 PM, Tom Lane wrote: I think we may have to adjust the acl.c APIs, or maybe better provide new entry points, so that we can have variants of pg_xxx_aclcheck that won't throw a hard error upon not finding the row. We cheesily tried to

Re: "has_column_privilege()" issue with attnums and non-existent columns

On 3/30/21 6:22 PM, Tom Lane wrote: Joe Conway writes: Heh, I missed the forest for the trees it seems. That version undid the changes fixing what Ian was originally complaining about. Duh, right. It would be a good idea for there to be a code comment explaining this, because it's

Re: "has_column_privilege()" issue with attnums and non-existent columns

On 3/30/21 8:17 PM, Joe Conway wrote: On 3/30/21 6:22 PM, Tom Lane wrote: Joe Conway writes: Heh, I missed the forest for the trees it seems. That version undid the changes fixing what Ian was originally complaining about. Duh, right. It would be a good idea for there to be a code comment

Re: policies with security definer option for allowing inline optimization

On 4/2/21 9:57 AM, Isaac Morland wrote: Views already run security definer, allowing them to be used for some of the same information-hiding purposes as RLS. But I just found something strange: current_user/_role returns the user's role, not the view owner's role: postgres=# set role to t1; S

Re: policies with security definer option for allowing inline optimization

On 4/2/21 10:23 AM, Stephen Frost wrote: Greetings, * Joe Conway (m...@joeconway.com) wrote: On 4/2/21 9:57 AM, Isaac Morland wrote: >Views already run security definer, allowing them to be used for some of >the same information-hiding purposes as RLS. But I just found something &g

Re: documentation fix for SET ROLE

On 4/2/21 10:21 AM, Laurenz Albe wrote: On Mon, 2021-03-15 at 17:09 +, Bossart, Nathan wrote: On 3/15/21, 7:06 AM, "Laurenz Albe" wrote: > On Fri, 2021-03-12 at 21:41 +, Bossart, Nathan wrote: > > On 3/12/21, 11:14 AM, "Joe Conway" wrote: > > >

Re: PL/R regression on windows, but not linux with master.

On 4/11/21 10:13 AM, Tom Lane wrote: Andrew Dunstan writes: Well, plr.h does this: #define WARNING 19 #define ERROR 20 The coding pattern in plr.h looks quite breakable. Meh -- that code has gone 18+ years before breaking. Indeed. elog.h already provides a "PGERROR" m

Re: PL/R regression on windows, but not linux with master.

On 4/11/21 12:51 PM, Dave Cramer wrote: On Sun, 11 Apr 2021 at 12:43, Tom Lane <mailto:t...@sss.pgh.pa.us>> wrote: I wrote: > Joe Conway mailto:m...@joeconway.com>> writes: >> Would an equivalent "PGWARNING" be something we are open t

Re: security_context_t marked as deprecated in libselinux 3.1

On 8/13/20 1:22 AM, Michael Paquier wrote: > On Wed, Aug 12, 2020 at 10:50:21PM -0400, Tom Lane wrote: >> Ummm ... aren't you going to get some cast-away-const warnings now? >> Or are all of the called functions declared as taking "const char *" >> not just "char *"? > > Let me see.. The function

Re: [RFC] speed up count(*)

On 10/20/21 2:33 PM, John Naylor wrote: On Wed, Oct 20, 2021 at 2:23 PM Tomas Vondra mailto:tomas.von...@enterprisedb.com>> wrote: > > Couldn't we simply inspect the visibility map, use the index data only > for fully visible/summarized ranges, and inspect the heap for the > remaining pag

Re: [RFC] speed up count(*)

On 10/21/21 4:06 PM, Robert Haas wrote: On Thu, Oct 21, 2021 at 9:09 AM Joe Conway wrote: I think you are exactly correct. People seem to understand that with a predicate it is harder, but they expect select count(*) from foo; to be nearly instantaneous, and they don't really need it

Re: [RFC] speed up count(*)

On 10/21/21 4:23 PM, Robert Haas wrote: On Thu, Oct 21, 2021 at 4:19 PM Joe Conway wrote: That is a grossly overstated position. When I have looked, it is often not that terribly far off. And for many use cases that I have heard of at least, quite adequate. I don't think it'

Re: add a MAC check for TRUNCATE

On 9/6/19 11:26 AM, Yuli Khodorkovskiy wrote: > On Fri, Sep 6, 2019 at 10:40 AM Stephen Frost wrote: >> There are actual reasons why the 'DELETE' privilege is *not* the same as >> 'TRUNCATE' in PostgreSQL and I'm really not convinced that we should >> just be tossing that distinction out the windo

Re: add a MAC check for TRUNCATE

On 9/6/19 2:18 PM, Tom Lane wrote: > Yuli Khodorkovskiy writes: >> On Fri, Sep 6, 2019 at 11:57 AM Tom Lane wrote: >>> Well, the larger question, independent of the regression tests, is >>> will the new policy work at all on older SELinux? If not, that >>> doesn't seem very acceptable. > >> The

Re: add a MAC check for TRUNCATE

On 9/6/19 2:13 PM, Yuli Khodorkovskiy wrote: > As Joe Conway pointed out to me out of band, the build animal for RHEL > 7 has handle_unknown set to `0`. Are there any other concerns with > this approach? You mean deny_unknown I believe. "Allow unknown object class / permissions.

Re: add a MAC check for TRUNCATE

On 9/6/19 8:07 PM, Tom Lane wrote: > Joe Conway writes: >> On 9/6/19 2:18 PM, Tom Lane wrote: >>> sepgsql hasn't worked on RHEL6 in a long time, if ever; it requires >>> a newer version of libselinux than what ships in RHEL6. So I'm not >>> concerne

Re: add a MAC check for TRUNCATE

On 9/25/19 3:56 PM, Alvaro Herrera wrote: > Hello > > On 2019-Sep-09, Yuli Khodorkovskiy wrote: > >> I have included an updated version of the sepgql patch. The >> Truncate-Hook patch is unchanged from the last version. > > This patch no longer applies. Can you please rebase? > > Joe, do you p

Re: add a MAC check for TRUNCATE

On 9/25/19 4:47 PM, Joe Conway wrote: > On 9/25/19 3:56 PM, Alvaro Herrera wrote: >> Hello >> >> On 2019-Sep-09, Yuli Khodorkovskiy wrote: >> >>> I have included an updated version of the sepgql patch. The >>> Truncate-Hook patch is unchanged from

Re: get_controlfile() can leak fds in the backend

On 2/27/19 10:26 AM, Joe Conway wrote: > On 2/27/19 2:47 AM, Michael Paquier wrote: >> Hi all, >> (CC-ing Joe as of dc7d70e) > According to that comment BasicOpenFile does not seem to solve the issue > you are pointing out (leaking of file descriptor on ERROR). Perhaps >

Re: get_controlfile() can leak fds in the backend

On 2/27/19 7:54 PM, Michael Paquier wrote: > On Wed, Feb 27, 2019 at 07:45:11PM -0500, Joe Conway wrote: >> It seems to me that OpenTransientFile() is more appropriate. Patch done >> that way attached. > > Works for me, thanks for sending a patch! While on it, could you >

Re: Row Level Security − leakproof-ness and performance implications

On 2/28/19 9:12 AM, Robert Haas wrote: > On Wed, Feb 27, 2019 at 6:03 PM Joe Conway wrote: >> Patch for discussion attached. > > So... you're just going to replace ALL error messages of any kind with > "ERROR: missing error text" when this option is enabled? T

Re: Row Level Security − leakproof-ness and performance implications

On 2/28/19 11:03 AM, Joshua Brindle wrote: > On Thu, Feb 28, 2019 at 10:49 AM Tom Lane wrote: >> >> Joshua Brindle writes: >> > On Thu, Feb 28, 2019 at 9:12 AM Robert Haas wrote: >> >> So... you're just going to replace ALL error messages of any kind with >> >> "ERROR: missing error text" when t

Re: Row Level Security − leakproof-ness and performance implications

On 2/28/19 11:37 AM, Robert Haas wrote: > On Thu, Feb 28, 2019 at 11:14 AM Joe Conway wrote: >> > Although, and Joe may hate me for saying this, I think only the >> > non-constants should be redacted to keep some level of usability for >> > regular SQL errors. Mayb

Re: Row Level Security − leakproof-ness and performance implications

On 2/28/19 11:50 AM, Robert Haas wrote: > On Thu, Feb 28, 2019 at 11:44 AM Joe Conway wrote: >> No, and Tom stated as much too, but life is all about tradeoffs. Some >> people will find this an acceptable compromise. For those that don't >> they don't have to use i

Re: Row Level Security − leakproof-ness and performance implications

On 2/28/19 12:28 PM, Robert Haas wrote: > Mmmph. If your customers always have a non-production instance where > problems from production can be easily reproduced, your customers are > not much like our customers. Well I certainly did not mean to imply that this is always the case ;-) But I thin

Re: get_controlfile() can leak fds in the backend

On 2/28/19 7:20 AM, Michael Paquier wrote: > On Thu, Feb 28, 2019 at 07:11:04AM -0500, Joe Conway wrote: >> Sure, will do. What are your thoughts on backpatching? This seems >> unlikely to be a practical concern in the field, so my inclination is a >> master only fix. > &

Re: Tighten error control for OpenTransientFile/CloseTransientFile

On 2/28/19 9:33 PM, Michael Paquier wrote: > Hi all, > > Joe's message here has reminded me that we have lacked a lot of error > handling around CloseTransientFile(): > https://www.postgresql.org/message-id/c49b69ec-e2f7-ff33-4f17-0eaa4f2ce...@joeconway.com > > This has been mentioned by Alvaro a

Re: Row Level Security − leakproof-ness and performance implications

On 3/18/19 3:52 PM, Peter Eisentraut wrote: > On 2019-02-28 00:03, Joe Conway wrote: >> What if we provided an option to redact all client messages (leaving >> logged messages as-is). Separately we could provide a GUC to force all >> functions to be resolved as leakpro

Re: PostgreSQL pollutes the file system

On 3/29/19 11:44 AM, Daniel Gustafsson wrote: > On Friday, March 29, 2019 4:41 PM, Tom Lane wrote: > >> Christoph Berg m...@debian.org writes: >> >> > What might possibly make sense is to add options to psql to >> > facilitate common tasks: >> >> > psql --createdb foo >> > psql --createuser bar -

Re: PostgreSQL pollutes the file system

On 3/29/19 3:01 PM, Pavel Stehule wrote: > But psql has safe escaping via :"xxx" notation. So some like > > psql -c 'create role :"role"' -v role='my role' ... > > But what I know the psql variables are not evaluated for -c query You can do this: echo "create role :\"role\"" | psql -v role='my r

Re: PostgreSQL pollutes the file system

On 3/29/19 3:43 PM, Christoph Berg wrote: > Re: Joe Conway 2019-03-29 <48e5efaf-7ea2-ed70-a803-949bbfec8...@joeconway.com> >> echo "\password :\"role\"" | psql -v role='my role' >> Enter new password: >> Enter it again: >> >> T

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

On 7/27/19 3:02 PM, Sehrope Sarkuni wrote: > More generally, without a cryptographic MAC I don't think it's > possible to provide any meaningful malicious tamper detection. And > even that would have to be off-page to deal with page replay (which I > think is out of scope). > > [1]: https://en.wik

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

On 7/29/19 6:11 PM, Sehrope Sarkuni wrote: > On Mon, Jul 29, 2019 at 4:15 PM Alvaro Herrera > wrote: > > On 2019-Jul-27, Sehrope Sarkuni wrote: > > > Given the non-cryptographic nature of CRC and its 16-bit size, I'd > > round down the malicious tampe

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

On 8/19/19 8:51 AM, Ahsan Hadi wrote: > I have shared a calendar invite for TDE/KMS weekly meeting with the > members who expressed interest of joining the meeting in this chain. > Hopefully I haven't missed anyone. > > I am not aware of everyone's timezone but I have tried to setup a time > that'

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

On 8/26/19 2:53 AM, Masahiko Sawada wrote: > I guess that this depends on the number of encryption keys we use. If > we have encryption keys per tablespace or database the number of keys > would be at most several dozen or several hundred. It's enough to have > them in flat-file format on the disk

RFC: seccomp-bpf support

SECCOMP ("SECure COMPuting with filters") is a Linux kernel syscall filtering mechanism which allows reduction of the kernel attack surface by preventing (or at least audit logging) normally unused syscalls. Quoting from this link: https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt

Re: RFC: seccomp-bpf support

On 8/28/19 1:03 PM, Peter Eisentraut wrote: > On 2019-08-28 17:13, Joe Conway wrote: >> * systemd does not implement seccomp filters by default. Packagers may >> decide to do so, but there is no guarantee. Adding them post install >> potentially requires cooperation by g

Re: RFC: seccomp-bpf support

On 8/28/19 12:47 PM, David Fetter wrote: > On Wed, Aug 28, 2019 at 11:13:27AM -0400, Joe Conway wrote: >> SECCOMP ("SECure COMPuting with filters") is a Linux kernel syscall >> filtering mechanism which allows reduction of the kernel attack surface >> by preven

Re: RFC: seccomp-bpf support

On 8/28/19 4:07 PM, Peter Eisentraut wrote: > On 2019-08-28 21:38, Joshua Brindle wrote: >> I think we need to reign in the thread somewhat. The feature allows >> end users to define some sandboxing within PG. Nothing is being forced >> on anyone > > Features come with a maintenance cost. If we s

Re: RFC: seccomp-bpf support

On 8/29/19 10:00 AM, Tom Lane wrote: > Joe Conway writes: >> Clearly Joshua and I disagree, but understand that the consensus is not >> on our side. It is our assessment that PostgreSQL will be subject to >> seccomp willingly or not (e.g., via docker, systemd, etc.) and the

Re: A space-efficient, user-friendly way to store categorical data

On 02/11/2018 10:06 PM, Thomas Munro wrote: > On Mon, Feb 12, 2018 at 12:24 PM, Andrew Dunstan > wrote: >> On Mon, Feb 12, 2018 at 9:10 AM, Tom Lane wrote: >>> Andrew Kane writes: A better option could be a new "dynamic enum" type, which would have similar storage requirements as an en

Re: add a MAC check for TRUNCATE

On 11/8/19 9:02 AM, Yuli Khodorkovskiy wrote: > On Thu, Nov 7, 2019 at 7:46 PM Michael Paquier wrote: >> >> On Mon, Sep 30, 2019 at 11:38:05AM -0300, Alvaro Herrera wrote: >> > On 2019-Sep-30, Joe Conway wrote: >> > >> > > I am not sure I will get to

Re: add a MAC check for TRUNCATE

On 11/8/19 9:16 AM, Joe Conway wrote: > On 11/8/19 9:02 AM, Yuli Khodorkovskiy wrote: >> On Thu, Nov 7, 2019 at 7:46 PM Michael Paquier wrote: >>> >>> On Mon, Sep 30, 2019 at 11:38:05AM -0300, Alvaro Herrera wrote: >>> > On 2019-Sep-30, Joe Conway wrote: &g

Re: add a MAC check for TRUNCATE

On 11/20/19 2:30 PM, Joe Conway wrote: > On 11/8/19 9:16 AM, Joe Conway wrote: >> On 11/8/19 9:02 AM, Yuli Khodorkovskiy wrote: >>> On Thu, Nov 7, 2019 at 7:46 PM Michael Paquier wrote: >>>> >>>> On Mon, Sep 30, 2019 at 11:38:05AM -0300, Alvaro Herrer

Re: add a MAC check for TRUNCATE

On 11/22/19 3:07 AM, Michael Paquier wrote: > On Wed, Nov 20, 2019 at 02:30:12PM -0500, Joe Conway wrote: >> I tested this successfully on Rhinoceros, both with and without >> "db_table: { truncate }" loaded in the policy. Updated patches attached >> here with some

Re: string literal continuations in C

On 12/23/19 2:51 PM, Alvaro Herrera wrote: > Per a recent thread, these patches remove string literals split with > \-escaped newlines. The first is for the message "materialize mode > required, but it is not allowed in this context" where it's more > prevalent, and we keep perpetuating it; the se

Re: RFC: seccomp-bpf support

On 1/6/20 8:37 PM, Tomas Vondra wrote: > Hi, > > This patch is currently in "needs review" state, but the last message is > from August 29, and my understanding is that there have been a couple of > objections / disagreements about the architecture, difficulties with > producing the set of syscall

Re: [PATCH v20] GSSAPI encryption support

On 4/2/19 6:18 PM, Stephen Frost wrote: > Greetings, > > On Tue, Apr 2, 2019 at 18:10 Peter Eisentraut > > wrote: > > On 2019-02-23 17:27, Stephen Frost wrote: > >> About pg_hba.conf: The "hostgss" keyword seems a bit confusing.  > It only >

Re: Should the docs have a warning about pg_stat_reset()?

On 4/13/19 3:42 PM, Tomas Vondra wrote: > If only we had a way to regularly snapshot the data from within the > database, and then compute the deltas on that. If only we could insert > data from one table into another one a then do some analysics on it, > with like small windows moving over the dat

TRACE_SORT defined by default

I just noticed that TRACE_SORT is defined by default (since 2005 apparently). It seems odd since it is the only debugging code enabled by default. Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development signature.a

Re: TRACE_SORT defined by default

On 4/24/19 5:10 PM, Peter Geoghegan wrote: > On Wed, Apr 24, 2019 at 2:07 PM Joe Conway wrote: >> I just noticed that TRACE_SORT is defined by default (since 2005 >> apparently). It seems odd since it is the only debugging code enabled by >> default. > > I think th

Re: How to install login_hook in Postgres 10.5

On 5/13/19 8:32 PM, Michael Paquier wrote: > On Mon, May 13, 2019 at 01:06:10PM -0700, legrand legrand wrote: >> that finished commited >> "pgsql: Add hooks for session start and session end" >> https://www.postgresql.org/message-id/flat/575d6fa2-78d0-4456-8600-302fc35b2591%40dunslane.net#0819e315c

stawidth inconsistency with all NULL columns

Consider: CREATE TABLE testwid ( txtnotnull text, txtnull text, int8notnull int8, int8null int8 ); INSERT INTO testwid SELECT 'a' || g.i, NULL, g.i, NULL FROM generate_series(1,1) AS g(i); ANALYZE testwid; SELECT attname, avg_width FROM pg_stats WHERE tablename = '

Re: stawidth inconsistency with all NULL columns

On 5/21/19 3:55 PM, Tom Lane wrote: > Joe Conway writes: >> else if (null_cnt > 0) >> { >> /* We found only nulls; assume the column is entirely null */ >> stats->stats_valid = true; >> stats->stanullfrac = 1.0; >> if (is_varwidth

Re: initdb recommendations

On 5/23/19 10:30 PM, Stephen Frost wrote: > Greetings, > > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> "Jonathan S. Katz" writes: >> > For now I have left in the password based method to be scram-sha-256 as >> > I am optimistic about the support across client drivers[1] (and FWIW I >> > have an imp

Re: initdb recommendations

On 5/24/19 8:13 AM, Stephen Frost wrote: > Greetings, > > * Joe Conway (m...@joeconway.com) wrote: >> On 5/23/19 10:30 PM, Stephen Frost wrote: >> > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> >> "Jonathan S. Katz" writes: >> >> > For

Re: Excessive memory usage in multi-statement queries w/ partitioning

On 5/24/19 1:47 AM, Amit Langote wrote: > On 2019/05/23 4:15, Andreas Seltenreich wrote: >> …but when doing it on the parent relation, even 100 statements are >> enough to exceed the limit: >> >> , >> | $ psql -c "$(yes update t set c=c where c=6 \; | head -n 100)" >> | FEHLER: Speicher aufge

Re: initdb recommendations

On 5/24/19 8:56 AM, Jonathan S. Katz wrote: > On 5/24/19 8:33 AM, Stephen Frost wrote: >> * Magnus Hagander (mag...@hagander.net) wrote: >>> Making the default change away from trust in the source distro will affect >>> few people. >> >> Agreed. > > +1 Fewer people, but likely disproportionately

Re: Excessive memory usage in multi-statement queries w/ partitioning

On 5/24/19 9:33 AM, David Rowley wrote: > On Sat, 25 May 2019 at 00:18, Joe Conway wrote: >> I admittedly haven't followed this thread too closely, but if having 100 >> partitions causes out of memory on pg11, that sounds like a massive >> regression to me. > > F

Re: Excessive memory usage in multi-statement queries w/ partitioning

On 5/24/19 10:28 AM, Tom Lane wrote: > Joe Conway writes: >> On 5/24/19 9:33 AM, David Rowley wrote: >>> For it to have regressed it would have had to once have been better, >>> but where was that mentioned? The only thing I saw was >>> non-partitioned tables

Re: New committer: David Rowley

On 5/30/19 11:43 AM, Andres Freund wrote: > Hi, > > On 2019-05-30 11:39:23 -0400, Magnus Hagander wrote: >> For those of you that have not read the minutes from the developer meeting >> ahead of pgcon (can be found at >> https://wiki.postgresql.org/wiki/PgCon_2019_Developer_Meeting), we'd like >>

Re: pg_config wrongly marked as not parallel safe?

On 11/26/18 6:45 PM, Andres Freund wrote: > Hi, > > Triggered by the thread at [1] I looked for functions marked as > immutable but not parallel safe. > > postgres[19492][1]=# SELECT oid::regprocedure, provolatile, proparallel FROM > pg_proc WHERE provolatile = 'i' AND proparallel != 's'; > ┌───

Re: pg_config wrongly marked as not parallel safe?

On 11/26/18 7:08 PM, Andres Freund wrote: > On 2018-11-26 19:04:46 -0500, Joe Conway wrote: >> Not intentional. Though, sitting here chatting with Stephen about it, I >> am now wondering if pg_config() should actually be marked immutable: >> >> select * from pg_con

Re: pg_config wrongly marked as not parallel safe?

On 11/30/18 3:30 AM, Kyotaro HORIGUCHI wrote: > # And returning to the topic, I vote for pg_config should be "stable". And on that note, Does this change does warrant backpatching, or should be applied to master only? Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure En

missing toast table for pg_policy

Currently if you try to create a too large policy, it fails with: ERROR: row is too big: size X, maximum size 8160 An example for reproducing this is attached. Looking at the issue, the problem seems to be missing toast table for pg_policy. Also attached is a one line patch. It isn't clear

Re: missing toast table for pg_policy

On 02/16/2018 05:07 PM, Andres Freund wrote: > Hi, > > On 2018-02-16 16:56:15 -0500, Joe Conway wrote: >> Looking at the issue, the problem seems to be missing toast table for >> pg_policy. Also attached is a one line patch. It isn't clear to me >> whether this

Re: missing toast table for pg_policy

On 02/16/2018 05:24 PM, Tom Lane wrote: > Joe Conway writes: >> On 02/16/2018 05:07 PM, Andres Freund wrote: >>> If problematic for < master users I think you'll have to restart cluster >>> with allow_system_table_mods, manually create/drop toasted column. IIR

Re: missing toast table for pg_policy

On 02/17/2018 11:39 AM, Tom Lane wrote: > Joe Conway writes: >> Yes, exactly. I'm fine with not backpatching, just wanted to raise the >> possibility. I will push later today to HEAD (with a catalog version bump). > > BTW, I was wondering if it'd be a good

Re: missing toast table for pg_policy

On 02/18/2018 11:18 AM, Tom Lane wrote: > Joe Conway writes: >> Is there really a compelling reason to not just create toast tables for >> all system catalogs as in the attached? > > What happens when you VACUUM FULL pg_class? (The associated toast table > would have to

Re: SHA-2 functions

On 02/19/2018 08:43 AM, Peter Eisentraut wrote: > I also noticed while working on some SSL code that we have perfectly > good SHA-2 functionality in the server already, but it has no test > coverage outside the SCRAM tests. > > So I suggest these patches that expose the new functions sha224(), > s

Re: missing toast table for pg_policy

On 02/18/2018 01:33 PM, Joe Conway wrote: > On 02/18/2018 11:18 AM, Tom Lane wrote: >> I'm fairly suspicious of toasting anything that the toast mechanism itself >> depends on, actually, and that would include at least pg_attribute and >> pg_index as well as pg_class. Ma

Re: public schema default ACL

On 03/03/2018 01:56 AM, Noah Misch wrote: > Commit 5770172 ("Document security implications of search_path and the public > schema.") is largely a workaround for the fact that the boot_val of > search_path contains "public" while template0 gets "GRANT CREATE, USAGE ON > SCHEMA public TO PUBLIC". I

Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly

On 03/05/2018 11:19 AM, Tom Lane wrote: > Joe, I wonder if you could add "log_autovacuum_min_duration = 0" to > rhinoceros' extra_config options, temporarily? Correlating that log > output with the log_statement output from the test proper would let > us confirm or deny whether it's autovacuum.

Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly

On 03/05/2018 02:07 PM, Tom Lane wrote: > So you can revert the rhinoceros config change if you like --- thanks > for making it so quickly! Ok, reverted. > Meanwhile, I'm back to wondering what could possibly have affected > the planner's estimates, if pg_proc and pg_statistic didn't change. > I

Re: System username in pg_stat_activity

g system_user as the field name? (because if we keep auth_method:identity it's not really the authname anyway). I was worried system_user or sysuser would both be confusing with the fact that we have usesysid -- which would reference a *different* sys... I think if it is exactly &quo

Re: [17] CREATE SUBSCRIPTION ... SERVER

e it might make sense to use quote_literal_cstr() rather than defining your own appendEscapedValue() function? -- Joe Conway PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Re: pgjdbc is not working with PKCS8 certificates with password

at org.postgresql.ssl.MakeSSL.convert(MakeSSL.java:43) at org.postgresql.core.v3.ConnectionFactoryImpl.enableSSL(ConnectionFactoryImpl.java:584) at org.postgresql.core.v3.ConnectionFactoryImpl.tryConnect(ConnectionFactoryImpl.java:168) / /.../ Regards, Madhu -- J

Re: Non-superuser subscription owners

earch: https://docs.oracle.com/javase/8/docs/api/java/security/AccessController.html#doPrivileged-java.security.PrivilegedAction-java.security.AccessControlContext- https://learn.microsoft.com/en-us/dotnet/api/system.security.permissions.dataprotectionpermission.intersect?view=dotnet-plat-ext-7.0

Re: Improving inferred query column names

you'd soon be hitting NAMEDATALEN limits ... Probably an unpalatable idea, but if we did something like md5('avg(reltuples / relpages)') for the column name, it would be (reasonably) unique and deterministic. Not pretty, but possibly useful in some cases. -- Joe Conway Pos

Re: Possibility to disable `ALTER SYSTEM`

ike a security feature, and describes the intended use case.) I agree with pretty much all of this. +1 me too. -- Joe Conway PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Re: Popcount optimization using AVX512

s would be gratefully accepted... -- Joe Conway PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

  1   2   3   4   5   6   >