Re: Statistics Import and Export

Greetings, On Fri, Mar 29, 2024 at 19:35 Jeff Davis wrote: > On Fri, 2024-03-29 at 18:02 -0400, Stephen Frost wrote: > > I’d certainly think “with stats” would be the preferred default of > > our users. > > I'm concerned there could still be paths that lead to an er

Re: Statistics Import and Export

Greetings, On Fri, Mar 29, 2024 at 11:05 Jeff Davis wrote: > On Fri, 2024-03-29 at 05:32 -0400, Corey Huinker wrote: > > 0002: > > - All relstats and attrstats calls are now their own statement > > instead of a compound statement > > - moved the archive TOC entry from post-data back to

Re: Large block sizes support in Linux

Greetings, * Pankaj Raghav (ker...@pankajraghav.com) wrote: > On 23/03/2024 05:53, Thomas Munro wrote: > > On Fri, Mar 22, 2024 at 10:56 PM Pankaj Raghav (Samsung) > > wrote: > >> My team and I have been working on adding Large block size(LBS) > >> support to XFS in Linux[1]. Once this feature

Re: Statistics Import and Export

Greetings, * Corey Huinker (corey.huin...@gmail.com) wrote: > > No, we should be keeping the lock until the end of the transaction > > (which in this case would be just the one statement, but it would be the > > whole statement and all of the calls in it). See analyze.c:268 or > > so, where we

Re: Statistics Import and Export

Greetings, * Corey Huinker (corey.huin...@gmail.com) wrote: > > > One persistent problem is that there is no _safe equivalent to ARRAY_IN, > > so > > > that can always fail on us, though it should only do so if the string > > > passed in wasn't a valid array input format, or the values in the

Re: Statistics Import and Export

