Re: [HACKERS] [COMMITTERS] pgsql: test_pg_dump TAP test whitespace cleanup

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > > > This will be undone by the next perltidy run. > > > > Ugh. > > > > I certainly hope what was there before wasn

Re: [HACKERS] One-shot expanded output in psql using \G

David, * David G. Johnston (david.g.johns...@gmail.com) wrote: > On Mon, Jan 30, 2017 at 8:35 AM, Stephen Frost wrote: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > > Stephen Frost writes: > > > > This particular bike-shedding really doesn't seem to be terr

Re: [HACKERS] One-shot expanded output in psql using \G

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > This particular bike-shedding really doesn't seem to be terribly useful > > or sensible, to me. \gx isn't "consistent" or "descriptive", frankly. > > Why not? To me it

Re: [HACKERS] Superowners

Simon, * Simon Riggs (si...@2ndquadrant.com) wrote: > On 30 January 2017 at 14:43, Stephen Frost wrote: > > > We need to make sure that we're actually talking about the same things > > here, because we've now shifted from ownership-like privileges to those > &g

Re: [HACKERS] One-shot expanded output in psql using \G

* Pavel Stehule (pavel.steh...@gmail.com) wrote: > 2017-01-30 14:46 GMT+01:00 Stephen Frost : > > > * Christoph Berg (christoph.b...@credativ.de) wrote: > > > Re: Daniel Verite 2017-01-28 <74e7fd23-f5a9-488d-a8c4- > > 1e0da674b...@manitou-mail.org> > > &

Re: [HACKERS] One-shot expanded output in psql using \G

* Christoph Berg (christoph.b...@credativ.de) wrote: > Re: Daniel Verite 2017-01-28 > <74e7fd23-f5a9-488d-a8c4-1e0da674b...@manitou-mail.org> > > > Mysql's CLI client is using \G for this purpose, and adding the very > > > same functionality to psql fits nicely into the set of existing > > > backs

Re: [HACKERS] Superowners

Simon, * Simon Riggs (si...@2ndquadrant.com) wrote: > On 27 January 2017 at 22:48, Peter Eisentraut > wrote: > > On 1/26/17 1:25 PM, Simon Riggs wrote: > >> That should include the ability to dump all objects, yet without any > >> security details. And it should allow someone to setup logical > >

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

* Andres Freund (and...@anarazel.de) wrote: > On 2017-01-28 08:47:03 +0900, Michael Paquier wrote: > > On Sat, Jan 28, 2017 at 8:03 AM, Peter Eisentraut > > wrote: > > > On 1/26/17 2:05 PM, Robert Haas wrote: > > >> I do not think it can be right to rename the directory and not > > >> anything els

Re: [HACKERS] Superowners

Jim, * Jim Nasby (jim.na...@bluetreble.com) wrote: > On 1/29/17 4:44 PM, Stephen Frost wrote: > >* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > >>On 1/26/17 1:25 PM, Simon Riggs wrote: > >>>That should include the ability to dump all objects, yet wit

Re: [HACKERS] Superowners

* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 1/26/17 1:25 PM, Simon Riggs wrote: > > That should include the ability to dump all objects, yet without any > > security details. And it should allow someone to setup logical > > replication easily, including both trigger based and

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Greetings, * Simon Riggs (si...@2ndquadrant.com) wrote: > On 27 January 2017 at 14:09, Dave Page wrote: > > On Fri, Jan 27, 2017 at 1:18 PM, Simon Riggs wrote: > > > >> If the monitoring tool requires superuser then that is a problem, so > >> it would be helpful if it didn't do that, please. Not

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Jan 27, 2017 at 11:34 AM, Stephen Frost wrote: > > * Robert Haas (robertmh...@gmail.com) wrote: > >> OK, fair enough. get_raw_page() is clearly not something that we > >> really want everybody to have acce

Re: [HACKERS] potential hardware donation

