On 9 September 2011 01:04, George Barnett wrote:
> After looking through the code I found that when postgres calls write() it
> doesn't retry. In order to address the issue with the PANIC in the WAL
> writer I set the sync method to o_sync which solved the issue in that part of
> the code, how
On fre, 2011-09-09 at 10:04 +1000, George Barnett wrote:
> After looking through the code I found that when postgres calls
> write() it doesn't retry. In order to address the issue with the
> PANIC in the WAL writer I set the sync method to o_sync which solved
> the issue in that part of the code,
On Thu, Sep 8, 2011 at 03:22, Robert Haas wrote:
> On Wed, Sep 7, 2011 at 5:24 PM, Alvaro Herrera
> wrote:
>> I remember we had bugs whereby an encoding conversion would fail,
>> leading to elog trying to report this problem, but this attempt would
>> also incur a conversion step, failing recursi
On Fri, Sep 9, 2011 at 11:56, Fujii Masao wrote:
> Hi,
>
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg02343.php
>
> In previous discussion, we've reached the consensus that we should unite
> recovery.conf and postgresql.conf. The attached patch does that. The
> patch is WIP, I'll have
On Tue, Sep 6, 2011 at 22:35, Simon Riggs wrote:
> On Mon, Sep 5, 2011 at 11:38 AM, Magnus Hagander wrote:
>> On Sun, Sep 4, 2011 at 19:02, Simon Riggs wrote:
>>> On Fri, Sep 2, 2011 at 6:52 PM, Magnus Hagander wrote:
>>>
Attached patch implements a "low watermark wal location" in the
On Fri, Sep 9, 2011 at 7:21 PM, Magnus Hagander wrote:
> On Fri, Sep 9, 2011 at 11:56, Fujii Masao wrote:
>> Hi,
>>
>> http://archives.postgresql.org/pgsql-hackers/2010-12/msg02343.php
>>
>> In previous discussion, we've reached the consensus that we should unite
>> recovery.conf and postgresql.c
On Fri, Sep 9, 2011 at 13:15, Fujii Masao wrote:
> On Fri, Sep 9, 2011 at 7:21 PM, Magnus Hagander wrote:
>> On Fri, Sep 9, 2011 at 11:56, Fujii Masao wrote:
>>> Hi,
>>>
>>> http://archives.postgresql.org/pgsql-hackers/2010-12/msg02343.php
>>>
>>> In previous discussion, we've reached the consen
Magnus Hagander writes:
>> If you must have this then make pg_basebackup copy xlog files
>> regularly during the backup. That way your backup can take forever and
>> your primary disk won't fill up. In many cases it actually will take
>> forever, but at least we don't take down the primary.
>
> Th
On Fri, Sep 9, 2011 at 13:40, Dimitri Fontaine wrote:
> Magnus Hagander writes:
>>> If you must have this then make pg_basebackup copy xlog files
>>> regularly during the backup. That way your backup can take forever and
>>> your primary disk won't fill up. In many cases it actually will take
>>>
On sön, 2011-09-04 at 12:06 -0400, Andrew Dunstan wrote:
> Maybe we need a few members that test a large number of locales.
> (Anyone feel like donating resources? I'm currently providing
> resources for seven, which I think is sufficient :-) )
If we're just testing different configuration combin
On Sep9, 2011, at 13:48 , Magnus Hagander wrote:
> On Fri, Sep 9, 2011 at 13:40, Dimitri Fontaine wrote:
>> Magnus Hagander writes:
If you must have this then make pg_basebackup copy xlog files
regularly during the backup. That way your backup can take forever and
your primary disk
Florian Pflug writes:
> Couldn't we send all available WAL after each single data-file instead
> of waiting for all data files to be transferred before sending WAL?
+1 (or maybe not at the file boundary but rather driven by archive
command with some internal hooking, as the backend needs some new
Magnus Hagander writes:
> I have to wonder though, if it wouldn't be less confusing to just get
> rid of recovery.conf and use a *different* file for this. Just to make
> it clear it's not a config file, but just a boolean exists/notexists
> state.
+1. If it's not a configuration file anymore, i
Magnus Hagander writes:
> On Fri, Sep 9, 2011 at 13:40, Dimitri Fontaine wrote:
>> I'm not getting why we need the later one when we have this older one?
> One of them is for the simple case. It requires a single connection to
> the server, and it supports things like writing to tarfiles and
> c
George Barnett writes:
> [ patch to retry writes on NFS ]
I'm having a hard time getting excited about this idea, because IMO
NFS is insufficiently reliable to run a database on, and no patch like
this can fix that. However, some concrete points:
1. If writes need to be retried, why not reads?
Hello,
On Sep 7, 2011, at 5:00 PM, Tom Lane wrote:
> Andy Colson writes:
>> Where did the other warnings go? Its right though, line 570 is bad. It
>> also seems to have killed the server. I have not gotten through the history
>> of messages regarding this patch, but is it supposed to kill t
On Fri, Sep 9, 2011 at 3:05 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> I have to wonder though, if it wouldn't be less confusing to just get
>> rid of recovery.conf and use a *different* file for this. Just to make
>> it clear it's not a config file, but just a boolean exists/notexists
>> s
--On 9. September 2011 10:27:22 -0400 Tom Lane wrote:
On the whole I think you'd be better off lobbying your NFS implementors
to provide something closer to the behavior of every other filesystem on
the planet. Or checking to see if you need to adjust your NFS
configuration, as the other res
On Thu, Sep 8, 2011 at 8:42 PM, Fujii Masao wrote:
> Another idea to avoid spinlock contention is save the timestamp in
> PgBackendStatus (which contains information for pg_stat_activity).
> This enables us to write and read the timestamp without spinlock.
> Comments?
That seems like a possibly p
I marked this patch as "Ready for Committer", and hope this patch being
committed.
Thanks,
--
NEC Europe Ltd, SAP Global Competence Center
KaiGai Kohei
> -Original Message-
> From: Shigeru Hanada [mailto:shigeru.han...@gmail.com]
> Sent: 9. September 2011 06:03
> To: Kohei Kaigai
> Cc:
I wrote:
> I propose moving the Timestamp/Interval typedefs, as well as some basic
> associated macros such as the ones mentioned above (basically, lines
> 25-100 of utils/timestamp.h, plus the DT_NOBEGIN/DT_NOEND stuff, plus
> the Julian-date macros in datetime.h), into a separate header file that
On 9/9/11 7:05 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> I have to wonder though, if it wouldn't be less confusing to just get
>> rid of recovery.conf and use a *different* file for this. Just to make
>> it clear it's not a config file, but just a boolean exists/notexists
>> state.
>
> +1.
On Fri, Sep 09, 2011 at 10:27:22AM -0400, Tom Lane wrote:
> George Barnett writes:
> > [ patch to retry writes on NFS ]
>
> I'm having a hard time getting excited about this idea, because IMO
> NFS is insufficiently reliable to run a database on, and no patch like
> this can fix that. However, s
Hi,
this is not exactly a Postgresql question, but an input from hackers
list like this would be invaluable for me.
I am coding my own database engine, and I decided to do not implement
transaction engine because it implies too much code.
But to achieve the Durability of ACID I need a 100% reliable
Noah Misch wrote:
> We shouldn't complain when a kernel provides a conforming write(),
> even if it appears that the kernel achieved little by using some
> freedom afforded it.
I remember we had some compiler warnings in the logging area because
we were making the assumption that no implementa
On Sep9, 2011, at 20:15 , Nulik Nol wrote:
> this is not exactly a Postgresql question, but an input from hackers
> list like this would be invaluable for me.
> I am coding my own database engine, and I decided to do not implement
> transaction engine because it implies too much code.
> But to achi
On Sep8, 2011, at 15:09 , Aidan Van Dyk wrote:
> Personally, I think both of these show examples of why PG should be
> looking hard at either providing a simple robust local directory based
> archive_command, or very seriously pointing users at properly written
> tools like omniptr, or ptrtools, wa
On Fri, Sep 09, 2011 at 08:59:43PM +0200, Florian Pflug wrote:
> Archiving WAL should be done by copying to a temp file and moving it
> into place. Before returning success, one should probably also do the
> fsync incantations the linux kernel guys argued are necessary to prevent
> the file from ap
On Thu, Sep 8, 2011 at 1:56 PM, Tom Lane wrote:
> Daniel Farina writes:
>> On Tue, Sep 6, 2011 at 12:00 PM, Tom Lane wrote:
>>> I'm still of the opinion that there's no real need to avoid memcpy with
>>> identical source and destination, so I didn't apply this first patch.
>
>> I am leery of mem
Excerpts from Alvaro Herrera's message of mar ago 09 13:01:04 -0400 2011:
> To implement this, we need to augment MultiXact to store the lock type
> that each comprising Xid holds on the tuple. Two bits per Xid are
> needed. My thinking is that we could simply extend the "members" to add
> a by
On Wed, Aug 24, 2011 at 1:04 PM, Daniel Farina wrote:
> On Wed, Aug 24, 2011 at 12:38 PM, Tom Lane wrote:
>> Assuming the issue really is the physical unlinks (which I agree I'd
>> like to see some evidence for), I wonder whether the problem could be
>> addressed by moving smgrDoPendingDeletes()
On Thu, Sep 8, 2011 at 10:03 PM, Magnus Hagander wrote:
>> Would there be a way to prevent this abhorrent scenario from coming
>> into existence?
> There are plenty of clustering products out there that are really
> designed for one thing pimarily, and that's dealing with this kind of
> fencing.
On Fri, Sep 9, 2011 at 6:57 AM, Heikki Linnakangas
wrote:
>> In particular, I'd like to know what
>> boundaries it is envisaged that the code should be refactored along to
>> increase its conceptual integrity, or to better separate concerns. I
>> assume that that's the idea, since each new .c file
Tom Lane wrote:
> George Barnett writes:
> > [ patch to retry writes on NFS ]
>
> I'm having a hard time getting excited about this idea, because IMO
> NFS is insufficiently reliable to run a database on, and no patch like
> this can fix that. However, some concrete points:
>
> 1. If writes nee
On Fri, Sep 9, 2011 at 6:40 PM, Josh Berkus wrote:
> I'm in favor of this. People are sufficiently confused by the existing
> behavior that we're not going to confuse them further by changing it.
>
Fwiw as someone who *was* confused previously, it now makes perfect
sense to me. "We have postgres
On Fri, Sep 9, 2011 at 7:46 PM, Florian Pflug wrote:
>> I am going to use the whole partition device for the DB (like /dev/sda1)
>> , so no filesystem code will be used. Also I am using asynchronous IO
>> (the aio_read and aio_write) and I don't know if they can be combined
>> with the fdatasync()
Excerpts from Tom Lane's message of vie sep 09 18:59:45 -0300 2011:
> Simplify handling of the timezone GUC by making initdb choose the default.
>
> We were doing some amazingly complicated things in order to avoid running
> the very expensive identify_system_timezone() procedure during GUC
> ini
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of vie sep 09 18:59:45 -0300 2011:
>> Simplify handling of the timezone GUC by making initdb choose the default.
> Hmm, I was hoping that this might open the door for setting a nonempty
> default log_line_prefix, but apparently not :-( Se
I've produced the refinement of my little shell script anticipated by
my last e-mail (using sed to remove irrelevant variations in
__func__.12345 type symbol names). I decided to test it for:
1. Detecting behavioural changes when removing existing "pgrminclude
ignore" files (Basically headers that
Robert Haas wrote:
> On Sat, May 7, 2011 at 11:42 PM, Bruce Momjian wrote:
> > Is this a TODO?
>
> I think so.
Added to TODO:
Address problem where superusers are assumed to be members of all groups
http://archives.postgresql.org/pgsql-hackers/2011-04/msg00337.php
Hi,
Currently createuser cannot create a role with REPLICATION privilege
because it doesn't have any option to do that. Which sometimes annoys
me when setting up replication. I'd like to propose to add new options
"-x (--replication)" and "-X (--no-replication)" into createuser. "-x" allows
the ne
On Sat, Sep 10, 2011 at 01:07, Greg Stark wrote:
> On Fri, Sep 9, 2011 at 6:40 PM, Josh Berkus wrote:
>> I'm in favor of this. People are sufficiently confused by the existing
>> behavior that we're not going to confuse them further by changing it.
>>
>
> Fwiw as someone who *was* confused previ
On Sat, Sep 10, 2011 at 2:08 PM, Fujii Masao wrote:
> Currently createuser cannot create a role with REPLICATION privilege
> because it doesn't have any option to do that. Which sometimes annoys
> me when setting up replication. I'd like to propose to add new options
> "-x (--replication)" and "-X
43 matches
Mail list logo
