On Fri, Mar 17, 2017 at 11:03 PM, Michael Paquier
wrote:
> On Fri, Mar 17, 2017 at 10:58 PM, Robert Haas wrote:
>> Fine! I've committed the pg_clog renaming, but I'd really like to
>> draw the line here. I'm not going to commit the pg_subtrans ->
>> pg_subxact naming and am -1 on anyone else do
On Thu, Mar 16, 2017 at 10:21 PM, Michael Paquier
wrote:
> On Fri, Mar 17, 2017 at 11:17 AM, Robert Haas wrote:
>> I understand that the point of renaming pg_clog to pg_xact is that
>> pg_clog contains the dreaded letters l-o-g, which we hypothesize
>> causes DBAs to remove it. (Alternate hypoth
On Fri, Mar 17, 2017 at 10:58 PM, Robert Haas wrote:
> Fine! I've committed the pg_clog renaming, but I'd really like to
> draw the line here. I'm not going to commit the pg_subtrans ->
> pg_subxact naming and am -1 on anyone else doing so. I think that
> having the names of things in the code
On Fri, Mar 17, 2017 at 11:17 AM, Robert Haas wrote:
> I understand that the point of renaming pg_clog to pg_xact is that
> pg_clog contains the dreaded letters l-o-g, which we hypothesize
> causes DBAs to remove it. (Alternate hypothesis: "So, that's what's
> clogging my database!")
>
> Renaming
On Thu, Mar 16, 2017 at 9:31 PM, Michael Paquier
wrote:
> On Fri, Mar 17, 2017 at 12:19 AM, David Steele wrote:
>> This patch does not apply cleanly at cccbdde:
>>
>> $ git apply ../other/0001-Rename-pg_clog-to-pg_xact.patch
>> error: doc/src/sgml/ref/pg_resetxlog.sgml: No such file or directory
On Fri, Mar 17, 2017 at 12:19 AM, David Steele wrote:
> This patch does not apply cleanly at cccbdde:
>
> $ git apply ../other/0001-Rename-pg_clog-to-pg_xact.patch
> error: doc/src/sgml/ref/pg_resetxlog.sgml: No such file or directory
> error: patch failed: src/backend/postmaster/autovacuum.c:2468
On 1/17/17 2:31 AM, Michael Paquier wrote:
> On Tue, Nov 29, 2016 at 1:35 PM, Michael Paquier
> wrote:
>> On Tue, Nov 22, 2016 at 8:35 PM, Haribabu Kommi
>> wrote:
>>> Hi Craig,
>>>
>>> This is a gentle reminder.
>>>
>>> you assigned as reviewer to the current patch in the 11-2016 commitfest.
>>>
On Tue, Jan 17, 2017 at 4:31 PM, Michael Paquier
wrote:
> On Tue, Nov 29, 2016 at 1:35 PM, Michael Paquier
> wrote:
>> On Tue, Nov 22, 2016 at 8:35 PM, Haribabu Kommi
>> wrote:
>>> Hi Craig,
>>>
>>> This is a gentle reminder.
>>>
>>> you assigned as reviewer to the current patch in the 11-2016 c
On Tue, Nov 29, 2016 at 1:35 PM, Michael Paquier
wrote:
> On Tue, Nov 22, 2016 at 8:35 PM, Haribabu Kommi
> wrote:
>> Hi Craig,
>>
>> This is a gentle reminder.
>>
>> you assigned as reviewer to the current patch in the 11-2016 commitfest.
>> But you haven't shared your review yet. Please share y
On Tue, Nov 22, 2016 at 8:35 PM, Haribabu Kommi
wrote:
> Hi Craig,
>
> This is a gentle reminder.
>
> you assigned as reviewer to the current patch in the 11-2016 commitfest.
> But you haven't shared your review yet. Please share your review about
> the patch. This will help us in smoother operati
Hi Craig,
This is a gentle reminder.
you assigned as reviewer to the current patch in the 11-2016 commitfest.
But you haven't shared your review yet. Please share your review about
the patch. This will help us in smoother operation of commitfest.
Please Ignore if you already shared your review.
Bruce Momjian wrote:
> On Mon, Oct 24, 2016 at 11:59:42AM -0300, Alvaro Herrera wrote:
> > There is one difference though, which is that the really destructive
> > use of pg_resetxlog is the one that removes pg_xlog files. The other
> > uses that simply set flags in the control file are not as ba
On Mon, Oct 24, 2016 at 11:59:42AM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Sat, Oct 22, 2016 at 11:18:28PM +0300, Greg Stark wrote:
>
> > > I think the apt-get behaviour was specifically designed to ensure it
> > > couldn't easily be put into a script which I would have said was
Bruce Momjian wrote:
> On Sat, Oct 22, 2016 at 11:18:28PM +0300, Greg Stark wrote:
> > I think the apt-get behaviour was specifically designed to ensure it
> > couldn't easily be put into a script which I would have said was
> > desirable -- except I suspect there are situations where Postgres
> >
On Sat, Oct 22, 2016 at 11:18:28PM +0300, Greg Stark wrote:
> On Fri, Oct 21, 2016 at 9:03 PM, Stephen Frost wrote:
> > WARNING: The following essential packages will be removed.
> > This should NOT be done unless you know exactly what you are doing!
> > login
> > 0 upgraded, 0 newly installed,
On Sun, Oct 23, 2016 at 5:18 PM, Vik Fearing wrote:
> On 10/22/2016 06:00 PM, David Steele wrote:
>> On 10/22/16 6:58 PM, Bruce Momjian wrote:
>>> On Sat, Oct 22, 2016 at 07:33:56AM +0900, Michael Paquier wrote:
On Sat, Oct 22, 2016 at 4:29 AM, Alvaro Herrera
> Also +1 to renaming pg
On 10/22/2016 06:00 PM, David Steele wrote:
> On 10/22/16 6:58 PM, Bruce Momjian wrote:
>> On Sat, Oct 22, 2016 at 07:33:56AM +0900, Michael Paquier wrote:
>>> On Sat, Oct 22, 2016 at 4:29 AM, Alvaro Herrera
>>>
Also +1 to renaming pg_subtrans to pg_subxact.
>>>
>>> Nice suggestion, good namin
On Fri, Oct 21, 2016 at 9:03 PM, Stephen Frost wrote:
> WARNING: The following essential packages will be removed.
> This should NOT be done unless you know exactly what you are doing!
> login
> 0 upgraded, 0 newly installed, 1 to remove and 71 not upgraded.
> After this operation, 1,212 kB disk
On 10/22/16 6:58 PM, Bruce Momjian wrote:
On Sat, Oct 22, 2016 at 07:33:56AM +0900, Michael Paquier wrote:
On Sat, Oct 22, 2016 at 4:29 AM, Alvaro Herrera
Also +1 to renaming pg_subtrans to pg_subxact.
Nice suggestion, good naming for consistency with the rest.
Agreed.
+1
--
-David
da..
On Sat, Oct 22, 2016 at 07:33:56AM +0900, Michael Paquier wrote:
> On Sat, Oct 22, 2016 at 4:29 AM, Alvaro Herrera
> wrote:
> > David Steele wrote:
> >> On 10/21/16 3:12 AM, David G. Johnston wrote:
> >>
> >> > I have no problem continuing keeping with historical precedent and
> >> > allowing mnem
On Sat, Oct 22, 2016 at 4:29 AM, Alvaro Herrera
wrote:
> David Steele wrote:
>> On 10/21/16 3:12 AM, David G. Johnston wrote:
>>
>> > I have no problem continuing keeping with historical precedent and
>> > allowing mnemonic abbreviations in our directory and file names at this
>> > point.
>>
>> I'
David Steele wrote:
> On 10/21/16 3:12 AM, David G. Johnston wrote:
>
> > I have no problem continuing keeping with historical precedent and
> > allowing mnemonic abbreviations in our directory and file names at this
> > point.
>
> I'm still in favor of pg_xact. A search of the 9.6 docs brings
* Robert Haas (robertmh...@gmail.com) wrote:
> I don't think that the problem is that people are accidentally typing
> "pg_resetxlog $PGDATA" and pressing return. They're typing that on
> purpose, and if you change the sequence of characters required to get
> that effect, they'll just type the new
On Fri, Oct 21, 2016 at 9:47 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Thu, Oct 20, 2016 at 12:12 PM, Stephen Frost wrote:
>> > That said, I'd also like to see a --force or similar option or mechanism
>> > put in place to reduce the risk of users trashing their
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Oct 20, 2016 at 12:12 PM, Stephen Frost wrote:
> > That said, I'd also like to see a --force or similar option or mechanism
> > put in place to reduce the risk of users trashing their system because
> > they think pg_resetwal is "safe." ("It's
On 10/21/16 3:12 AM, David G. Johnston wrote:
I have no problem continuing keeping with historical precedent and
allowing mnemonic abbreviations in our directory and file names at this
point.
I'm still in favor of pg_xact. A search of the 9.6 docs brings up a
number of hits for "xact": pg_l
On Thu, Oct 20, 2016 at 6:03 PM, Robert Haas wrote:
> On Thu, Oct 20, 2016 at 3:46 PM, Tom Lane wrote:
> > I'm mostly with Stephen on this. As the names stand, they encourage
> > people to go look at the documentation,
> > https://www.postgresql.org/docs/devel/static/storage-file-layout.html
>
On Fri, Oct 21, 2016 at 10:03 AM, Robert Haas wrote:
> On Thu, Oct 20, 2016 at 3:46 PM, Tom Lane wrote:
>> I'm mostly with Stephen on this. As the names stand, they encourage
>> people to go look at the documentation,
>> https://www.postgresql.org/docs/devel/static/storage-file-layout.html
>> wh
On Thu, Oct 20, 2016 at 3:46 PM, Tom Lane wrote:
> I'm mostly with Stephen on this. As the names stand, they encourage
> people to go look at the documentation,
> https://www.postgresql.org/docs/devel/static/storage-file-layout.html
> which will provide more information than you'd ever get out of
On Fri, Oct 21, 2016 at 12:35 AM, Robert Haas wrote:
> On Wed, Oct 12, 2016 at 10:22 PM, Michael Paquier
> wrote:
>> OK. I can live with that as well. Attached are three patches. The
>> pg_xlog -> pg_wal move, the pg_clog -> pg_transaction move, and the
>> pg_clog -> pg_xact move. Only one surviv
Stephen Frost writes:
> * David Fetter (da...@fetter.org) wrote:
>> On Thu, Oct 20, 2016 at 02:23:32PM -0400, Tom Lane wrote:
>>> I don't see one single one of those subdirectory names that I'd call
>>> self-documenting.
>> That's a problem we should do something about, even if we can't do it
>>
* David Fetter (da...@fetter.org) wrote:
> On Thu, Oct 20, 2016 at 02:23:32PM -0400, Tom Lane wrote:
> > Robert Haas writes:
> > > On Thu, Oct 20, 2016 at 2:09 PM, Tom Lane wrote:
> > >> We have the two precedents "pg_subtrans" and "pg_multixact", so
> > >> unless we want to get into renaming tho
On Thu, Oct 20, 2016 at 02:23:32PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Oct 20, 2016 at 2:09 PM, Tom Lane wrote:
> >> We have the two precedents "pg_subtrans" and "pg_multixact", so
> >> unless we want to get into renaming those too, I think "pg_trans"
> >> and "pg_xact" are r
On Thu, Oct 20, 2016 at 2:23 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Oct 20, 2016 at 2:09 PM, Tom Lane wrote:
>>> We have the two precedents "pg_subtrans" and "pg_multixact", so
>>> unless we want to get into renaming those too, I think "pg_trans"
>>> and "pg_xact" are really the on
On Thu, Oct 20, 2016 at 02:02:27PM -0400, Robert Haas wrote:
> On Thu, Oct 20, 2016 at 1:39 PM, Bruce Momjian wrote:
> > On Thu, Oct 20, 2016 at 12:29:47PM -0400, Robert Haas wrote:
> >> > When it comes to the name, I tend to think of 'pg_xact' as saying "this
> >> > is where we persist info we ne
Robert Haas writes:
> On Thu, Oct 20, 2016 at 2:09 PM, Tom Lane wrote:
>> We have the two precedents "pg_subtrans" and "pg_multixact", so
>> unless we want to get into renaming those too, I think "pg_trans"
>> and "pg_xact" are really the only options worth considering.
>>
>> Personally I'd go f
On Thu, Oct 20, 2016 at 2:09 PM, Tom Lane wrote:
> Robert Haas writes:
>> Is pg_xact actually better than pg_clog?
>
> Yes, because it doesn't contain the three letters "log".
I figured somebody was going to say that.
> We have the two precedents "pg_subtrans" and "pg_multixact", so
> unless we
Robert Haas writes:
> Is pg_xact actually better than pg_clog?
Yes, because it doesn't contain the three letters "log".
We have the two precedents "pg_subtrans" and "pg_multixact", so
unless we want to get into renaming those too, I think "pg_trans"
and "pg_xact" are really the only options wort
On Thu, Oct 20, 2016 at 1:39 PM, Bruce Momjian wrote:
> On Thu, Oct 20, 2016 at 12:29:47PM -0400, Robert Haas wrote:
>> > When it comes to the name, I tend to think of 'pg_xact' as saying "this
>> > is where we persist info we need to keep about transactions." Today
>> > that's just the commit st
On Thu, Oct 20, 2016 at 12:29:47PM -0400, Robert Haas wrote:
> > When it comes to the name, I tend to think of 'pg_xact' as saying "this
> > is where we persist info we need to keep about transactions." Today
> > that's just the commit status info, but I could imagine that there
> > might, someday
On Thu, Oct 20, 2016 at 12:12 PM, Stephen Frost wrote:
> That said, I'd also like to see a --force or similar option or mechanism
> put in place to reduce the risk of users trashing their system because
> they think pg_resetwal is "safe." ("It's just gonna reset things to make
> the database start
On Thu, Oct 20, 2016 at 12:05 PM, Stephen Frost wrote:
>> To be honest, I don't really like either pg_transaction or pg_xact.
>
>> Neither name captures the fact that what we're really tracking here is
>> the transaction *status*. pg_xact is slightly worse because it's a
>> poor abbreviation for
On 10/20/2016 09:12 AM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Robert Haas writes:
That said, I'd also like to see a --force or similar option or mechanism
put in place to reduce the risk of users trashing their system because
they think pg_resetwal is "safe." ("It's jus
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > One idea would be to rename pg_resetxlog to pg_resetwal. I think
> > that's actually an improvement.
>
> This would fit in as part of a general plan to s/xlog/wal/g throughout
> our user-visible names and documentation. Which seem
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Oct 12, 2016 at 10:22 PM, Michael Paquier
> wrote:
> > OK. I can live with that as well. Attached are three patches. The
> > pg_xlog -> pg_wal move, the pg_clog -> pg_transaction move, and the
> > pg_clog -> pg_xact move. Only one survivor to
Robert Haas writes:
> One idea would be to rename pg_resetxlog to pg_resetwal. I think
> that's actually an improvement.
This would fit in as part of a general plan to s/xlog/wal/g throughout
our user-visible names and documentation. Which seems like a good idea
to me; there's no need to expose
On Wed, Oct 12, 2016 at 10:22 PM, Michael Paquier
wrote:
> OK. I can live with that as well. Attached are three patches. The
> pg_xlog -> pg_wal move, the pg_clog -> pg_transaction move, and the
> pg_clog -> pg_xact move. Only one survivor to be chosen among the last
> two ones.
Committed 0001.
On Wed, Oct 19, 2016 at 7:05 AM, Christoph Berg wrote:
> (tl;dr: rename pg_xlog yes, rename pg_resetxlog only if we have a good
> alternative.)
I'm amused by the idea of a TL;DR in parentheses at the very bottom of
the email, but maybe I'm just easily amused.
One idea would be to rename pg_reset
Re: Bruce Momjian 2016-10-19 <20161018220909.ga11...@momjian.us>
> > There's actually another instance of "rename so people shoot their
> > feet less often" here: pg_resetxlog, which is a user-facing tool.
> > Folks on #postgresql have repeatedly been joking that it should rather
> > be named pg_ea
On Fri, Oct 14, 2016 at 07:19:02PM +0200, Christoph Berg wrote:
> Re: Stephen Frost 2016-10-14 <20161014113523.gz13...@tamriel.snowman.net>
> > > We have a tool called pg_xlogdump in the standard installation. initdb
> > > has an option --xlogdir, pg_basebackup has --xlog and others. Renaming
> >
On Fri, Oct 14, 2016 at 11:48 AM, Stephen Frost wrote:
> * Magnus Hagander (mag...@hagander.net) wrote:
> > On Fri, Oct 14, 2016 at 4:35 AM, Stephen Frost
> wrote:
> > > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> > > > On 10/12/16 11:22 AM, Tom Lane wrote:
> > > > > The main
* Christoph Berg (m...@debian.org) wrote:
> Re: Stephen Frost 2016-10-14 <20161014113523.gz13...@tamriel.snowman.net>
> > > We have a tool called pg_xlogdump in the standard installation. initdb
> > > has an option --xlogdir, pg_basebackup has --xlog and others. Renaming
> > > the xlog directory
* Magnus Hagander (mag...@hagander.net) wrote:
> On Fri, Oct 14, 2016 at 4:35 AM, Stephen Frost wrote:
> > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> > > On 10/12/16 11:22 AM, Tom Lane wrote:
> > > > The main problem we're trying to fix here is people thinking that
> > > > some
Re: Stephen Frost 2016-10-14 <20161014113523.gz13...@tamriel.snowman.net>
> > We have a tool called pg_xlogdump in the standard installation. initdb
> > has an option --xlogdir, pg_basebackup has --xlog and others. Renaming
> > the xlog directory would make this all a bit confusing, unless we're
14.10.2016, 07:38, Peter Eisentraut kirjoitti:
On 10/12/16 11:22 AM, Tom Lane wrote:
The main problem we're trying to fix here is people thinking that
something with "log" in the name contains discardable data. Just
relocating the directory without renaming it won't improve that.
I think it w
On Fri, Oct 14, 2016 at 4:35 AM, Stephen Frost wrote:
> * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> > On 10/12/16 11:22 AM, Tom Lane wrote:
> > > The main problem we're trying to fix here is people thinking that
> > > something with "log" in the name contains discardable data.
On Fri, Oct 14, 2016 at 9:56 AM, Tom Lane wrote:
> Jim Nasby writes:
> > On 10/14/16 9:06 AM, Stephen Frost wrote:
> >> It'd probably be easier to move the things that are *not* PG internal
> >> (eg: config files, et al) *out* of the data directory and into somewhere
> >> sensible, like /etc ...
Jim Nasby writes:
> On 10/14/16 9:06 AM, Stephen Frost wrote:
>> It'd probably be easier to move the things that are *not* PG internal
>> (eg: config files, et al) *out* of the data directory and into somewhere
>> sensible, like /etc ...
> I do think it would be an improvement to segregate things
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> On 10/14/16 9:06 AM, Stephen Frost wrote:
> >>> And internal/base and internal/global and internal/pg_... because
> >>> these shouldn't be touched by the users either.
> >>>
> >>> I don't think this would lead anywhere.
> >It'd probably be easier to m
On 10/14/16 9:06 AM, Stephen Frost wrote:
> And internal/base and internal/global and internal/pg_... because
> these shouldn't be touched by the users either.
>
> I don't think this would lead anywhere.
It'd probably be easier to move the things that are *not* PG internal
(eg: config files, et
* Christoph Berg (m...@debian.org) wrote:
> Re: Stephen Frost 2016-10-14 <20161014113523.gz13...@tamriel.snowman.net>
> > > I think it would help if we moved it to something like
> > > "internal/pg_xlog" and "internal/pg_clog". Keep the name but move it
> > > out of sight.
> >
> > I disagree that
Re: Stephen Frost 2016-10-14 <20161014113523.gz13...@tamriel.snowman.net>
> > I think it would help if we moved it to something like
> > "internal/pg_xlog" and "internal/pg_clog". Keep the name but move it
> > out of sight.
>
> I disagree that this will materially help with the issue.
And intern
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 10/12/16 11:22 AM, Tom Lane wrote:
> > The main problem we're trying to fix here is people thinking that
> > something with "log" in the name contains discardable data. Just
> > relocating the directory without renaming it won't imp
On 10/12/16 11:22 AM, Tom Lane wrote:
> The main problem we're trying to fix here is people thinking that
> something with "log" in the name contains discardable data. Just
> relocating the directory without renaming it won't improve that.
I think it would help if we moved it to something like
"i
* David Steele (da...@pgmasters.net) wrote:
> On 10/4/16 1:48 AM, Michael Paquier wrote:
>
> > So this is still open for votes. Here are the candidates and who
> > voiced for what:
> > - pg_transaction: Michael P, Thomas M. => Current 0002 is doing that.
> > - pg_xact: David S, Robert
> > - pg_tra
Peter Eisentraut writes:
> On 10/4/16 1:48 AM, Michael Paquier wrote:
>> So this is still open for votes. Here are the candidates and who
>> voiced for what:
>> - pg_transaction: Michael P, Thomas M. => Current 0002 is doing that.
>> - pg_xact: David S, Robert
>> - pg_trans: Tom
>> - pg_transactio
On 10/4/16 1:48 AM, Michael Paquier wrote:
> So this is still open for votes. Here are the candidates and who
> voiced for what:
> - pg_transaction: Michael P, Thomas M. => Current 0002 is doing that.
> - pg_xact: David S, Robert
> - pg_trans: Tom
> - pg_transaction_status: Peter E.
I think this w
On Tue, Oct 4, 2016 at 1:48 AM, Michael Paquier
wrote:
> Yes, pg_wal is fine as new name in replacement of pg_xlog. Now for the
> pg_clog...
Of course the irony here is that "WAL" stands for "Write Ahead Log".
So we're renaming a directly that has "log" in the name (pg_xlog) to a
directory that h
On 10/4/16 1:48 AM, Michael Paquier wrote:
> So this is still open for votes. Here are the candidates and who
> voiced for what:
> - pg_transaction: Michael P, Thomas M. => Current 0002 is doing that.
> - pg_xact: David S, Robert
> - pg_trans: Tom
> - pg_transaction_status: Peter E.
Christoph als
Robert Haas writes:
> I think the tests for PQserverVersion(conn) / 100 >= 1000 are strange.
> I submit that either PQserverVersion(conn) >= 10 or
> PQserverVersion(conn) / 1 >= 10 is an easier-to-understand test.
> I vote for the first style.
+1, that's the way most existing tests of thi
Re: Michael Paquier 2016-09-30
"pg_trans" is used in two places:
> -pg_clog records the commit status for each transaction that has been assigned
> +pg_trans records the commit status for each transaction that has been
> assigned
> - /* copy old commit logs to new data dir */
> - copy
On Fri, Sep 30, 2016 at 1:45 AM, Michael Paquier
wrote:
> As there have been no reviews at code level, I am moving that to the next CF.
Code review of 0001:
I think the tests for PQserverVersion(conn) / 100 >= 1000 are strange.
I submit that either PQserverVersion(conn) >= 10 or
PQserverVers
On Thu, Sep 29, 2016 at 9:17 PM, Michael Paquier
wrote:
> On Tue, Aug 30, 2016 at 11:04 AM, Michael Paquier
> wrote:
>> On Mon, Aug 29, 2016 at 9:39 PM, Craig Ringer
>> wrote:
>>> Cool. I'll mark as waiting on author pending that.
>>>
>>> It'll be good to get this footgun put away.
>>
>> OK, so
On Tue, Aug 30, 2016 at 11:04 AM, Michael Paquier
wrote:
> On Mon, Aug 29, 2016 at 9:39 PM, Craig Ringer
> wrote:
>> Cool. I'll mark as waiting on author pending that.
>>
>> It'll be good to get this footgun put away.
>
> OK, so done. I have put the renaming of pg_xlog to pg_wal on top patch
> st
On 8/29/16 7:34 PM, Andres Freund wrote:
What if we left symlinks for the config files? Or perhaps even better,
> provide a tool that will create them for people that actually need
> them.
See the thread around
http://archives.postgresql.org/message-id/20160826104446.n3cif4m7modslkrs%40msg.df7cb
On Mon, Aug 29, 2016 at 9:39 PM, Craig Ringer
wrote:
> Cool. I'll mark as waiting on author pending that.
>
> It'll be good to get this footgun put away.
OK, so done. I have put the renaming of pg_xlog to pg_wal on top patch
stack as that's the one making no discussion it seems: a lot of people
l
On 8/28/16 8:45 PM, Jim Nasby wrote:
> People accidentally blowing away pg_clog or pg_xlog is a pretty common
> occurrence, and I don't think there's all that many tools that reference
> them. I think it's well worth renaming them.
I think a related problem is that the default log directory is c
On 8/29/16 12:54 PM, Robert Haas wrote:
> As for the new names, how about pg_wal and
> pg_xact? I don't think "pg_trans" is as good; is it transactional or
> transient or transport or transitive or what?
pg_transaction_status? (or pg_xact_status if you want to keep it short)
--
Peter Eisentraut
On 2016-08-29 19:27:29 -0500, Jim Nasby wrote:
> On 8/27/16 1:11 PM, Tom Lane wrote:
> > Alvaro Herrera writes:
> > > I'm for renaming too, but I'd go with Peter E's suggestion: move pg_xlog
> > > to something like $PGDATA/var/wal or $PGDATA/srv/wal or something like
> > > that.
> >
> > I think
On 8/27/16 1:11 PM, Tom Lane wrote:
Alvaro Herrera writes:
I'm for renaming too, but I'd go with Peter E's suggestion: move pg_xlog
to something like $PGDATA/var/wal or $PGDATA/srv/wal or something like that.
I think that would make sense if we were to relocate *everything* under
PGDATA into
On Fri, Aug 26, 2016 at 05:14:36PM +0200, Magnus Hagander wrote:
> On Aug 26, 2016 5:13 PM, "Joshua D. Drake" wrote:
> >
> > On 08/25/2016 07:39 PM, Michael Paquier wrote:
> >>
> >> Hi all,
> >>
> >> I am relaunching $subject as 10 development will begin soon. As far as
> >> I know, there is agree
On 08/29/2016 10:00 AM, Daniel Verite wrote:
Let's imagine that pg_xlog is named wal instead.
How does that help our user with the disk space problem?
Does that point to a path of resolution? I don't see it.
What do we think that user's next move will be?
After all, WAL means Write Ahead *Log*.
Joshua D. Drake wrote:
> You log in, see that all the space and you find that you are using a
> ton of disk space. You look around for anything you can delete. You
> find a directory called pg_xlog, it says log, junior ignorant, don't
> want to be a sysadmin 101 says, "delete logs".
Yes,
On Sat, Aug 27, 2016 at 2:03 PM, Michael Paquier
wrote:
> - Rename them, hard break is OK: Michael P, Bruce, Stephen (depends on
> David's input), Magnus
I'm in favor of this. But I don't like Peter's proposal to use a more
complicated structure. As for the new names, how about pg_wal and
pg_x
On Sat, Aug 27, 2016 at 5:33 PM, Michael Paquier
wrote:
> On Sat, Aug 27, 2016 at 6:34 AM, Andres Freund wrote:
>> On 2016-08-26 17:31:14 -0400, Peter Eisentraut wrote:
>>> I agree with all that. But the subject line is specifically about
>>> moving pg_xlog. So if your opinion is that we should
On 08/29/2016 08:07 AM, Tom Lane wrote:
"Joshua D. Drake" writes:
Also as a note to the idea that we make break things for external user
space; the next version being v10 is the exact time to do that.
Let's please drop this meme that "v10 is a great time to break things".
We don't want this t
On 2016-08-29 12:07:51 -0400, David Steele wrote:
> >> pg_replslot -> pg_tmp/pg_repslot
> >
> > That's most certainly not ephemeral. Just because something isn't
> > generally appropriate on a standby, doesn't, by far, mean it's ephemeral.
>
> Yes, ephemeral was a poor choice of words. I really
On 8/29/16 11:35 AM, Andres Freund wrote:
> On 2016-08-29 11:18:38 -0400, David Steele wrote:
>> pg_logical -> pg_replgcl
>
> That seems considerably worse.
Fair enough. I was just trying to throw something out there to get rid
of the "log" in logical.
>> pg_replslot -> pg_tmp/pg_repslot
>
> T
Andres Freund writes:
> On 2016-08-29 11:18:38 -0400, David Steele wrote:
>> pg_replslot -> pg_tmp/pg_repslot
> That's most certainly not ephemeral. Just because something isn't
> generally appropriate on a standby, doesn't, by far, mean it's ephemeral.
Do we need to account for both of those co
Hi,
On 2016-08-29 11:18:38 -0400, David Steele wrote:
> pg_logical -> pg_replgcl
That seems considerably worse.
> pg_replslot -> pg_tmp/pg_repslot
That's most certainly not ephemeral. Just because something isn't
generally appropriate on a standby, doesn't, by far, mean it's ephemeral.
Greetin
On 8/27/16 4:33 AM, Michael Paquier wrote:
> On Sat, Aug 27, 2016 at 6:34 AM, Andres Freund wrote:
>> On 2016-08-26 17:31:14 -0400, Peter Eisentraut wrote:
>>> I agree with all that. But the subject line is specifically about
>>> moving pg_xlog. So if your opinion is that we shouldn't move pg_xl
"Joshua D. Drake" writes:
> Also as a note to the idea that we make break things for external user
> space; the next version being v10 is the exact time to do that.
Let's please drop this meme that "v10 is a great time to break things".
We don't want this to be any worse than any other major-ver
On 08/29/2016 06:42 AM, Daniel Verite wrote:
Aside from that, we might also question how much of the excuse
"pg_xlog looked like it was just deletable logs" is a lie made up
after the fact, because anybody wrecking a database is not against
deflecting a bit of the blame to the software, that's h
On 08/29/2016 12:04 AM, Magnus Hagander wrote:
On Mon, Aug 29, 2016 at 2:45 AM, Jim Nasby mailto:jim.na...@bluetreble.com>> wrote:
On 8/26/16 4:08 PM, Andres Freund wrote:
Splitting of ephemeral data seems to have a benefit, the rest
seems more
like rather noisy busy
On 08/27/2016 11:11 AM, Tom Lane wrote:
Alvaro Herrera writes:
I'm for renaming too, but I'd go with Peter E's suggestion: move pg_xlog
to something like $PGDATA/var/wal or $PGDATA/srv/wal or something like that.
I think that would make sense if we were to relocate *everything* under
PGDATA i
Craig Ringer wrote:
> People won't see a README in amongst 5000 xlog segments while
> freaking out about the sever being down.
Maybe they're more likely to google "pg_xlog".
BTW, renaming it will not help with respect to that, as
there's a pretty good corpus on knowledge linked to that
pa
On 29 August 2016 at 20:28, Michael Paquier wrote:
> On Mon, Aug 29, 2016 at 5:28 PM, Craig Ringer
> wrote:
>> On 29 August 2016 at 14:30, Michael Paquier
>> wrote:
>>> On Mon, Aug 29, 2016 at 2:36 PM, Craig Ringer
>>> wrote:
I don't care if it comes as part of some greater reorg or not b
On Mon, Aug 29, 2016 at 5:28 PM, Craig Ringer
wrote:
> On 29 August 2016 at 14:30, Michael Paquier wrote:
>> On Mon, Aug 29, 2016 at 2:36 PM, Craig Ringer
>> wrote:
>>> I don't care if it comes as part of some greater reorg or not but I'll be
>>> really annoyed if scope creep lands up killing th
On 27/08/16 18:50, Tom Lane wrote:
Michael Paquier writes:
OK, so let's focus only on the renaming mentioned in $subject. So far
as I can see on this thread, here are the opinions of people who
clearly gave one:
- Rename them, hard break is OK: Michael P, Bruce, Stephen (depends on
David's inpu
On 29 August 2016 at 14:30, Michael Paquier wrote:
> On Mon, Aug 29, 2016 at 2:36 PM, Craig Ringer
> wrote:
>> I don't care if it comes as part of some greater reorg or not but I'll be
>> really annoyed if scope creep lands up killing the original proposal to just
>> rename these dirs. I think th
1 - 100 of 136 matches
Mail list logo