Dan, * Dan Langille (d...@langille.org) wrote: > If someone wanted to donate a SuperServer 6028TR-D72R > (http://www.supermicro.com/products/system/2U/6028/SYS-6028TR-D72R.cfm) to > the PostgreSQL project, would it be used? Possibly, but if it's really for PG infrastructure uses, the question s

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Simon Riggs writes: > > [ good general plan ] > > > 3. Make a list of all functions that would cause security problems. > > One by one, precisely. If we did remove all superuser checks we would > > need this list documented to advise people of the risks, s

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > OK, fair enough. get_raw_page() is clearly not something that we > really want everybody to have access to by default, but if it were up > to me, I'd change the permissions check inside the function to do a > check for select privileges on th

Re: [HACKERS] One-shot expanded output in psql using \G

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > > > I think the suggestion is that \G replaces \g (which is the same thing > > > as the semicolon). So you would do this: > >

Re: [HACKERS] One-shot expanded output in psql using \G

* David G. Johnston (david.g.johns...@gmail.com) wrote: > On Fri, Jan 27, 2017 at 8:31 AM, Stephen Frost wrote: > > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > > D'Arcy Cain wrote: > > > > > > > I am a pretty heavy user of p

Re: [HACKERS] One-shot expanded output in psql using \G

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > D'Arcy Cain wrote: > > > I am a pretty heavy user of psql but I don't think that that would be so > > helpful. I assume you mean a new option, let's call it "\X" the causes the > > next query to be expanded. I type "\X" then a query. I realiz

Re: [HACKERS] One-shot expanded output in psql using \G

Christoph, * Christoph Berg (christoph.b...@credativ.de) wrote: > The same idea was discussed back in 2008. Back then the outcome was > that "\x auto" was implemented, but I still think that \G is a useful > feature to have on its own, and several people in the thread seem to > have agreed back th

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

Andres, * Andres Freund (and...@anarazel.de) wrote: > On 2017-01-26 19:01:54 -0500, Stephen Frost wrote: > > * Andres Freund (and...@anarazel.de) wrote: > > > I hear these complaints about postgres most frequently: 1) replication > > > sucks. 2) way too slow on ana

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

Andres, * Andres Freund (and...@anarazel.de) wrote: > I hear these complaints about postgres most frequently: 1) replication > sucks. 2) way too slow on analytics queries. 3) existing admin tools > suck. 4) self written admin tools (required due to 3)) constantly break. > > There's a lot being do

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jan 25, 2017 at 10:31 PM, Stephen Frost wrote: > > Frankly, I get quite tired of the argument essentially being made here > > that because pg_ls_dir() wouldn't grant someone superuser rights, that > >

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

* Robert Haas (robertmh...@gmail.com) wrote: > And I think that's all pretty reasonable. I don't consider this a > done deal yet. I don't consider your -1 irrelevant. But I don't > think it's fair to present this as if I am somehow running roughshod > over community process, either. If a large

Re: [HACKERS] Allow interrupts on waiting standby

* Andres Freund (and...@anarazel.de) wrote: > On 2017-01-26 19:36:11 +, Simon Riggs wrote: > > Tomorrow is too late. > > Huh? We're not wrapping today/tomorrow, are we? If I missed something > and we are, then sure, it makes sense to push ahead. I haven't seen anyone suggest that we're chang

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

* Andres Freund (and...@anarazel.de) wrote: > On 2017-01-24 16:47:29 -0500, Robert Haas wrote: > > I'm happy to go change every last bit of it. > > I quite regret not aggressively opining against the renaming of pg_xlog > to pg_wal. I think the few users deleting their data don't weigh against > r

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Robert Haas writes: > > On Thu, Jan 26, 2017 at 12:27 PM, Alvaro Herrera > > wrote: > >> There have been complaints that pg_receivexlog's name is not consistent > >> with pg_recvlogical, and I seem to recall there were some votes for > >> renaming pg_recei

Re: [HACKERS] Checksums by default?

* Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jan 25, 2017 at 7:37 PM, Andres Freund wrote: > > On 2017-01-25 19:30:08 -0500, Stephen Frost wrote: > >> * Peter Geoghegan (p...@heroku.com) wrote: > >> > On Wed, Jan 25, 2017 at 3:30 PM, Stephen Frost &

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > Your proposed policy is essentially that functions should have > built-in superuser checks if having access to that function is > sufficient to escalate your account to full superuser privileges. Yes, I do. > 1. There's no consensus on any s

Re: [HACKERS] pgbench more operators & functions

Fabien, * Fabien COELHO (coe...@cri.ensmp.fr) wrote: > I think that there is a misunderstanding, most of which being my fault. No worries, it happens. :) > I have really tried to do everything that was required from > committers, including revising the patch to match all previous > feedback. Th

