On Sunday, 23 October 2016, Michael Paquier
wrote:
> On Sun, Oct 23, 2016 at 5:05 PM, Venkata B Nagothi
> wrote:
> > I just did did a "git pull" to test one of my patches and i get the
> > following error :
> >
> > 2016-10-23 18:51:47.679 AEDT [31930] FATAL: could not open archive
> status
> >
On Sun, Oct 23, 2016 at 5:05 PM, Venkata B Nagothi wrote:
> I just did did a "git pull" to test one of my patches and i get the
> following error :
>
> 2016-10-23 18:51:47.679 AEDT [31930] FATAL: could not open archive status
> directory "pg_xlog/archive_status": No such file or directory
> 2016-
I just did did a "git pull" to test one of my patches and i get the
following error :
2016-10-23 18:51:47.679 AEDT [31930] FATAL: could not open archive status
directory "pg_xlog/archive_status": No such file or directory
2016-10-23 18:51:47.679 AEDT [31841] LOG: archiver process (PID 31930)
exi
On 05/03/2016 06:38 PM, Michael Paquier wrote:
On Mon, May 2, 2016 at 10:29 PM, Robert Haas wrote:
On Thu, Apr 28, 2016 at 11:46 PM, Craig Ringer wrote:
I just helped another person yesterday who deleted their pg_xlog.
The biggest reason I've seen pg_xlog get deleted is not because it's
cal
On Mon, May 2, 2016 at 10:29 PM, Robert Haas wrote:
> On Thu, Apr 28, 2016 at 11:46 PM, Craig Ringer wrote:
>> I just helped another person yesterday who deleted their pg_xlog.
>
> The biggest reason I've seen pg_xlog get deleted is not because it's
> called pg_xlog, but because it's located some
On Thu, Apr 28, 2016 at 11:46 PM, Craig Ringer wrote:
> On 29 April 2016 at 10:12, Bruce Momjian wrote:
>> My larger question was, was 9.6 an ideal time to do this, and if so, why
>> did this issue not get done. If 9.6 wasn't in some way ideal, we can do
>> it in 9.7.
>
> Doing it at the very be
On 29 April 2016 at 10:12, Bruce Momjian wrote:
>
> My larger question was, was 9.6 an ideal time to do this, and if so, why
> did this issue not get done. If 9.6 wasn't in some way ideal, we can do
> it in 9.7.
>
>
Doing it at the very beginning of the release cycle seems like a good idea.
I
On Thu, Apr 28, 2016 at 10:07:40PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Are we going to rename pg_xlog or pg_clog for 9.6?
>
> NO. We don't even have a patch for this, much less one that's been
> through any review. This suggestion is at least two months too late.
My larger quest
Bruce Momjian writes:
> Are we going to rename pg_xlog or pg_clog for 9.6?
NO. We don't even have a patch for this, much less one that's been
through any review. This suggestion is at least two months too late.
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Thu, Apr 28, 2016 at 04:30:39PM -0700, Andres Freund wrote:
> On 2016-04-28 19:23:26 -0400, Bruce Momjian wrote:
> >
> > Are we going to rename pg_xlog or pg_clog for 9.6?
>
> If we do so, we should do it at a good bit earlier in the cycle imo.
Well, we talked about it in May of 2015, but did
On 2016-04-28 19:23:26 -0400, Bruce Momjian wrote:
>
> Are we going to rename pg_xlog or pg_clog for 9.6?
If we do so, we should do it at a good bit earlier in the cycle imo.
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
htt
Are we going to rename pg_xlog or pg_clog for 9.6?
---
On Sun, May 31, 2015 at 10:44:54PM +0200, Joel Jacobson wrote:
> On Sun, May 31, 2015 at 7:46 PM, Tom Lane wrote:
> > Hm. I think the impact on third-party backup tool
On Tue, Jun 2, 2015 at 2:45 AM, Mark Kirkwood wrote:
> On 01/06/15 05:29, Joel Jacobson wrote:
>
>> While anyone who is familiar with postgres would never do something as
>> stupid as to delete pg_xlog,
>> according to Google, there appears to be a fair amount of end-users out
>> there having mad
On 6/2/15 4:58 PM, David Steele wrote:
On 5/31/15 1:46 PM, Tom Lane wrote:
Hm. I think the impact on third-party backup tools would be rather bad,
but there's a simple modification of the idea that might fix that:
just always create pg_xlog as a symlink to pg_xjournal during initdb.
Anybody who
On 5/31/15 1:46 PM, Tom Lane wrote:
> Hm. I think the impact on third-party backup tools would be rather bad,
> but there's a simple modification of the idea that might fix that:
> just always create pg_xlog as a symlink to pg_xjournal during initdb.
> Anybody who blindly removes pg_xlog won't hav
* Michael Nolan wrote:
> Why not take a simpler approach and create a zero length file in directories
> that should not be fiddled with by non-experts using a file name something
> like "DO.NOT.DELETE.THESE.FILES"?
Move the critical things into a new subdirectory?
$PGDATA/pg_critical/pg_xlog?
On Tue, Jun 2, 2015 at 11:03 PM, Abhijit Menon-Sen wrote:
> At 2015-06-01 23:35:23 -0500, htf...@gmail.com wrote:
>>
>> No, it won't prevent the incredibly stupid from doing incredibly
>> stupid things, nothing will.
>
> I hate to speechify, but I think we should try hard to avoid framing
> such q
On Tue, Jun 2, 2015 at 07:33:19PM +0530, Abhijit Menon-Sen wrote:
> At 2015-06-01 23:35:23 -0500, htf...@gmail.com wrote:
> >
> > No, it won't prevent the incredibly stupid from doing incredibly
> > stupid things, nothing will.
>
> I hate to speechify, but I think we should try hard to avoid fram
On 06/01/2015 09:35 PM, Michael Nolan wrote:
Why not take a simpler approach and create a zero length file in
directories that should not be fiddled with by non-experts using a file
name something like "DO.NOT.DELETE.THESE.FILES"?
+1
No, it won't prevent the incredibly stupid from doing inc
At 2015-06-01 23:35:23 -0500, htf...@gmail.com wrote:
>
> No, it won't prevent the incredibly stupid from doing incredibly
> stupid things, nothing will.
I hate to speechify, but I think we should try hard to avoid framing
such questions in terms of "incredibly stupid" people and the things
they m
On 06/02/2015 03:06 AM, Joel Jacobson wrote:
On Tue, Jun 2, 2015 at 6:35 AM, Michael Nolan wrote:
Why not take a simpler approach and create a zero length file in directories
that should not be fiddled with by non-experts using a file name something
like "DO.NOT.DELETE.THESE.FILES"?
Then the
On 01/06/15 05:29, Joel Jacobson wrote:
While anyone who is familiar with postgres would never do something as
stupid as to delete pg_xlog,
according to Google, there appears to be a fair amount of end-users out
there having made the irrevocable mistake of deleting the precious
directory,
a decis
On Tue, Jun 2, 2015 at 6:35 AM, Michael Nolan wrote:
> Why not take a simpler approach and create a zero length file in directories
> that should not be fiddled with by non-experts using a file name something
> like "DO.NOT.DELETE.THESE.FILES"?
Then the smart sysadmin will say "but I didn't delet
Le 2 juin 2015 6:37 AM, "Michael Nolan" a écrit :
>
> Why not take a simpler approach and create a zero length file in
directories that should not be fiddled with by non-experts using a file
name something like "DO.NOT.DELETE.THESE.FILES"?
>
> No, it won't prevent the incredibly stupid from doing
Why not take a simpler approach and create a zero length file in
directories that should not be fiddled with by non-experts using a file
name something like "DO.NOT.DELETE.THESE.FILES"?
No, it won't prevent the incredibly stupid from doing incredibly stupid
things, nothing will.
--
Mike Nolan
On Tue, Jun 2, 2015 at 8:48 AM, Josh Berkus wrote:
> On 06/01/2015 04:22 PM, Thomas Munro wrote:
>> On Tue, Jun 2, 2015 at 8:17 AM, Josh Berkus wrote:
>>> Also ... if we were to rename it, it should be "pg_wal" or "pg_xact".
>>> Please let's not add yet another term for the WAL.
>>
>> +1 for pg_w
On 06/01/2015 04:22 PM, Thomas Munro wrote:
> On Tue, Jun 2, 2015 at 8:17 AM, Josh Berkus wrote:
>> Also ... if we were to rename it, it should be "pg_wal" or "pg_xact".
>> Please let's not add yet another term for the WAL.
>
> +1 for pg_wal if it has to be renamed.
>
> If pg_clog also has to be
On Tue, Jun 2, 2015 at 8:17 AM, Josh Berkus wrote:
> Also ... if we were to rename it, it should be "pg_wal" or "pg_xact".
> Please let's not add yet another term for the WAL.
+1 for pg_wal if it has to be renamed.
If pg_clog also has to be renamed, how about using your other
suggestion "pg_xact
On Mon, Jun 1, 2015 at 05:57:27PM -0400, David Steele wrote:
> On 6/1/15 4:42 PM, Joel Jacobson wrote:
> >> Also ... if we were to rename it, it should be "pg_wal" or "pg_xact".
> >> Please let's not add yet another term for the WAL.
>
> I like pg_wal. It's correct and suitably mysterious.
+1
On 6/1/15 4:42 PM, Joel Jacobson wrote:
>> Also ... if we were to rename it, it should be "pg_wal" or "pg_xact".
>> Please let's not add yet another term for the WAL.
I like pg_wal. It's correct and suitably mysterious.
--
- David Steele
da...@pgmasters.net
signature.asc
Description: OpenPGP
On Mon, Jun 1, 2015 at 10:17 PM, Josh Berkus wrote:
> If we symlink pg_xlog, then it will still trip up anyone who does "rm
> -rf *log*/*" or deletes files directly from inside the directory, both
> of which I've seen. Deleting the directory itself is comparatively rare
> in my experience. So fo
On 05/31/2015 10:46 AM, Tom Lane wrote:
> Joel Jacobson writes:
>> If we could turn back time, would we have picked "pg_xlog" as the most
>> optimal name for this important directory, or would we have come up with a
>> more user-friendly name?
>
> Yeah...
>
>> My suggestion is to use "pg_xjourna
On 5/31/15 1:29 PM, Joel Jacobson wrote:
> My suggestion is to use "pg_xjournal" instead of "pg_xlog"
If we're going to make any changes in this area, I would like to see a
more comprehensive solution for separating user-editable files from
internal files. (E.g., make subdirectories "etc" and "va
At 2015-05-31 13:46:33 -0400, t...@sss.pgh.pa.us wrote:
>
> just always create pg_xlog as a symlink to pg_xjournal during initdb.
At first glance, the Subject: of this thread made me think that *was*
Joel's proposal. :-) But I think it's a great idea, and worth doing.
I think "pg_journal" (no "x"
On Sun, May 31, 2015 at 7:46 PM, Tom Lane wrote:
> Hm. I think the impact on third-party backup tools would be rather bad,
> but there's a simple modification of the idea that might fix that:
> just always create pg_xlog as a symlink to pg_xjournal during initdb.
> Anybody who blindly removes pg_
Joel Jacobson writes:
> If we could turn back time, would we have picked "pg_xlog" as the most
> optimal name for this important directory, or would we have come up with a
> more user-friendly name?
Yeah...
> My suggestion is to use "pg_xjournal" instead of "pg_xlog" when new users
> create a ne
While anyone who is familiar with postgres would never do something as
stupid as to delete pg_xlog,
according to Google, there appears to be a fair amount of end-users out
there having made the irrevocable mistake of deleting the precious
directory,
a decision made on the assumption that since "it
On 11.07.2011 17:33, jcamera wrote:
Hi,
I have problems in my database. I think it is corrupted. Folow my log
when I tried to start it standalone.
I have some questions:
1. I saw that the error is in base/30518/449778670_vm file. Can I rebuild
this file or somethink like this?
*_vm files
Hi,
I have problems in my database. I think it is corrupted. Folow my log
when I tried to start it standalone.
I have some questions:
1. I saw that the error is in base/30518/449778670_vm file. Can I rebuild
this file or somethink like this?
2. In the last line of log, we can see "DEBUG: sh
Hi all
How can i read transactions from "write ahead log " pg_xlog ?
It is possible ?
regards
S.W
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
qmis wrote:
> Hi all
>
> How can i read transactions from "write ahead log " pg_xlog ?
> It is possible ?
No, it is all binary and read only on startup after a crash. If you want
to interpret it, you have to read the backend code that reads it during
recovery.
--
Bruce Momjian
41 matches
Mail list logo