Greetings, * Corey Huinker (corey.huin...@gmail.com) wrote: > > Having thought about it a bit more, I generally like the idea of being > > able to just update one stat instead of having to update all of them at > > once (and therefore having to go look up what the other values currently > >

Re: Statistics Import and Export

Greetings, * Corey Huinker (corey.huin...@gmail.com) wrote: > > > +/* > > > + * Set statistics for a given pg_class entry. > > > + * > > > + * pg_set_relation_stats(relation Oid, reltuples double, relpages int) > > > + * > > > + * This does an in-place (i.e. non-transactional) update of pg_class,

Re: Statistics Import and Export

Greetings, * Corey Huinker (corey.huin...@gmail.com) wrote: > > Having some discussion around that would be useful. Is it better to > > have a situation where there are stats for some columns but no stats for > > other columns? There would be a good chance that this would lead to a > > set of

Re: Proposal to add page headers to SLRU pages

Greetings, * Li, Yong (y...@ebay.com) wrote: > > On Mar 7, 2024, at 03:09, Stephen Frost wrote: > > * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote: > >> I suppose this is important to do if we ever want to move SLRUs into > >> shared buffers. However, I wonder

Re: improve ssl error code, 2147483650

Greetings, * Heikki Linnakangas (hlinn...@iki.fi) wrote: > On 07/03/2024 02:12, David Zhang wrote: > > The SSL_CTX_load_verify_locations function in OpenSSL will return NULL > > if there is a system error, such as "No such file or directory" in this > > case: > > > > const char

Re: Provide a pg_truncate_freespacemap function

Greetings, * Ronan Dunklau (ronan.dunk...@aiven.io) wrote: > As we are currently experiencing a FSM corruption issue [1], we need to > rebuild FSM when we detect it. Ideally, we'd figure out a way to pick up on this and address it without the user needing to intervene, however ... > I noticed

Re: Proposal to add page headers to SLRU pages

Greetings, * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote: > I suppose this is important to do if we ever want to move SLRUs into > shared buffers. However, I wonder about the extra time this adds to > pg_upgrade. Is this something we should be concerned about? Is there > any

Re: Statistics Import and Export

Greetings, * Matthias van de Meent (boekewurm+postg...@gmail.com) wrote: > On Wed, 6 Mar 2024 at 11:33, Stephen Frost wrote: > > On Wed, Mar 6, 2024 at 11:07 Matthias van de Meent > > wrote: > >> Or even just one VALUES for the whole statistics loading? > > I don’

Re: Statistics Import and Export

Greetings, On Wed, Mar 6, 2024 at 11:07 Matthias van de Meent < boekewurm+postg...@gmail.com> wrote: > On Fri, 1 Mar 2024, 04:55 Corey Huinker, wrote: > >> Also per our prior discussion- this makes sense to include in post-data > section, imv, and also because then we have the indexes we may

Re: [PATCH] updates to docs about HOT updates for BRIN

Greetings, * Jeff Davis (pg...@j-davis.com) wrote: > On Tue, 2024-02-27 at 09:48 -0500, Stephen Frost wrote: > > Attached is an updated patch which drops the 'such as' and adds a > > sentence mentioning that BRIN is the only in-core summarizing index. > > The original pat

Re: Statistics Import and Export

Greetings, On Fri, Mar 1, 2024 at 12:14 Nathan Bossart wrote: > On Thu, Feb 29, 2024 at 10:55:20PM -0500, Corey Huinker wrote: > >> That’s certainly a fair point and my initial reaction (which could > >> certainly be wrong) is that it’s unlikely to be an issue- but also, if > you > >> feel you

Re: Statistics Import and Export

Greetings, On Thu, Feb 29, 2024 at 17:48 Corey Huinker wrote: > Having looked through this thread and discussed a bit with Corey >> off-line, the approach that Tom laid out up-thread seems like it would >> make the most sense overall- that is, eliminate the JSON bits and the >> SPI and instead

Re: Statistics Import and Export

Greetings, * Corey Huinker (corey.huin...@gmail.com) wrote: > On Thu, Feb 15, 2024 at 4:09 AM Corey Huinker > wrote: > > Posting v5 updates of pg_import_rel_stats() and pg_import_ext_stats(), > > which address many of the concerns listed earlier. > > > > Leaving the export/import scripts off for

Re: Atomic ops for unlogged LSN

Greetings, * Nathan Bossart (nathandboss...@gmail.com) wrote: > Here is a new version of the patch that uses the new atomic read/write > functions with full barriers that were added in commit bd5132d. Thoughts? Saw that commit go in- glad to see it. Thanks for updating this patch too. The

Re: [PATCH] updates to docs about HOT updates for BRIN

Greetings, * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote: > On 2024-Feb-26, Stephen Frost wrote: > > Here's an updated patch which tries to improve on the wording a bit by > > having it be a bit more consistent. Would certainly welcome feedback on > > it though, of cour

Re: [PATCH] updates to docs about HOT updates for BRIN

Greetings, * Elizabeth Christensen (elizabeth.christen...@crunchydata.com) wrote: > > On Feb 26, 2024, at 4:21 PM, Stephen Frost wrote: > > * Elizabeth Christensen (elizabeth.christen...@crunchydata.com) wrote: > >> I have a small documentation patch to the HOT upd

Re: Control your disk usage in PG: Introduction to Disk Quota Extension

Greetings, * Xing Guo (higuox...@gmail.com) wrote: > Looks that many hackers are happy with the original patch except that > the original patch needs a simple rebase, though it has been 3 years. I'm not completely against the idea of adding these hooks, but I have to say that it's unfortunate to

Re: [PATCH] updates to docs about HOT updates for BRIN

Greetings, * Elizabeth Christensen (elizabeth.christen...@crunchydata.com) wrote: > I have a small documentation patch to the HOT updates page > to add references > to summary (BRIN) indexes not blocking HOT updates >

Re: Set log_lock_waits=on by default

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > >> On Tue, 2024-02-06 at 12:29 -0500, Tom Lane wrote: > >>> I was, and remain, of the opinion that that was a bad idea that > >>> we'll eventually revert, just like we previously g

Re: Set log_lock_waits=on by default

Greetings, * Laurenz Albe (laurenz.a...@cybertec.at) wrote: > On Tue, 2024-02-06 at 12:29 -0500, Tom Lane wrote: > > Nathan Bossart writes: > > > It looks like there are two ideas: > > > [...] > > > * Set log_lock_waits on by default. The folks on this thread seem to > > > support this idea,

Re: Detecting some cases of missing backup_label

Greetings, * Stephen Frost (sfr...@snowman.net) wrote: > * Andres Freund (and...@anarazel.de) wrote: > > I recently mentioned to Robert (and also Heikki earlier), that I think I > > see a > > way to detect an omitted backup_label in a relevant subset of the cases

Re: Detecting some cases of missing backup_label

Greetings, * Andres Freund (and...@anarazel.de) wrote: > I recently mentioned to Robert (and also Heikki earlier), that I think I see a > way to detect an omitted backup_label in a relevant subset of the cases (it'd > apply to the pg_control as well, if we moved to that). Robert encouraged me >

Re: [HACKERS] Changing references of password encryption to hashing

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Nov 28, 2023 at 12:24 PM Stephen Frost wrote: > > I don’t know what they’re doing now, as you don’t say, and so I really > > couldn’t say if ldap is better or worse for them. In some cases, sure, > > perhap

Re: [HACKERS] Changing references of password encryption to hashing

Greetings, On Tue, Nov 28, 2023 at 20:19 Robert Haas wrote: > On Tue, Nov 28, 2023 at 10:16 AM Stephen Frost wrote: > > We pass a completely cleartext password to the server from the client. > > Yes, we might encrypt it on the way with TLS, but even SSH realized how > >

Re: Add recovery to pg_control and remove backup_label

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Sun, Nov 26, 2023 at 3:42 AM Stephen Frost wrote: > > What would really be helpful would be hearing from these individuals > > directly as to what the issues are with the changes, such that perhaps > > we

Re: [HACKERS] Changing references of password encryption to hashing

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Nov 28, 2023 at 9:55 AM Stephen Frost wrote: > > I do think we should use the correct terminology in our documentation > > and would support your working on improving things in this area. > > +1. > >

Re: [HACKERS] Changing references of password encryption to hashing

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > Is there any interest in fixing our documentation that says encrypted > when it means hashed? Should I pursue this? I do think we should use the correct terminology in our documentation and would support your working on improving things in

Re: Partial aggregates pushdown

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Nov 27, 2023 at 4:23 PM Tom Lane wrote: > > Well, one of the founding principles of postgres_fdw was to be able > > to talk to PG servers that are not of the same version as yours. > > If we break that in the name of performance,

Re: Add recovery to pg_control and remove backup_label

Greetings, * David Steele (da...@pgmasters.net) wrote: > On 11/21/23 12:41, Andres Freund wrote: > > Sure. They also receive a backup_label today. If an external solution > > forgets > > to replace pg_control copied as part of the filesystem copy, they won't get > > an > > error after the

Re: [PATCHES] Post-special page storage TDE support

Greetings, On Mon, Nov 13, 2023 at 16:53 David Christensen < david.christen...@crunchydata.com> wrote: > On Mon, Nov 13, 2023 at 2:52 PM Andres Freund wrote: > >> >> > This scheme would open up space per page that would now be available for >> > plenty of other things; the encoding in the

Re: [PATCHES] Post-special page storage TDE support

Greetings, On Wed, Nov 8, 2023 at 20:55 David Christensen < david.christen...@crunchydata.com> wrote: > On Wed, Nov 8, 2023 at 8:04 AM Stephen Frost wrote: > >> * Andres Freund (and...@anarazel.de) wrote: >> > On 2023-05-09 17:08:26 -0500, David Chr

Re: [PATCHES] Post-special page storage TDE support

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2023-05-09 17:08:26 -0500, David Christensen wrote: > > From 965309ea3517fa734c4bc89c144e2031cdf6c0c3 Mon Sep 17 00:00:00 2001 > > From: David Christensen > > Date: Tue, 9 May 2023 16:56:15 -0500 > > Subject: [PATCH v4 1/3] Add

Re: Moving forward with TDE [PATCH v3]

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Mon, Nov 6, 2023 at 09:56:37AM -0500, Stephen Frost wrote: > > The gist is, without a suggestion of things to try, we're left > > to our own devices to try and figure out things which might be > > successful, only

Re: Add the ability to limit the amount of memory that can be allocated to backends.

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2023-11-06 13:02:50 -0500, Stephen Frost wrote: > > > > The max_total_memory limit is checked whenever the global counters are > > > > updated. There is no special error handling if a memory allocation > &g

Re: Atomic ops for unlogged LSN

Greetings, * Nathan Bossart (nathandboss...@gmail.com) wrote: > On Tue, Nov 07, 2023 at 12:57:32AM +, John Morris wrote: > > I incorporated your suggestions and added a few more. The changes are > > mainly related to catching potential errors if some basic assumptions > > aren’t met. > > Hm.

Re: Add the ability to limit the amount of memory that can be allocated to backends.

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2023-10-31 17:11:26 +, John Morris wrote: > > Postgres memory reservations come from multiple sources. > > > > * Malloc calls made by the Postgres memory allocators. > > * Static shared memory created by the postmaster at

Re: Moving forward with TDE [PATCH v3]

Greetings, Thanks for your feedback on this. * Andres Freund (and...@anarazel.de) wrote: > I still am quite quite unconvinced that using the LSN as a nonce is a good > design decision. This is a really important part of the overall path to moving this forward, so I wanted to jump to it and have

Re: Fwd: Annoying corruption in PostgreSQL.

Greetings, Please don't top-post on these lists. * Kirill Reshke (reshkekir...@gmail.com) wrote: > We have physical backups and we can PITR. But restoring a cluster to some > point in the past is a bit of a different task: we need our client's > approval for these operations, since we are a

Re: Bug: RLS policy FOR SELECT is used to check new rows

Greetings, On Tue, Oct 24, 2023 at 14:42 Robert Haas wrote: > On Tue, Oct 24, 2023 at 1:46 PM Jeff Davis wrote: > > Perhaps the idea is that if there are constraints involved, the failure > > or success of an INSERT/UPDATE/DELETE could leak information that you > > don't have privileges to

Re: Add the ability to limit the amount of memory that can be allocated to backends.

Greetings, * Andrei Lepikhov (a.lepik...@postgrespro.ru) wrote: > The only issue I worry about is the uncertainty and clutter that can be > created by this feature. In the worst case, when we have a complex error > stack (including the extension's CATCH sections, exceptions in stored >

Re: [PoC/RFC] Multiple passwords, interval expirations

Greetings, * Jeff Davis (pg...@j-davis.com) wrote: > On Wed, 2023-10-18 at 14:48 -0400, Stephen Frost wrote: > > Right, we need more observability, agreed, but that's not strictly > > necessary of this patch and could certainly be added independently.  > > Is > >

Re: Add the ability to limit the amount of memory that can be allocated to backends.

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2023-10-19 18:06:10 -0400, Stephen Frost wrote: > > Ignoring such would defeat much of the point of this effort- which is to > > get to a position where we can say with some confidence that we're not > > going

Re: Add the ability to limit the amount of memory that can be allocated to backends.

Greetings, * Andrei Lepikhov (a.lepik...@postgrespro.ru) wrote: > On 19/10/2023 02:00, Stephen Frost wrote: > > * Andrei Lepikhov (a.lepik...@postgrespro.ru) wrote: > > > On 29/9/2023 09:52, Andrei Lepikhov wrote: > > > > On 22/5/2023 22:59, reid.thomp...@crunchyda

Re: Parent/child context relation in pg_get_backend_memory_contexts()

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2023-10-18 15:53:30 -0400, Stephen Frost wrote: > > > Here how pg_backend_memory_contexts would look like with this patch: > > > > > > postgres=# SELECT name, id, parent, parent_id, path > > > FROM

Re: pg_dump needs SELECT privileges on irrelevant extension table

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > I wrote: > > Why are we marking extension member objects as being subject to SECLABEL > > or POLICY dumping? As the comment notes, that isn't really sensible > > unless what we are dumping is a delta from the extension's initial > >

Re: Parent/child context relation in pg_get_backend_memory_contexts()

Greetings, * Melih Mutlu (m.melihmu...@gmail.com) wrote: > Melih Mutlu , 16 Haz 2023 Cum, 17:03 tarihinde şunu > yazdı: > > > With this change, here's a query to find how much space used by each > > context including its children: > > > > > WITH RECURSIVE cte AS ( > > > SELECT id,

Re: Add the ability to limit the amount of memory that can be allocated to backends.

Greetings, * Andrei Lepikhov (a.lepik...@postgrespro.ru) wrote: > On 29/9/2023 09:52, Andrei Lepikhov wrote: > > On 22/5/2023 22:59, reid.thomp...@crunchydata.com wrote: > > > Attach patches updated to master. > > > Pulled from patch 2 back to patch 1 a change that was also pertinent > > > to

Re: [PoC/RFC] Multiple passwords, interval expirations

Greetings, * Jeff Davis (pg...@j-davis.com) wrote: > On Tue, 2023-10-17 at 22:52 -0400, Stephen Frost wrote: > > > Reading back through the thread, from a user perspective, the primary > > one seems to be that passwords are expected to be named.  I'm > > surprised >

Re: [PoC/RFC] Multiple passwords, interval expirations

Greetings, * Jeff Davis (pg...@j-davis.com) wrote: > On Tue, 2023-10-17 at 16:20 -0400, Stephen Frost wrote: > > Agreed that it's a bad idea to design to support 2 and only 2. > > I don't disagree, but it's difficult to come up with syntax that: > > (a) supports N p

Re: [PoC/RFC] Multiple passwords, interval expirations

Greetings, * Nathan Bossart (nathandboss...@gmail.com) wrote: > On Wed, Oct 04, 2023 at 10:41:15PM -0700, Gurjeet Singh wrote: > > The patches posted in this thread so far attempt to add the ability to > > allow the user to have an arbitrary number of passwords. I believe > > that allowing

Re: The danger of deleting backup_label

Greetings, * David Steele (da...@pgmasters.net) wrote: > On 10/16/23 15:06, Robert Haas wrote: > > On Mon, Oct 16, 2023 at 1:00 PM David Steele wrote: > > > After some agonizing (we hope) they decide to delete backup_label and, > > > wow, it just works! So now they merrily go on their way with a

Re: Disabling Heap-Only Tuples

Greetings, * Laurenz Albe (laurenz.a...@cybertec.at) wrote: > On Tue, 2023-09-19 at 12:52 -0400, Robert Haas wrote: > > On Tue, Sep 19, 2023 at 12:30 PM Alvaro Herrera > > wrote: > > > I was thinking something vaguely like "a table size that's roughly what > > > an optimal autovacuuming

Re: Possibility to disable `ALTER SYSTEM`

Greetings, * Magnus Hagander (mag...@hagander.net) wrote: > On Mon, Sep 11, 2023 at 1:56 PM Martín Marqués > wrote: > > > I would like to propose a patch that allows administrators to disable > > > `ALTER SYSTEM` via either a runt-time option to pass to the Postgres > > > server process at

Re: Adding a pg_get_owned_sequence function?

Greetings, * Nathan Bossart (nathandboss...@gmail.com) wrote: > On Fri, Sep 01, 2023 at 01:31:43PM -0400, Tom Lane wrote: > > Nathan Bossart writes: > >> I wonder if it'd be possible to just remove pg_get_serial_sequence(). > > > > A quick search at http://codesearch.debian.net/ finds uses of

Re: SLRUs in the main buffer pool - Page Header definitions

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Aug 24, 2023 at 3:28 PM Stephen Frost wrote: > > Agreed that we'd certainly want to make sure it's all correct and to do > > performance testing but in terms of how many buffers... isn't much of > > the point

Re: Let's make PostgreSQL multi-threaded

Greetings, * David Geier (geidav...@gmail.com) wrote: > On 8/11/23 14:05, Merlin Moncure wrote: > > Hm, noted this upthread, but asking again, does this > > help/benefit interactions with the operating system make oom kill > > situations less likely?   These things are the bane of my existence,

Re: SLRUs in the main buffer pool - Page Header definitions

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Aug 18, 2023 at 12:15 PM Nathan Bossart > wrote: > > I think I agree with Stephen. We routinely make changes that require > > updates to extensions, and I doubt anyone is terribly wild about > > maintaining two SLRU systems for

Re: Logging of matching pg_hba.conf entry during auth skips trust auth, potential security issue

Greetings, On Thu, Aug 17, 2023 at 15:23 Robert Haas wrote: > On Thu, Aug 17, 2023 at 12:54 PM Jacob Champion > wrote: > > On Thu, Aug 17, 2023 at 9:46 AM Stephen Frost > wrote: > > > Don't like 'skipped' but that feels closer. > > > > > > How

Re: Logging of matching pg_hba.conf entry during auth skips trust auth, potential security issue

Greetings, * Jacob Champion (jchamp...@timescale.com) wrote: > On Thu, Aug 17, 2023 at 9:01 AM Stephen Frost wrote: > > Maybe 'connection allowed' instead..? > > Hm. It hasn't really been allowed yet, either. To illustrate what I mean: > > LOG: connection received: h

Re: Logging of matching pg_hba.conf entry during auth skips trust auth, potential security issue

Greetings, * Jacob Champion (jchamp...@timescale.com) wrote: > Maybe something like the attached? > - I used the phrasing "connection not authenticated" in the hopes that > it's a bit more greppable than just "connection", especially in > combination with the existing "connection authenticated"

Re: odd buildfarm failure - "pg_ctl: control file appears to be corrupt"

Greetings, (Adding David Steele into the CC on this one...) * Thomas Munro (thomas.mu...@gmail.com) wrote: > This is a frustrating thread, because despite the last patch solving > most of the problems we discussed, it doesn't address the > low-level-backup procedure in a nice way. We'd have to

Re: Dumping policy on a table belonging to an extension is expected?

Greetings, * Amul Sul (sula...@gmail.com) wrote: > I have a ROW LEVEL SECURITY policy on the table part of an extension, and > while > dumping the database where that extension is installed, dumps the policy of > that table too even though not dumpling that table . > > Here is quick tests, where

Re: Atomic ops for unlogged LSN

Greetings, * Nathan Bossart (nathandboss...@gmail.com) wrote: > On Mon, Jun 12, 2023 at 07:24:18PM -0400, Stephen Frost wrote: > > * Nathan Bossart (nathandboss...@gmail.com) wrote: > >> Is it? I see uses in GiST indexing (62401db), so it's not immediately > >> obviou

Re: SLRUs in the main buffer pool - Page Header definitions

Greetings, [snipped quoted bits] Would really be helpful to keep who the author of each quoted snipper was when you quote them; dropping that makes it look like one person wrote all of them and that's confusing. * Bagga, Rishu (bagri...@amazon.com) wrote: > The third patch brings back the the

Re: pg_upgrade instructions involving "rsync --size-only" might lead to standby corruption?

Greetings, * Nikolay Samokhvalov (n...@postgres.ai) wrote: > On Fri, Jun 30, 2023 at 14:33 Bruce Momjian wrote: > > On Fri, Jun 30, 2023 at 04:16:31PM -0400, Robert Haas wrote: > > > I'm not quite clear on how Nikolay got into trouble here. I don't > > > think I understand under exactly what

Re: Atomic ops for unlogged LSN

Greetings, * Nathan Bossart (nathandboss...@gmail.com) wrote: > On Thu, May 25, 2023 at 07:41:21AM +0900, Michael Paquier wrote: > > On Wed, May 24, 2023 at 02:49:58PM -0700, Andres Freund wrote: > >> So we indeed loose some "barrier strength" - but I think that's fine. For > >> one, > >> it's a

Re: Let's make PostgreSQL multi-threaded

Greetings, * Dave Cramer (davecramer@postgres.rocks) wrote: > One thing I can think of is upgrading. AFAIK dump and restore is the only > way to change the on disk format. > Presuming that eventually we will be forced to change the on disk format it > would be nice to be able to do so in a manner

Re: Docs: Encourage strong server verification with SCRAM

Greetings, * Jacob Champion (jchamp...@timescale.com) wrote: > On 5/24/23 05:04, Daniel Gustafsson wrote: > >> On 23 May 2023, at 23:02, Stephen Frost wrote: > >> Perhaps more succinctly- maybe we should be making adjustments to the > >> current language instead

Re: Large files for relations

Greetings, * Peter Eisentraut (peter.eisentr...@enterprisedb.com) wrote: > On 24.05.23 02:34, Thomas Munro wrote: > > Thanks all for the feedback. It was a nice idea and it *almost* > > works, but it seems like we just can't drop segmented mode. And the > > automatic transition schemes I showed

Re: Docs: Encourage strong server verification with SCRAM

Greetings, * Michael Paquier (mich...@paquier.xyz) wrote: > On Tue, May 23, 2023 at 09:46:58PM -0400, Stephen Frost wrote: > > Not without breaking things we support today and for what seems like an > > unclear benefit given that we've got channel binding today (though > > pe

Re: Docs: Encourage strong server verification with SCRAM

Greetings, * Michael Paquier (mich...@paquier.xyz) wrote: > On Tue, May 23, 2023 at 05:02:50PM -0400, Stephen Frost wrote: > > * Jacob Champion (jchamp...@timescale.com) wrote: > >> As touched on in past threads, our SCRAM implementation is slightly > >> nonstandard

Re: Docs: Encourage strong server verification with SCRAM

Greetings, * Jacob Champion (jchamp...@timescale.com) wrote: > As touched on in past threads, our SCRAM implementation is slightly > nonstandard and doesn't always protect the entirety of the > authentication handshake: > > - the username in the startup packet is not covered by the SCRAM >

Re: Naming of gss_accept_deleg

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Abhijit Menon-Sen writes: > > At 2023-05-20 23:21:57 -0400, t...@sss.pgh.pa.us wrote: > >> I thought the plan was to also rename the libpq "gssdeleg" connection > >> parameter and so on? I can look into that tomorrow, if nobody beats > >> me

Re: Adding SHOW CREATE TABLE

Greetings, On Sat, May 20, 2023 at 13:32 David G. Johnston wrote: > On Sat, May 20, 2023 at 10:26 AM Stephen Frost wrote: > >> > A server function can be conveniently called from any client code. >> >> Clearly any client using libpq can conveniently cal

Re: Adding SHOW CREATE TABLE

Greetings, * Laurenz Albe (laurenz.a...@cybertec.at) wrote: > On Fri, 2023-05-19 at 13:08 -0400, Andrew Dunstan wrote: > > On 2023-05-18 Th 19:53, Stephen Frost wrote: > > > * Kirk Wolak (wol...@gmail.com) wrote: > > > > My approach for now is to develop this as

Re: How to ensure that SSPI support (Windows) enabled?

Greetings, Please don't top-post. * Dimitry Markman (dmark...@mathworks.com) wrote: > I was asking our 3p library people how to add windows support to gss and they > said that on windows we should use SSPI They're correct. > I’m not really familiar with either gssapi or SSPI Kerberos support

Re: Naming of gss_accept_deleg

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > Why is the new PG 16 GUC called "gss_accept_deleg" and not > "gss_accept_delegation"? The abbreviation here seems atypical. At the time it felt natural to me but I don't feel strongly about it, happy to change it if folks would prefer it

Re: Adding SHOW CREATE TABLE

Greetings, * Kirk Wolak (wol...@gmail.com) wrote: > My approach for now is to develop this as the \st command. > After reviewing the code/output from the 3 sources (psql, fdw, and > pg_dump). This trivializes the approach, > and requires the smallest set of changes (psql is already close with >

Re: [PATCHES] Post-special page storage TDE support

Greetings, * David Christensen (david.christen...@crunchydata.com) wrote: > Refreshing this with HEAD as of today, v4. Thanks for updating this! > Subject: [PATCH v4 1/3] Add reserved_page_space to Page structure > > This space is reserved for extended data on the Page structure which will be

Re: Large files for relations

Greetings, * Dagfinn Ilmari Mannsåker (ilm...@ilmari.org) wrote: > Thomas Munro writes: > > On Fri, May 12, 2023 at 8:16 AM Jim Mlodgenski wrote: > >> On Mon, May 1, 2023 at 9:29 PM Thomas Munro wrote: > >>> I am not aware of any modern/non-historic filesystem[2] that can't do > >>> large

Re: base backup vs. concurrent truncation

Greetings, * Greg Stark (st...@mit.edu) wrote: > Including the pre-truncation length in the wal record is the obviously > solid approach and I none of the below is a good substitution for it. I tend to agree with the items mentioned in Andres's recent email on this thread too in terms of

Re: Large files for relations

Greetings, * Corey Huinker (corey.huin...@gmail.com) wrote: > On Wed, May 3, 2023 at 1:37 AM Thomas Munro wrote: > > On Wed, May 3, 2023 at 5:21 PM Thomas Munro > > wrote: > > > rsync --link-dest ... rsync isn't really a safe tool to use for PG backups by itself unless you're using it with

Re: [PATCH] Allow Postgres to pick an unused port to listen

Greetings, * Peter Eisentraut (peter.eisentr...@enterprisedb.com) wrote: > On 13.04.23 04:45, Yurii Rashkovskii wrote: > > But getting your agreement is important to get this in; I am willing to > > play along and resolve both (1) and (2) in one go. As for the > > implementation approach for (2),

Re: longfin missing gssapi_ext.h

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > I'm guessing it's not really an issue but it does make changing > > configure a bit annoying on my Ubuntu 22.04, when I run autoconf2.69, I > > end up with this additional hunk as changed fr

Re: longfin missing gssapi_ext.h

Greetings, * Stephen Frost (sfr...@snowman.net) wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Stephen Frost writes: > > > Done that way. > > > > Looks like you neglected to update the configure script proper? > > Pah, indeed. Will fix. Sorry ab

Re: longfin missing gssapi_ext.h

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > Done that way. > > Looks like you neglected to update the configure script proper? Pah, indeed. Will fix. Sorry about that. Thanks, Stephen signature.asc Description: PGP signature

Re: longfin missing gssapi_ext.h

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > How about the attached which just switches from testing for > > gss_init_sec_context to testing for gss_store_cred_into? > > WFM. Done that way. Thanks! Stephen signature.asc Description: PGP signature

Re: longfin missing gssapi_ext.h

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > Pushed, thanks again to everyone. > > I'll monitor the buildfarm and assuming there isn't anything unexpected > > then I'll mark the open item as resolved now. > > The Debian 7 (Wheez

Re: PGBuildfarm member pollock Branch HEAD Failed at Stage Make

Greetings, * buildfarm-adm...@lists.postgresql.org (buildfarm-adm...@lists.postgresql.org) wrote: > The PGBuildfarm member pollock had the following event on branch HEAD: > Failed at Stage: Make > The snapshot timestamp for the build is: 2023-04-13 13:06:34 > The specs of this machine are: >

Re: longfin missing gssapi_ext.h

Greetings, * Jonathan S. Katz (jk...@postgresql.org) wrote: > On 4/12/23 12:22 PM, Stephen Frost wrote: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > > Stephen Frost writes: > > > > Updated patch set attached. > > > > > > LGTM > > > &

Re: longfin missing gssapi_ext.h

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > Updated patch set attached. > > LGTM Great, thanks. I cleaned up the commit messages a bit more and added links to the discussion. If there isn't anything more then I'll plan to push these later to

Re: longfin missing gssapi_ext.h

Greetings, * Daniel Gustafsson (dan...@yesql.se) wrote: > > On 12 Apr 2023, at 16:33, Stephen Frost wrote: > > Sure, reworked that way and attached. > > While not changed in this hunk, does the comment regarding Heimdal still > apply? > > @@ -918,6 +919,7 @@

Re: longfin missing gssapi_ext.h

Greetings, * Jonathan S. Katz (jk...@postgresql.org) wrote: > On 4/12/23 10:33 AM, Stephen Frost wrote: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > > Stephen Frost writes: > > > > Understood. Please find attached the updated patch with changes to the >

Re: longfin missing gssapi_ext.h

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > Understood. Please find attached the updated patch with changes to the > > commit message to indicate that we now require MIT Kerberos, an > > additional explicit check for gssapi_ext.h in c

Re: longfin missing gssapi_ext.h

Greetings, * Stephen Frost (sfr...@snowman.net) wrote: > Greetings, > > * Justin Pryzby (pry...@telsasoft.com) wrote: > > > configure | 27 ++ > > > configure.ac | 2 + > > > > Does me

  1   2   3   4   5   6   7   8   9   10   >