Re: [HACKERS] Checksums by default?

Peter, * Peter Geoghegan (p...@heroku.com) wrote: > On Wed, Jan 25, 2017 at 1:22 PM, Peter Geoghegan wrote: > > I understand that my experience with storage devices is unusually > > narrow compared to everyone else here. That's why I remain neutral on > > the high level question of whether or not

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Andres, * Andres Freund (and...@anarazel.de) wrote: > On 2017-01-25 18:04:09 -0500, Stephen Frost wrote: > > Robert's made it clear that he'd like to have a blanket rule that we > > don't have superuser checks in these code paths if they can be GRANT'd > >

Re: [HACKERS] Checksums by default?

* Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jan 25, 2017 at 6:30 PM, Stephen Frost wrote: > > I hope to discuss it further after we have the ability to turn it off > > easily. > > I think we should have the ability to flip it in BOTH directions easily. Presuma

Re: [HACKERS] Checksums by default?

Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: > That would be enough. It should also be rare enough that there would > not be that many pages to track when looking at records from the > backup start position to minimum recovery point. It could be also > simpler, though more time-co

Re: [HACKERS] Checksums by default?

* Andres Freund (and...@anarazel.de) wrote: > On 2017-01-25 19:30:08 -0500, Stephen Frost wrote: > > * Peter Geoghegan (p...@heroku.com) wrote: > > > On Wed, Jan 25, 2017 at 3:30 PM, Stephen Frost wrote: > > > > As it is, there are backup solutions whic

Re: [HACKERS] Checksums by default?

* Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jan 25, 2017 at 7:19 PM, Michael Paquier > wrote: > > On Thu, Jan 26, 2017 at 9:14 AM, Peter Geoghegan wrote: > >> On Wed, Jan 25, 2017 at 3:30 PM, Stephen Frost wrote: > >>> As it is, there are back

Re: [HACKERS] Checksums by default?

* Michael Paquier (michael.paqu...@gmail.com) wrote: > On Thu, Jan 26, 2017 at 9:14 AM, Peter Geoghegan wrote: > > On Wed, Jan 25, 2017 at 3:30 PM, Stephen Frost wrote: > >> As it is, there are backup solutions which *do* check the checksum when > >> backing up PG. Th

Re: [HACKERS] Checksums by default?

* Peter Geoghegan (p...@heroku.com) wrote: > On Wed, Jan 25, 2017 at 3:30 PM, Stephen Frost wrote: > > As it is, there are backup solutions which *do* check the checksum when > > backing up PG. This is no longer, thankfully, some hypothetical thing, > > but something which r

Re: [HACKERS] Checksums by default?

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jan 25, 2017 at 2:23 PM, Stephen Frost wrote: > > Yet, our default is to have them disabled and *really* hard to enable. > > First of all, that could be fixed by further development. I'm certainly all for d

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Andres, * Andres Freund (and...@anarazel.de) wrote: > On 2017-01-25 16:52:38 -0500, Stephen Frost wrote: > > * Robert Haas (robertmh...@gmail.com) wrote: > > > Preventing people from calling functions by denying the ability to > > > meaningfully GRANT EXECUTE on those

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jan 25, 2017 at 3:17 PM, Stephen Frost wrote: > > Your email is 'pg_ls_dir & friends', which I took to imply at *least* > > pg_read_file() and pg_read_binary_file(), and it's not unreasonab

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jan 25, 2017 at 2:08 PM, Stephen Frost wrote: > > That isn't what you're doing with those functions though, you're giving > > the monitoring tool superuser-level rights but trying to pretend like &

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jan 25, 2017 at 2:13 PM, Stephen Frost wrote: > > I went over *every* superuser check in the system when I did that work, > > wrote up a long email about why I made the decisions that I did, posted > > i

Re: [HACKERS] Checksums by default?

* Peter Geoghegan (p...@heroku.com) wrote: > On Wed, Jan 25, 2017 at 10:18 AM, Robert Haas wrote: > > Trying to force those people to use checksums is just masterminding; > > they've made their own decision that it's not worth bothering with. > > When something goes wrong, WE still care about dist

