On 2014-08-11 12:42:06 +0900, Fujii Masao wrote:
> On Mon, Aug 11, 2014 at 10:48 AM, Tatsuo Ishii wrote:
> >> On Mon, Aug 11, 2014 at 9:23 AM, Tatsuo Ishii wrote:
> >>> We can know the LSN of last committed WAL record on primary by using
> >>> pg_current_xlog_location(). It seems there's no API t
On Mon, Aug 11, 2014 at 1:26 PM, Fujii Masao wrote:
> Thanks for updating the patch! Again I tested the feature and found
something
> wrong. I set synchronous_standby_num to 2 and started three standbys. Two
of
> them are included in synchronous_standby_names, i.e., they are synchronous
> standbys
On Mon, Aug 4, 2014 at 11:41 AM, Dilip kumar wrote:
>
> On 31 July 2014 10:59, Amit kapila Wrote,
>
>
>
> Thanks for the review and valuable comments.
> I have fixed all the comments and attached the revised patch.
I have again looked into your revised patch and would like
to share my findings wi
On Mon, Aug 11, 2014 at 11:54 AM, Michael Paquier
wrote:
> On Mon, Aug 11, 2014 at 1:31 AM, Fujii Masao wrote:
>> On Sat, Aug 9, 2014 at 3:03 PM, Michael Paquier
>> wrote:
>> Great! This is really the feature which I really want.
>> Though I forgot why we missed this feature when
>> we had added
The SO major version should be sufficient for applications to operate
normally. If that isn't the case then I agree that we need to review
the changes we are making to see if the SO should be bumped. Note that
Debian's viewpoint on this is more along the lines of "why build against
an old ver
On Mon, Aug 11, 2014 at 10:48 AM, Tatsuo Ishii wrote:
>> On Mon, Aug 11, 2014 at 9:23 AM, Tatsuo Ishii wrote:
>>> We can know the LSN of last committed WAL record on primary by using
>>> pg_current_xlog_location(). It seems there's no API to know the time
>>> when the WAL record was created. I wo
On Mon, Aug 11, 2014 at 1:31 AM, Fujii Masao wrote:
> On Sat, Aug 9, 2014 at 3:03 PM, Michael Paquier
> wrote:
> Great! This is really the feature which I really want.
> Though I forgot why we missed this feature when
> we had added the synchronous replication feature,
> maybe it's worth reading
> On Mon, Aug 11, 2014 at 9:23 AM, Tatsuo Ishii wrote:
>> We can know the LSN of last committed WAL record on primary by using
>> pg_current_xlog_location(). It seems there's no API to know the time
>> when the WAL record was created. I would like to know standby delay by
>> using pg_last_xact_rep
On Mon, Aug 11, 2014 at 9:23 AM, Tatsuo Ishii wrote:
> We can know the LSN of last committed WAL record on primary by using
> pg_current_xlog_location(). It seems there's no API to know the time
> when the WAL record was created. I would like to know standby delay by
> using pg_last_xact_replay_ti
We can know the LSN of last committed WAL record on primary by using
pg_current_xlog_location(). It seems there's no API to know the time
when the WAL record was created. I would like to know standby delay by
using pg_last_xact_replay_timestamp() and such that API.
If there's no such a API, it wou
Hi,
it's 1AM here, so only a few comments after quickly reading the patch.
On 10.8.2014 23:26, Jeff Davis wrote:
> This patch is requires the Memory Accounting patch, or something
> similar to track memory usage.
I think the patch you sent actually includes the accounting patch. Is
that on purpo
* Noah Misch (n...@leadboat.com) wrote:
> [Due for a new subject line?]
Probably.
> Our grace period for active backends after unclean exit of one of their peers
> is low, milliseconds to seconds. Our grace period for active backends after
> unclean exit of the postmaster is unconstrained. At l
[Due for a new subject line?]
On Sat, Aug 09, 2014 at 08:16:01PM +0200, Andres Freund wrote:
> On 2014-08-09 14:09:36 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2014-08-09 14:00:49 -0400, Tom Lane wrote:
> > >> I don't think it's anywhere near as black-and-white as you guys claim.
http://www.postgresql.org/docs/9.1/static/gin-implementation.html
"""As of PostgreSQL 9.1, NULL key values can be included in the index. Also,
placeholder NULLs are included in the index for indexed items that are NULL
or contain no keys according to extractValue. This allows searches that
should
On Thu, Aug 07, 2014 at 09:39:57AM -0400, Robert Haas wrote:
> On Wed, Aug 6, 2014 at 9:35 PM, Bruce Momjian wrote:
> > On Sun, Jan 12, 2014 at 12:53:40PM -0500, Noah Misch wrote:
> >> Further study revealed a defect in the patch's memory management, and I
> >> have
> >> not gotten around to corr
This patch is requires the Memory Accounting patch, or something similar
to track memory usage.
The attached patch enables hashagg to spill to disk, which means that
hashagg will contain itself to work_mem even if the planner makes a
bad misestimate of the cardinality.
This is a well-known concep
On Fri, 2014-08-08 at 01:16 -0700, Jeff Davis wrote:
> Either way, it's better to be conservative. Attached is a version of the
> patch with opt-in memory usage tracking. Child contexts inherit the
> setting from their parent.
There was a problem with the previous patch: the parent was unlinked
be
On Fri, Aug 8, 2014 at 6:01 AM, Heikki Linnakangas
wrote:
> It's possible that two backends arrive at phase 3 at the same time, with
> different values. For example, backend A wants to update the minimum to
> contain 10, and and backend B wants to update it to 5. Now, if backend B
> gets to update
On Sat, Aug 9, 2014 at 3:03 PM, Michael Paquier
wrote:
> Hi all,
>
> Please find attached a patch to add support of synchronous replication
> for multiple standby servers. This is controlled by the addition of a
> new GUC parameter called synchronous_standby_num, that makes server
> wait for trans
Hi
2014-08-09 10:20 GMT+02:00 Guillaume Lelarge :
> Hi,
>
> Le 9 août 2014 05:57, "Ramirez, Danilo" a
> écrit :
> >
> > Thanks to all for the great info. We are new to postgresql and this
> discussion has both instructed us and increased our respect for the
> database and the community.
> >
>
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2014-08-10 19:48:29 +0800, Craig Ringer wrote:
> > I just had an idea I wanted to run by you all before turning it into a
> > patch.
> >
> > People seem to get confused when they get auth errors because they
> > changed pg_hba.conf but didn't re
From: "Michael Paquier"
Please find attached a patch finishing the work begun during CF1. This
adds versioning support for all the remaining dll and exe files on
both MinGW and MSVC:
- regress.dll (MSVC only)
- isolationtester.exe
- pg_isolation_regress.exe
- pg_regress.exe
- pg_regress_ecpg.exe
Hi,
On 2014-08-10 19:48:29 +0800, Craig Ringer wrote:
> I just had an idea I wanted to run by you all before turning it into a
> patch.
>
> People seem to get confused when they get auth errors because they
> changed pg_hba.conf but didn't reload.
>
> Should we emit a HINT alongside the main aut
On Tue, Aug 5, 2014 at 10:35 PM, David Rowley wrote:
>
> The patch (attached) is also now able to detect when a NOT EXISTS clause
> cannot produce any records at all.
>
>
I've attached an updated version of the patch which fixes up some
incorrect logic in the foreign key matching code, plus vari
Hi all
I just had an idea I wanted to run by you all before turning it into a
patch.
People seem to get confused when they get auth errors because they
changed pg_hba.conf but didn't reload.
Should we emit a HINT alongside the main auth error in that case?
Given the amount of confusion that I s
On 08/10/2014 12:42 PM, Simon Riggs wrote:
On 8 August 2014 16:03, Heikki Linnakangas wrote:
I couldn't resist starting to hack on this, and implemented the scheme I've
been having in mind:
1. MMTuple contains the block number of the heap page (range) that the tuple
represents. Vacuum is no l
On 08/10/2014 12:22 PM, Simon Riggs wrote:
On 8 August 2014 16:03, Heikki Linnakangas wrote:
1. MMTuple contains the block number of the heap page (range) that the tuple
represents. Vacuum is no longer needed to clean up old tuples; when an index
tuples is updated, the old tuple is deleted ato
On 8 August 2014 16:03, Heikki Linnakangas wrote:
> I couldn't resist starting to hack on this, and implemented the scheme I've
> been having in mind:
>
> 1. MMTuple contains the block number of the heap page (range) that the tuple
> represents. Vacuum is no longer needed to clean up old tuples;
On 8 August 2014 10:01, Heikki Linnakangas wrote:
> It's possible that two backends arrive at phase 3 at the same time, with
> different values. For example, backend A wants to update the minimum to
> contain 10, and and backend B wants to update it to 5. Now, if backend B
> gets to update the tu
Hello Andres,
But further benchmarks sound like a good idea.
I've started running some benchmarks with pgbench, with varying block &
WAL block sizes. I've done a blog post on a small subset of results,
focussing on block size with SSDs and to validate the significance of the
figures found,
On 8 August 2014 16:03, Heikki Linnakangas wrote:
> 1. MMTuple contains the block number of the heap page (range) that the tuple
> represents. Vacuum is no longer needed to clean up old tuples; when an index
> tuples is updated, the old tuple is deleted atomically with the insertion of
> a new tu
On 2014-08-10 08:50:58 +0800, Craig Ringer wrote:
> On 08/10/2014 12:54 AM, Andres Freund wrote:
> > On 2014-08-07 21:02:54 -0400, Tom Lane wrote:
> >> Craig Ringer writes:
> >>> On 08/08/2014 03:54 AM, Tom Lane wrote:
> FWIW, I think it's a seriously bad idea to expose LSNs in the protocol
>
On Sun, Aug 10, 2014 at 12:24 PM, Amit Kapila
wrote:
>
> On Fri, Aug 8, 2014 at 11:41 AM, Fujii Masao
wrote:
> >
> > Yep, right. ParseConfigFp() is not good place to pick up data_directory.
> > What about the attached patch which makes ProcessConfigFile() instead of
> > ParseConfigFp() pick up da
33 matches
Mail list logo
