> From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Daniel Farina
> Sent: Tuesday, July 10, 2012 11:42 AM
>>On Mon, Jul 9, 2012 at 1:30 PM, Shaun Thomas
wrote:
>>
>> 1. Slave wants to be synchronous with master. Master wants replication on
at least o
Sorry by mistake for below mail, I have not kept hackers in loop.
From: Amit Kapila [mailto:amit.kap...@huawei.com]
Sent: Tuesday, July 10, 2012 12:07 PM
To: 'Gurjeet Singh'
Subject: RE: [HACKERS] Allow replacement of bloated primary key indexes
without foreign key rebuilds
From: pgsql-hac
On Mon, Jul 9, 2012 at 1:30 PM, Shaun Thomas wrote:
>
> 1. Slave wants to be synchronous with master. Master wants replication on at
> least one slave. They have this, and are happy.
> 2. For whatever reason, slave crashes or becomes unavailable.
> 3. Master notices no more slaves are available,
On Jul 9, 2012, at 7:48 PM, Bruce Momjian wrote:
> Rsync is popular with Postgres users, but I don't understand how they
> are using the default check mode (file size, modification time) to
> synchronize shut-down data directories? It seems they would have to use
> --checksum because it is too e
Rsync is popular with Postgres users, but I don't understand how they
are using the default check mode (file size, modification time) to
synchronize shut-down data directories? It seems they would have to use
--checksum because it is too easy for files to change in the same
second, and for a backe
I noticed today that has_language_privilege() returns incorrect answer
for non-superuser, e.g.:
8<---
select has_language_privilege('nobody',
'plperlu',
'usage');
has_language_privilege
---
Shaun,
> PostgreSQL's implementation means the master will block until
> someone/something notices and tells it to stop waiting, or the slave
> comes back. For pretty much any high-availability environment, this is
> not viable. Based on that alone, I can't imagine a scenario where
> synchronous r
>>> -- Bug Submitter: easy-access way for users to submit bugs and check on
>>> their status later.
>
>> Not sure how to handle the first two. Bug submission is always a pita and
>> although we could use the fix-bug-later app, it would clutter it as we were
>> trying to determine real bugs vs use
On Mon, Jul 9, 2012 at 8:23 PM, Fujii Masao wrote:
> Hi,
>
> I found several problems in pg_receivexlog, e.g., memory leaks,
> file-descripter leaks, ..etc. The attached patch fixes these problems.
While I don't doubt that what you've found are real problems, would
you mind explaining exactly wha
> Could you crank up the log verbosity so we can get
> file and line number, at least?
First hit since the change:
ERROR: XX000: could not open relation with OID 1554847444
LOCATION: relation_open, heapam.c:879
STATEMENT: SELECT
...
Will leave the verbosity up and see if it occurs in the sam
Hey everyone,
Upon doing some usability tests with PostgreSQL 9.1 recently, I ran
across this discussion:
http://archives.postgresql.org/pgsql-hackers/2011-12/msg01224.php
And after reading the entire thing, I found it odd that the overriding
pushback was because nobody could think of a use
> > ERROR: could not open relation with OID 1554847326
>
> Is that the *entire* message? No details? Could you crank up the
> log verbosity so we can get file and line number, at least?
Yes, that's the entire thing, other than the statement line after it.
In this particular case:
STATEMENT:
Greg Sabino Mullane writes:
> I've expanded my searching a bit, to see if I can find any other
> correlations. One thing that seems to happen about 10 times a day
> is an error of this sort:
> ERROR: could not open relation with OID 1554847326
Is that the *entire* message? No details? Could
On Mon, Jul 9, 2012 at 3:26 PM, Joshua D. Drake wrote:
>
> On 07/09/2012 12:02 PM, Josh Berkus wrote:
>>
>>
>> Hackers,
>>
>> So I want to repeat this because I think we are conflating several uses
>> for a "bug tracker" which aren't the same, and which really need to be
>> dealt with seperately.
I've expanded my searching a bit, to see if I can find any other
correlations. One thing that seems to happen about 10 times a day
is an error of this sort:
ERROR: could not open relation with OID 1554847326
In this case, the OID in question always exists, and corresponds to
one of a handful
On 07/09/2012 12:02 PM, Josh Berkus wrote:
Hackers,
So I want to repeat this because I think we are conflating several uses
for a "bug tracker" which aren't the same, and which really need to be
dealt with seperately.
-- Better CF App: to track feature submissions, discussion, revisions
and r
Hackers,
So I want to repeat this because I think we are conflating several uses
for a "bug tracker" which aren't the same, and which really need to be
dealt with seperately.
-- Better CF App: to track feature submissions, discussion, revisions
and reviews.
-- Bug Submitter: easy-access way for
Hi,
I found several problems in pg_receivexlog, e.g., memory leaks,
file-descripter leaks, ..etc. The attached patch fixes these problems.
ISTM there are still some other problems in pg_receivexlog, so I'll
read it deeply later.
Regards,
--
Fujii Masao
fix_pgreceivexlog_problems_v1.patch
Des
Few days back, I have worked on 2 bugs and sent the reason why that defect
is occurring.
According to me those defects should be fixed as they have been introduced
in some recent versions.
Defect -1
Bug reference: 6712
http://archives.postgresql.org/pgsql-bugs/2012-07/msg1.php
> y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes:
>>> Also, I was under the impression that recent Linux kernels use hugepages
>>> automatically if they can, so I wonder exactly what Andres was testing
>>> on ...
>
>> if you mean the "trasparent hugepage" feature, iirc it doesn't affect
>> MAP_S
> Robert Haas writes:
>> On Fri, Jun 29, 2012 at 3:52 PM, Andres Freund
>> wrote:
>>> In a *very* quick patch I tested using huge pages/MAP_HUGETLB for the
>>> mmap'ed
>>> memory.
>
>> So, considering that there is required setup, it seems that the
>> obvious thing to do here is add a GUC: hug
On Monday, July 09, 2012 08:11:00 AM Tom Lane wrote:
> y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes:
> >> Also, I was under the impression that recent Linux kernels use hugepages
> >> automatically if they can, so I wonder exactly what Andres was testing
> >> on ...
> >
> > if you mean the "tr
Hi Ryan,
On Mon, Jun 25, 2012 at 9:00 PM, Ryan Kelly wrote:
>> Connection attempt by \connect command could be also canceled by
>> pressing Ctrl+C on psql prompt.
>>
>> In addition, I tried setting PGCONNECT_TIMEOUT to 0 (infinite), but
>> psql gave up after few seconds, for both start-up and re-
On Mon, Jul 09, 2012 at 02:11:00AM -0400, Tom Lane wrote:
> y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes:
> >> Also, I was under the impression that recent Linux kernels use hugepages
> >> automatically if they can, so I wonder exactly what Andres was testing
> >> on ...
>
> > if you mean the
24 matches
Mail list logo