Re: [HACKERS] Checksums by default?

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jan 25, 2017 at 12:02 AM, Jim Nasby wrote: > > I'm not completely grokking your second paragraph, but I would think that an > > average user would love got get a heads-up that their hardware is failing. > > Sure. If the database run

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > Also, the same argument could be made about removing the built-in > superuser check from ANY function, and we've already rejected that > argument for a bunch of other functions. If we say that argument is > valid for some functions but not ot

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Greg, * Greg Stark (st...@mit.edu) wrote: > I tend to agree. But in the past when this came up people pointed out > you could equally do things this way and still grant all the access > you wanted using SECURITY DEFINER. Arguably that's a better approach > because then instead of auditing the enti

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > The use case I have in mind is > a monitoring tool that needs access to one more of those functions -- > in keeping with the principle of least privilege, it's much better to > give the monitoring user only the privileges which it actually nee

[HACKERS] \h tab-completion

All, I'm not really inclined to do it myself right now, but it'd be awful nice if we had better table completion for \h. Right now, '\h alter' returns nothing, and '\h alter' returns a *bunch* of stuff. Yet, we happily support '\h alter view' and friends, returning just the info relevant for tha

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

* Vladimir Rusinov (vrusi...@google.com) wrote: > On Mon, Jan 23, 2017 at 6:59 PM, Stephen Frost wrote: > > I don't have any problem with asking for a summary of the exact set of > > changes that he's planning to make though. My understanding is that it > >

Re: [HACKERS] [COMMITTERS] pgsql: Add pg_sequence system catalog

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 1/19/17 11:03 AM, Stephen Frost wrote: > > I'd suggest using our usual approach in pg_dump, which is matching based > > on the OID, like so: > > > > WHERE c.oid = '%u'::oid >

Re: [HACKERS] Superowners

Simon, * Simon Riggs (si...@2ndquadrant.com) wrote: > So I was thinking about various annoying admin/security issues > recently, so I came up with this: a new type of user called a > “superowner”. It’s somewhere between a superuser and a normal user. I like the general idea, but I'm not really

Re: [HACKERS] Checksums by default?

Greetings, * Ants Aasma (ants.aa...@eesti.ee) wrote: > On Tue, Jan 24, 2017 at 4:07 AM, Tom Lane wrote: > > Peter Geoghegan writes: > >> I thought that checksums went in in part because we thought that there > >> was some chance that they'd find bugs in Postgres. > > > > Not really. AFAICS the

Re: [HACKERS] Checksums by default?

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Jim Nasby writes: > > On 1/23/17 7:47 PM, Stephen Frost wrote: > >> It might be interesting to consider checking them in 'clean' pages in > >> shared_buffers in a background process, as that, presumably, *would*

Re: [HACKERS] Checksums by default?

* Peter Geoghegan (p...@heroku.com) wrote: > On Mon, Jan 23, 2017 at 5:26 PM, Stephen Frost wrote: > > Not sure how this part of that sentence was missed: > > > > - > > ... even though they were enabled as soon as the feature became > > available. > >

Re: [HACKERS] Checksums by default?

Jim, * Jim Nasby (jim.na...@bluetreble.com) wrote: > On 1/23/17 6:55 PM, Stephen Frost wrote: > >* Jim Nasby (jim.na...@bluetreble.com) wrote: > >>As others have mentioned, right now practically no one enables this, > >>so we've got zero data on how useful it mi

Re: [HACKERS] Checksums by default?

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Jim Nasby (jim.na...@bluetreble.com) wrote: > >> As others have mentioned, right now practically no one enables this, > >> so we've got zero data on how useful it might actually be. > >

Re: [HACKERS] Checksums by default?

Jim, * Jim Nasby (jim.na...@bluetreble.com) wrote: > As others have mentioned, right now practically no one enables this, > so we've got zero data on how useful it might actually be. Uhm, Peter G just said that Heroku enables this on all their databases and have yet to see a false-positive report

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 1/17/17 5:03 PM, Robert Haas wrote: > > Right. I think a lot of that stuff should also be changed. If we > > weren't OK with breaking compatibility, why'd we change pg_xlog -> > > pg_wal? If we're not willing to change oth

Re: [HACKERS] [COMMITTERS] pgsql: Add pg_sequence system catalog

