Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Mon, Jul 8, 2019 at 11:18:01AM -0400, Joe Conway wrote:
> > On 7/8/19 10:19 AM, Bruce Momjian wrote:
> > > When people are asking for multiple keys (not just for key rotation),
> > > they are asking to have multiple keys that can be suppli
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> On 2019-Jul-05, Bruce Momjian wrote:
>
> > What people really want with more-granular-than-cluster encryption is
> > the ability to supply their passphrase key _when_ they want to access
> > their data, and then leave and be sure the
Greetings,
* Thomas Munro (thomas.mu...@gmail.com) wrote:
> If the thread for a CF entry began
> before you were subscribed, you might be able to download the whole
> thread as a mailbox file and import it into your email client so that
> you can reply to the thread; if you can't do that (it can b
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Furthermore, while you can do "make install" and "make installcheck"
> in this directory or its children, it is HIGHLY NOT ADVISED to do so
> with a server containing valuable data. Some of these tests may have
> undesirable side
Greetings,
* Daniel Gustafsson (dan...@yesql.se) wrote:
> > On 27 Jun 2019, at 00:48, Andrew Gierth wrote:
>
> > Tom> In general, the point I'm trying to make is that our policy should
> > Tom> be "Ties are broken arbitrarily, and if you don't like the choice
> > Tom> that initdb makes, here's h
Greetings,
* Sascha Kuhl (yogidaba...@gmail.com) wrote:
> Does Microsoft or any other DB manufacturer have an ear on this mailing
> list?
Many, many, many of the people who are on this mailing list work for DB
manufacturers.
I suspect that most of them are manufacturing PostgreSQL.
Thanks,
Ste
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Stephen and Magnus want a warning, because it's an indication that a
> > tool author, or *something* modified the file in an unexpected way, and
> > that we are having to do some kind of clea
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> On 2019-Jun-24, Robert Haas wrote:
>
> > On Sat, Jun 22, 2019 at 5:13 PM Stephen Frost wrote:
> > > All that said, whatever code it is that we write for pg_basebackup to do
> > > this properly
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Fri, Jun 21, 2019 at 12:55 PM Tom Lane wrote:
> >> Ah, got it. So it seems like the correct behavior might be for
> >> ALTER SYSTEM to
> >> (a) run through the whole file and remove any conflicting lines;
> >> (b) ap
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sat, Jun 22, 2019 at 5:13 PM Stephen Frost wrote:
> > All that said, whatever code it is that we write for pg_basebackup to do
> > this properly should go into our client side library, so other tools can
> > leverage tha
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jun 21, 2019 at 12:55 PM Tom Lane wrote:
> > Ah, got it. So it seems like the correct behavior might be for
> > ALTER SYSTEM to
> > (a) run through the whole file and remove any conflicting lines;
> > (b) append new setting at the
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jun 21, 2019 at 11:24 AM Stephen Frost wrote:
> > That's not quite accurate, given that it isn't how the ALTER SYSTEM call
> > itself works, and clearly isn't how the authors of that feature expec
Greetings,
On Sat, Jun 22, 2019 at 17:43 Amit Kapila wrote:
> On Sun, Jun 23, 2019 at 2:43 AM Stephen Frost wrote:
> >
> > Greetings,
> >
> > On Sat, Jun 22, 2019 at 17:07 Amit Kapila
> wrote:
> >>
> >> On Fri, Jun 21, 2019 at 8:15 PM Robert H
Greetings,
On Sat, Jun 22, 2019 at 17:07 Amit Kapila wrote:
> On Fri, Jun 21, 2019 at 8:15 PM Robert Haas wrote:
> >
> > On Mon, Jun 17, 2019 at 10:50 AM Ian Barwick
> > wrote:
> > > In Pg12, the code in pg_basebackup implies the correct thing to do is
> append to .auto.conf,
> > > but as demo
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> So there's certainly some fraction of these cases where we could have
> avoided doing manual catalog updates by expending work on some ALTER
> command instead. But I don't see much reason to think that we could,
> or should try to, insist that e
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-06-21 12:28:43 -0400, Tom Lane wrote:
> > Robert Haas writes:
> > > A related issue is that alter_system_table_mods prohibits both stuff
> > > that's probably not going to cause any big problem and stuff that is
> > > almost guarant
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> I haven't been paying too close attention to this thread, but isn't
> >> that exactly what it does now and always has? guc.c, at least,
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > I kinda feel like we should prohibit DML on system catalogs, even by
> > superusers, unless you press the big red button that says "I am
> > definitely sure that I know what I'm doing."
>
> Keep in mind that DML-on-syste
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > To me, forcing every tools author to use postgresql.conf parsing tools
> > rather than just appending to the file is a needless burden on tool
> > authors. I'd vote for just having ALTER SYSTEM silently drop all but
> >
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jun 17, 2019 at 10:50 AM Ian Barwick
> wrote:
> > In Pg12, the code in pg_basebackup implies the correct thing to do is
> > append to .auto.conf,
> > but as demonstrated that can cause problems with duplicate entries.
>
> Yeah.
>
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jun 21, 2019 at 5:12 AM Peter Eisentraut
> wrote:
> > Any other thoughts?
>
> I kinda feel like we should prohibit DML on system catalogs, even by
> superusers, unless you press the big red button that says "I am
> definitely sure
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> David Steele writes:
> > On 6/21/19 9:45 AM, Tom Lane wrote:
> >> +1 for using O_CLOEXEC on machines that have it. I don't think I want to
> >> jump through hoops for machines that don't have it --- POSIX has required
> >> it for some time, so
Greetings,
* Thomas Munro (thomas.mu...@gmail.com) wrote:
> I also know that a motivated user could also use GSSAPI instead of
> LDAP. Do you think we should update the manual to say so, perhaps in
> a "tip" box on the LDAP auth page?
Hrm, not sure how I missed this before, but, yes, I'm all for
Greetings,
* Andrew Gierth (and...@tao11.riddles.org.uk) wrote:
> >>>>> "Stephen" == Stephen Frost writes:
>
> Stephen> In the situation that started this discussion, a change had
> Stephen> already been made and it was only later realized that it
&g
Greetings,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> Searching subject for "Specify thread msgid" field doesn't work. It returns
> empty result set every time.
Is this still not working? I was chatting with Magnus and it seems
possible this was broken and then fixed already.
Thanks,
S
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Jun 20, 2019 at 1:28 PM Alvaro Herrera
> wrote:
> > I suppose we could have a moratorium on commits starting from (say) EOB
> > Wednesday of the week prior to the release; patches can only be
> > committed after that if they have
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-06-20 12:02:30 -0400, Robert Haas wrote:
> > On Thu, Jun 20, 2019 at 8:52 AM Stephen Frost wrote:
> > > I don't want to come across as implying that I'm saying what was done
> > > was '
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Also on the topic of process: 48 hours before a wrap deadline is
> *particularly* not the time to play fast and loose with this sort of
> thing. It'd have been better to wait till after this week's releases,
> so there'd at least be time to reco
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Mon, Jun 17, 2019 at 5:41 PM Stephen Frost wrote:
> > I'd further say something along the lines of 'utilities should not
> > modify a postgresql.auto.conf that's in place under a running PostgreSQL
&g
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-06-17 14:34:58 -0400, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> > > On 2019-06-14 23:14:09 +0100, Andrew Gierth wrote:
> > > > So here is my current proposed fix.
> &
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-06-14 23:14:09 +0100, Andrew Gierth wrote:
> > So here is my current proposed fix.
>
> Before pushing a commit that's controversial - and this clearly seems to
> somewhat be - it'd be good to give others a heads up that you intend t
Greetings,
* Ian Barwick (ian.barw...@2ndquadrant.com) wrote:
> On 6/15/19 1:08 AM, Stephen Frost wrote:
> > * Ian Barwick (ian.barw...@2ndquadrant.com) wrote:
> >> Consider the following cascading standby setup with PostgreSQL 12:
> >>
> >> - there exists a r
Greetings,
* Ian Barwick (ian.barw...@2ndquadrant.com) wrote:
> However, going back to the original scenario (cascaded standby set up using
> "pg_basebackup --write-recovery-conf") there would now be a warning emitted
> the first time anyone executes ALTER SYSTEM (about duplicate
> "primary_conni
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> In any case, if we end up with a more complex/advanced design, I've
> already voiced my opinion that binding the keys to tablespaces is the
> wrong abstraction, and I think we'll regret it eventually. For example,
> why have we inve
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On Sun, Jun 16, 2019 at 02:10:23PM -0400, Stephen Frost wrote:
> >* Joe Conway (m...@joeconway.com) wrote:
> >>On 6/16/19 9:45 AM, Bruce Momjian wrote:
> >>> On Sun, Jun 16, 2019 at 07:07:20AM -0400, J
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Sun, Jun 16, 2019 at 12:42:55PM -0400, Joe Conway wrote:
> > On 6/16/19 9:45 AM, Bruce Momjian wrote:
> > > On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote:
> > >> In any case it doesn't address my first point, which is limiting
Greetings,
* Joe Conway (m...@joeconway.com) wrote:
> On 6/16/19 9:45 AM, Bruce Momjian wrote:
> > On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote:
> >> In any case it doesn't address my first point, which is limiting the
> >> volume encrypted with the same key. Another valid reason is
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Unless there's actually a use-case for duplicate entries in
> > postgresql.auto.conf,
>
> There isn't --- guc.c will just discard the earlier duplicates.
One might be able to argue
Greetings,
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> On Fri, Jun 14, 2019 at 9:38 PM Stephen Frost wrote:
> > * Ian Barwick (ian.barw...@2ndquadrant.com) wrote:
> > >
> > > Note this issue is not specific to pg_basebackup, primary_conninfo (or
> > >
Greetings,
* Ian Barwick (ian.barw...@2ndquadrant.com) wrote:
> Consider the following cascading standby setup with PostgreSQL 12:
>
> - there exists a running primary "A"
> - standby "B" is cloned from primary "A" using "pg_basebackup
> --write-recovery-conf"
> - standby "C" is cloned from stan
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> As mentioned on another thread about test coverage, I have noticed
> that be-gssapi-common.h is not placed at the correct location, even
> its its identication path at the top points to where the file should
> be:
> https://www.postgresql
Greetings,
* Melanie Plageman (melanieplage...@gmail.com) wrote:
> Peter and I implemented this small (attached) patch to extend
> abbreviated key compare sort to macaddr8 datatype (currently supported
> for macaddr).
Nice.
> I think that that seems like an improvement. I was thinking of
> regis
Greetings,
* Noah Misch (n...@leadboat.com) wrote:
> On Tue, May 28, 2019 at 12:15:35PM -0400, Magnus Hagander wrote:
> > On Fri, May 24, 2019 at 11:24 AM Noah Misch wrote:
> > > On Thu, May 23, 2019 at 06:56:49PM +0200, Magnus Hagander wrote:
> > > > On Thu, May 23, 2019, 18:54 Peter Eisentraut
Greetings,
* sharon clark (sc...@hotmail.com) wrote:
> I plan to submit a proposal for both the PostgreSQL Introductory Resources
> and Tutorial projects, but I’m open to learning technologies for ANY other
> projects listed. Please feel free to contact me with any questions.
Thanks for reachin
Greetings,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 24/05/2019 16:01, Stephen Frost wrote:
> >What I was really getting at though was the ability to have multiple
> >authenticator tokens active concurrently (eg: md5 AND SCRAM), with an
> >ability to use either o
Greetings,
* Jonathan S. Katz (jk...@postgresql.org) wrote:
> On 5/24/19 8:33 AM, Stephen Frost wrote:
> > We need to provide better documentation about how to get from md5 to
> > SCRAM, in my view. I'm not sure where that should live, exactly.
> > I really wish w
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> The thing that will potentially hit *end users* is when the RPMs, DEBs or
> Windows Installers switch to SCRAM (because of clients with older drivers).
Agreed. I'm not sure that our change to SCRAM as default would actually
make them ch
Greetings,
* Joe Conway (m...@joeconway.com) wrote:
> On 5/24/19 8:13 AM, Stephen Frost wrote:
> > * Joe Conway (m...@joeconway.com) wrote:
> >> On 5/23/19 10:30 PM, Stephen Frost wrote:
> >> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> >> "J
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 now I have left in the password based method to be scram-sha-256 as
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 implementation for crystal-pg ~60% done).
>
> > Howeve
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Wed, May 22, 2019 at 06:35:31PM +, Bossart, Nathan wrote:
> > A bit of digging led me to the commit that removed databases and
> > tablespaces from pg_init_privs [0] and to a related thread [1]. IIUC
> > the problem is that using
Greetings,
* Raghav Jajodia (jajodia.rag...@gmail.com) wrote:
> I am Raghav Jajodia, a software engineer from Bangalore, India. I have been
> a diligent open source contributor and have been a student under the
> following:
> 1. Google Summer of Code 2017 student
> 2. OWASP Code Sprint Winner
> 3.
Greetings,
* DHRUVI VADALIA (dhruvi.vada...@somaiya.edu) wrote:
> I'm a 3rd year Computer Engineer and I'm applying for GSoD.
[...]
> My *experience* in *technical writing* includes *project reports for
> college projects* and technical documentation such as *SRS*, etc. It was
> also one of my d
Greetings,
* Manish Devgan (manish.ns...@gmail.com) wrote:
> This is in context with the previous mail I created dated April 30, 2019 in
> regard to GSoD'19.
I might be missing it, but I don't see a prior email from you, and our
archives only show this email when I search across all lists.
> I a
Greetings,
* Sascha Kuhl (yogidaba...@gmail.com) wrote:
> Can I obtain a document with the organisational structure of this mailing
> list. I would like to foresee what happens with my email.
There is no formal document and we don't have any control over what
happens down-stream of us (there are
rotocol in MaxScale (proxy) and MariaDB Server in recent
> versions.
pgbouncer is already a transparent proxy that understands the PG
protocol, and, even better, it has support for transaction-level pooling
(as well as connection-level), which is really critical for larger PG
deployments
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Tomas Vondra writes:
> > On Sat, May 18, 2019 at 03:45:11PM -0400, Tom Lane wrote:
> >> Tomas Vondra writes:
> >>> But that's not an issue intruduced by PG12, it works like that even for
> >>> the extended statistics introduced in PG10.
>
> >>
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I'm generally in favor of doing something like what Tom is suggesting
> > with VERBOSE, but I also feel like it should be the default for formats
> > like JSON. If you're asking for the
Greetings,
* David Fetter (da...@fetter.org) wrote:
> On Tue, May 07, 2019 at 06:12:56PM -0400, Stephen Frost wrote:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > > One idea that comes to mind is that VERBOSE could be redefined as
> > > some sort of package of primitiv
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Andres Freund writes:
> > As I said, I don't think ALL is a good idea under any name. Like it
> > just makes no sense to have ANALYZE, SUMMARY, VERBOSE, BUFFERS,
> > SETTINGS, FORMAT controlled by one option, unless you call it DWIM. It's
> > s
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Having our test framework deny us useful features just strikes me as
> > bizarre.
>
> This is presuming that it's useful, which is debatable IMO.
> I think most people will find it useless
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, May 7, 2019 at 11:30 AM Stephen Frost wrote:
> > > Not unless you want to break every regression test that uses \d.
> > > Instability of the output is also a reason not to show the
> > > toast t
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Rafia Sabih writes:
> >>> IMHO, what makes more sense is to show the name of associated toast
> >>> table in the \dt+ of the no
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Rafia Sabih writes:
> > On Fri, 3 May 2019 at 16:27, Justin Pryzby wrote:
> >> Thanks - what about also showing the associated non-toast table ?
>
> > IMHO, what makes more sense is to show the name of associated toast
> > table in the \dt+ of
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Mon, May 06, 2019 at 08:32:44AM -0400, Andrew Dunstan wrote:
> > Why do we even have code referring to pre-7.3 servers? Wouldn't it be
> > simpler just to remove that code?
>
> Even for pg_dump, we only support servers down to 8.0. L
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-05-03 23:08:44 -0400, Stephen Frost wrote:
> > As mentioned though, it's likely to be a
> > quite rare thing to run into, so you'd have to be extra unlucky to even
> > hit this case and perhaps the ext
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-05-03 22:41:11 -0400, Stephen Frost wrote:
> > I suppose it is a pretty big change in the base autovacuum launcher to
> > be something that's run per database instead and then deal with the
> > coordination
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-05-03 22:03:18 -0400, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> > > I am not sure exactly how to fix this,
> > > because the calculation we use to determine the XID that ca
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> I don't think we necessarily need a new WAL record for what I'm
> describing above (as XLOG_SMGR_TRUNCATE already carries information
> about which forks are truncated, we could just have it acquire the
> exclusive lock), and I don't think w
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> I am not sure exactly how to fix this,
> because the calculation we use to determine the XID that can be used
> to vacuum a specific table is pretty complex; how can the postmaster
> know whether it's going to be able to make any progress i
Greetings,
* Evangelos Karatarakis (baggeliskap...@gmail.com) wrote:
> I am interested in participating in GSoD 2019 and more specifically I am
> interested in working on the project of impooving the Introductory Tutorial
> for beginners PostgreSQL and in databases. I have a practical and
> theore
Greetings,
* Steve (stev...@osfda.org) wrote:
> As you might know, generating SSL certificates for postgres (to be used by
> pgadmin, for example...) can be quite a bear; especially if you need more
> than one, since they are based on the username of the postgres user.
Well, you can map the commo
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Apr 24, 2019 at 9:28 AM Stephen Frost wrote:
> > At least in part then it seems like we're viewing the level of effort
> > around what I'm talking about quite differently, and I feel like that's
&g
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Apr 22, 2019 at 2:26 PM Stephen Frost wrote:
> > There was basically zero discussion about what things would look like at
> > a protocol level (I went back and skimmed over the thread before sending
>
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On Tue, Apr 23, 2019 at 10:22:46AM -0400, Stephen Frost wrote:
> >* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> >>On Sat, Apr 20, 2019 at 04:21:52PM -0400, Robert Haas wrote:
> >>>On Sat, Ap
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On Sat, Apr 20, 2019 at 04:21:52PM -0400, Robert Haas wrote:
> >On Sat, Apr 20, 2019 at 12:42 AM Stephen Frost wrote:
> >>> Oh. Well, I already explained my algorithm for doing that upthread,
> >>&g
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-04-22 14:26:40 -0400, Stephen Frost wrote:
> > I'm disappointed that the concerns about the trouble that end users are
> > likely to have with this didn't garner more discussion.
>
> My impression is
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Apr 22, 2019 at 1:08 PM Stephen Frost wrote:
> > > One could instead just do a straightforward extension
> > > to the existing BASE_BACKUP command to enable incremental backup.
> >
> > Ok, how do y
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-04-19 20:04:41 -0400, Stephen Frost wrote:
> > I agree that we don't want another implementation and that there's a lot
> > that we want to do to improve replay performance. We've already got
>
Greetings,
* Peter Geoghegan (p...@bowt.ie) wrote:
> On Mon, Apr 22, 2019 at 8:36 AM Stephen Frost wrote:
> > This seems like it would be helpful for global indexes as well, wouldn't
> > it?
>
> Yes, though that should probably work by reusing what we already do
>
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sat, Apr 20, 2019 at 4:32 PM Stephen Frost wrote:
> > Having been around for a while working on backup-related things, if I
> > was to implement the protocol for pg_basebackup today, I'd definitely
> > impl
Greetings,
* Peter Geoghegan (p...@bowt.ie) wrote:
> Andres has suggested that I work on teaching nbtree to accommodate
> variable-width, logical table identifiers, such as those required for
> indirect indexes, or clustered indexes, where secondary indexes must
> use a logical primary key value i
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sat, Apr 20, 2019 at 12:19 AM Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> > > What I'm NOT willing to
> > > do is build a whole bunch of infrastructure that will help pgback
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Apr 19, 2019 at 8:39 PM Stephen Frost wrote:
> > While I do think we should at least be thinking about the load caused
> > from scanning the WAL to generate a list of blocks that are changed, the
> > load I wa
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> What I'm NOT willing to
> do is build a whole bunch of infrastructure that will help pgbackrest
> do amazing things but will not provide a simple and convenient way of
> taking incremental backups using only core tools. I do care about
> h
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Mon, Apr 15, 2019 at 08:24:52AM -0400, Stephen Frost wrote:
> > The tests are really fast enough with one KDC that I don't think it
> > makes sense to have two independent tests.
>
> Perhaps you should add a
edicated background worker would be a good
> option, but Stephen Frost seems concerned (over on the other thread)
> about how much load that would generate. That never really occurred
> to me as a serious issue and I suspect for many people it wouldn't be,
> but there might be s
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> > > Wow. I have to admit that I feel completely opposite of that- I'd
> > > *love* to have an independent tool (which ideally uses the same code
> > > through the common library, or similar) that can be run to apply WAL.
> > >
> > > In othe
Greetings,
Ok, responding to the rest of this email.
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Apr 17, 2019 at 6:43 PM Stephen Frost wrote:
> > Sadly, I haven't got any great ideas today. I do know that the WAL-G
> > folks have specifically mentioned issues wit
Greetings,
I wanted to respond to this point specifically as I feel like it'll
really help clear things up when it comes to the point of view I'm
seeing this from.
* Robert Haas (robertmh...@gmail.com) wrote:
> > Perhaps that's what we're both saying too and just talking past each
> > other, but
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Apr 17, 2019 at 5:20 PM Stephen Frost wrote:
> > As I understand it, the problem is not with backing up an individual
> > database or cluster, but rather dealing with backing up thousands of
> > individual cl
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Apr 15, 2019 at 9:01 AM Stephen Frost wrote:
> > I love the general idea of having additional facilities in core to
> > support block-level incremental backups. I've long been unhappy that
> > any s
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Apr 16, 2019 at 5:44 PM Stephen Frost wrote:
> > > > I love the general idea of having additional facilities in core to
> > > > support block-level incremental backups. I've long been unhappy tha
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Mon, Apr 15, 2019 at 09:01:11AM -0400, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> > > Several companies, including EnterpriseDB, NTT, and Postgres Pro, have
> > > developed technology
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> Several companies, including EnterpriseDB, NTT, and Postgres Pro, have
> developed technology that permits a block-level incremental backup to
> be taken from a PostgreSQL server. I believe the idea in all of those
> cases is that non-rela
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On Tue, Apr 09, 2019 at 02:29:09PM -0400, Robert Haas wrote:
> >On Tue, Apr 9, 2019 at 11:51 AM Alvaro Herrera
> >wrote:
> >>This is not surprising, considering that columnar store is precisely the
> >>reason for starting the work
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 2019-04-09 09:32, Peter Eisentraut wrote:
> > On 2019-04-09 04:51, Stephen Frost wrote:
> >>> Running just 002_enc.pl by itself passes the tests!
> >> Great! I think what I'll do i
Greetings,
* Robbie Harwood (rharw...@redhat.com) wrote:
> Bruce Momjian writes:
> > On Wed, Apr 3, 2019 at 08:49:25AM +0200, Magnus Hagander wrote:
> >> On Wed, Apr 3, 2019 at 12:22 AM Joe Conway wrote:
> >>
> >> Personally I don't find it as confusing as is either, and I find
> >> hostgss to
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 2019-04-05 23:37, Stephen Frost wrote:
> > I wonder if somehow the keytab file that the server is using isn't
> > getting destroyed between the two test runs and so you're ending up with
> >
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 2019-04-05 14:48, Stephen Frost wrote:
> > On a failure to set up an encrypted connection, we'll actually fall back
> > to a non-encrypted one using GSSAPI *just* for authentication, which is>
1201 - 1300 of 1955 matches
Mail list logo