Peter, all, * Stephen Frost (sfr...@snowman.net) wrote: > * Peter Eisentraut (pete...@gmx.net) wrote: > > Add pg_sequence system catalog > > The query this added to dumpSequence() seems to think that sequence > names are unique across databases: Just FYI, I've added this

Re: [HACKERS] GSoC 2017

All, * Alexander Korotkov (a.korot...@postgrespro.ru) wrote: > Also, we need to decide who would > be our admin this year. I don't see anyone jumping at the bit to be the admin (it's not exactly a fun and exciting job, after all), so, unless someone really wants it (or someone wishs to object), I

Re: [HACKERS] Failure in commit_ts tap tests

Tom, Andrew, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Andrew Dunstan writes: > > On 01/20/2017 01:22 PM, Tom Lane wrote: > >> It looks like at least part of the answer is that the buildfarm isn't > >> running this test. AFAICS, it runs "make installcheck" not > >> "make check" in src/test/module

Re: [HACKERS] Commit fest 2017-01 will begin soon!

Michael, all, * Michael Paquier (michael.paqu...@gmail.com) wrote: > There is one week left for this commit fest, and now is the time to > push for things that have a chance to get in. As of now, there is a > total of 25 patches waiting for some love from a committer. Many thanks for your work as

Re: [HACKERS] new autovacuum criterion for visible pages

Amit, * Amit Kapila (amit.kapil...@gmail.com) wrote: > On Sun, Jan 22, 2017 at 3:27 AM, Stephen Frost wrote: > > * Simon Riggs (si...@2ndquadrant.com) wrote: > >> On 12 August 2016 at 01:01, Tom Lane wrote: > >> > Michael Paquier writes: > >> >> In

Re: [HACKERS] Checksums by default?

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Not at all; I just think that it's not clear that they are a net win > for the average user, and so I'm unconvinced that turning them on by > default is a good idea. I could be convinced otherwise by suitable > evidence. What I'm objecting to is turn

Re: [HACKERS] Checksums by default?

Thomas, * Thomas Munro (thomas.mu...@enterprisedb.com) wrote: > On Sun, Jan 22, 2017 at 7:37 AM, Stephen Frost wrote: > > Exactly, and that awareness will allow a user to prevent further data > > loss or corruption. Slow corruption over time is a very much known and > > acc

Re: [HACKERS] new autovacuum criterion for visible pages

All, * Simon Riggs (si...@2ndquadrant.com) wrote: > On 12 August 2016 at 01:01, Tom Lane wrote: > > Michael Paquier writes: > >> In short, autovacuum will need to scan by itself the VM of each > >> relation and decide based on that. > > > > That seems like a worthwhile approach to pursue. The V

Re: [HACKERS] Checksums by default?

* Ants Aasma (ants.aa...@eesti.ee) wrote: > On Sat, Jan 21, 2017 at 7:39 PM, Petr Jelinek > wrote: > > So in summary "postgresql.conf options are easy to change" while "initdb > > options are hard to change", I can see this argument used both for > > enabling or disabling checksums by default. As

Re: [HACKERS] Checksums by default?

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Andres Freund writes: > > Sure, it might be easy, but we don't have it. Personally I think > > checksums just aren't even ready for prime time. If we had: > > - ability to switch on/off at runtime (early patches for that have IIRC > > been posted) > > -

Re: [HACKERS] Checksums by default?

* Andres Freund (and...@anarazel.de) wrote: > On 2017-01-21 13:03:52 -0500, Stephen Frost wrote: > > * Andres Freund (and...@anarazel.de) wrote: > > > On 2017-01-21 12:46:05 -0500, Stephen Frost wrote: > > > > Do you run with all defaults in those environments? >

Re: [HACKERS] Checksums by default?

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > Because I see having checksums as, frankly, something we always should > > have had (as most other databases do, for good reason...) and because > > they will hopefully prevent data loss. I'm willing to

Re: [HACKERS] Checksums by default?

.de) wrote: > On 2017-01-21 12:46:05 -0500, Stephen Frost wrote: > > Do you run with all defaults in those environments? > > Irrelevant - changing requires re-initdb'ing. That's unrealistic. I disagree. Further, we can add an option to be able to disable checksums with

Re: [HACKERS] Checksums by default?

* Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote: > As we don't know the performance impact is (there was no benchmark done > on reasonably current code base) I really don't understand how you can > judge if it's worth it or not. Because I see having checksums as, frankly, something we always s

Re: [HACKERS] Checksums by default?

* Andres Freund (and...@anarazel.de) wrote: > On 2017-01-21 12:09:53 -0500, Tom Lane wrote: > > Also, if we do decide to do that, there's the question of timing. > > As I mentioned, one of the chief risks I see is the possibility of > > false-positive checksum failures due to bugs; I think that cod

Re: [HACKERS] Checksums by default?

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > As for checksums, I do see value in them and I'm pretty sure that the > > author of that particular feature did as well, or we wouldn't even have > > it as an option. You seem to be of the opinion

Re: [HACKERS] Checksums by default?

* Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote: > On 21/01/17 17:51, Stephen Frost wrote: > > I'm quite sure that the performance numbers for the CREATE TABLE + COPY > > case with wal_level=minimal would have been *far* better than for > > wal_level > minimal.

Re: [HACKERS] Checksums by default?

* Andreas Karlsson (andr...@proxel.se) wrote: > On 01/21/2017 04:48 PM, Stephen Frost wrote: > >* Fujii Masao (masao.fu...@gmail.com) wrote: > >>If the performance overhead by the checksums is really negligible, > >>we may be able to get rid of wal_log_hints param

Re: [HACKERS] Checksums by default?

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote: > >> The change of wal_level was supported by benchmark, I think it's > >> reasonable to ask for this to be as well. > > > No, it

Re: [HACKERS] Checksums by default?

* Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote: > On 21/01/17 17:31, Stephen Frost wrote: > > This is just changing the *default*, not requiring checksums to always > > be enabled. We do not hold the same standards for our defaults as we do > > for always-enabled code, f

Re: [HACKERS] Checksums by default?

Petr, * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote: > On 21/01/17 16:40, Stephen Frost wrote: > > * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote: > >> On 21/01/17 11:39, Magnus Hagander wrote: > >>> Is it time to enable checksums by default, and give in

Re: [HACKERS] Checksums by default?

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Magnus Hagander writes: > > Is it time to enable checksums by default, and give initdb a switch to turn > > it off instead? > > Have we seen *even one* report of checksums catching problems in a useful > way? This isn't the right question. The right ques

Re: [HACKERS] Checksums by default?

* Fujii Masao (masao.fu...@gmail.com) wrote: > On Sun, Jan 22, 2017 at 12:18 AM, Petr Jelinek > wrote: > > On 21/01/17 11:39, Magnus Hagander wrote: > >> Is it time to enable checksums by default, and give initdb a switch to > >> turn it off instead? > > > > I'd like to see benchmark first, both i

Re: [HACKERS] Checksums by default?

Petr, * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote: > On 21/01/17 11:39, Magnus Hagander wrote: > > Is it time to enable checksums by default, and give initdb a switch to > > turn it off instead? > > I'd like to see benchmark first, both in terms of CPU and in terms of > produced WAL (=net

Re: [HACKERS] Checksums by default?

Magnus, * Magnus Hagander (mag...@hagander.net) wrote: > On Sat, Jan 21, 2017 at 3:05 PM, Michael Paquier > wrote: > > > On Sat, Jan 21, 2017 at 7:39 PM, Magnus Hagander > > wrote: > > > Is it time to enable checksums by default, and give initdb a switch to > > turn > > > it off instead? > > >

Re: [HACKERS] Checksums by default?

* Michael Paquier (michael.paqu...@gmail.com) wrote: > On Sat, Jan 21, 2017 at 7:39 PM, Magnus Hagander wrote: > > Is it time to enable checksums by default, and give initdb a switch to turn > > it off instead? > > > > I keep running into situations where people haven't enabled it, because (a) > >

Re: [HACKERS] Checksums by default?

* Magnus Hagander (mag...@hagander.net) wrote: > Is it time to enable checksums by default, and give initdb a switch to turn > it off instead? Yes, please. We've already agreed to make changes to have a better user experience and ask those who really care about certain performance aspects to have

Re: [HACKERS] Valgrind-detected bug in partitioning code

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Robert Haas writes: > > Hmm. That's bad. I kind of wonder how sane it is to think that we > > can invoke SQL-callable functions during a relcache reload, because > > couldn't we be processing an invalidation in the context of an aborted > > transaction? >

[HACKERS] SearchSysCache, SysCacheGetAttr, and heap_getattr()

Greetings, There's some inconsistency when it comes to if we actually use SysCacheGetAttr() when pulling an attribute for a tuple we got via SearchSysCache(), or if we use heap_getattr(). Maybe I'm missing something, but that seems less than ideal. I've generally been under the belief that using

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

* Andres Freund (and...@anarazel.de) wrote: > On 2017-01-19 20:45:57 -0500, Stephen Frost wrote: > > * Andres Freund (and...@anarazel.de) wrote: > > > On 2017-01-19 10:06:09 -0500, Stephen Frost wrote: > > > > WAL replay does do more work, generally speaking (the W

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

* Andres Freund (and...@anarazel.de) wrote: > On 2017-01-19 10:06:09 -0500, Stephen Frost wrote: > > WAL replay does do more work, generally speaking (the WAL has to be > > read, the checksum validated on it, and then the write has to go out, > > while the checkpointer jus

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

* Michael Paquier (michael.paqu...@gmail.com) wrote: > On Fri, Jan 20, 2017 at 12:06 AM, Stephen Frost wrote: > > We did make the WAL checksum routines a lot > > faster with 9.6, as I recall, so perhaps there's been some change there > > too. > > 9.5, commit 5028

Re: [HACKERS] [COMMITTERS] pgsql: Add pg_sequence system catalog

Peter, * Peter Eisentraut (pete...@gmx.net) wrote: > Add pg_sequence system catalog The query this added to dumpSequence() seems to think that sequence names are unique across databases: appendPQExpBuffer(query, "SELECT seqstart, seqincrement, " "CASE WHEN seq

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 1/19/17 9:53 AM, Stephen Frost wrote: > > Sure, but we're talking about replaying WAL vs. doing a checkpoint, not > > about writing WAL vs. replaying WAL. Replaying WAL and doing a > > checkpoint both

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 1/18/17 3:12 PM, Stephen Frost wrote: > > I don't understand what I'm missing when it comes to checkpoint_timeout > > and the time required to recover from a crash. You aren't the fir

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 1/18/17 3:47 PM, Robert Haas wrote: > > Anybody who has got a script that runs pg_ctl unattended mode likely > > now has to go update that script to add --no-wait. > > The state of init scripts and other start scripts out there is s

Re: [HACKERS] [PATCH] ALTER DEFAULT PRIVILEGES with GRANT/REVOKE ON SCHEMAS

* Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote: > On 10/01/17 17:33, Matheus de Oliveira wrote: > > > > On Mon, Jan 9, 2017 at 10:58 AM, Ashutosh Sharma > > wrote: > > > > > Also, should I add translations for that error message in other > > languages (I >

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

* Michael Paquier (michael.paqu...@gmail.com) wrote: > On Thu, Jan 19, 2017 at 5:01 AM, Peter Eisentraut > wrote: > > On 1/18/17 8:25 AM, Stephen Frost wrote: > >> I was actually thinking about it the other way- start out by changing > >> them to both b

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

* Michael Paquier (michael.paqu...@gmail.com) wrote: > On Thu, Jan 19, 2017 at 6:20 AM, Stephen Frost wrote: > > On Wed, Jan 18, 2017 at 16:15 Robert Haas wrote: > >> On Wed, Jan 18, 2017 at 3:59 PM, Stephen Frost wrote: > >> > For non-cold standby configurations,

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

On Wed, Jan 18, 2017 at 16:15 Robert Haas wrote: > On Wed, Jan 18, 2017 at 3:59 PM, Stephen Frost wrote: > > > For non-cold standby configurations, pg_ctl is going to return just as > > > soon as the database has finished crash recovery, which in most cases > > >

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jan 18, 2017 at 3:43 PM, Stephen Frost wrote: > > * Robert Haas (robertmh...@gmail.com) wrote: > >> I think we've changed the defaults to make things better for an > >> attended startup and worse f

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Jan 17, 2017 at 5:31 PM, Stephen Frost wrote: > > If I'm understanding your concern correctly, you're worried about the > > case of a cold standby where the database is only replaying WAL but not > >

<    1   2   3   4   5   6   7   8   9   10   >