On Fri, Aug 8, 2014 at 11:41 AM, Fujii Masao masao.fu...@gmail.com 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 data_directory just after the configuration file
On Sun, Aug 10, 2014 at 12:24 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Fri, Aug 8, 2014 at 11:41 AM, Fujii Masao masao.fu...@gmail.com
wrote:
Yep, right. ParseConfigFp() is not good place to pick up data_directory.
What about the attached patch which makes ProcessConfigFile()
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 cr...@2ndquadrant.com 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
On 8 August 2014 16:03, Heikki Linnakangas hlinnakan...@vmware.com 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
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 10:01, Heikki Linnakangas hlinnakan...@vmware.com 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
On 8 August 2014 16:03, Heikki Linnakangas hlinnakan...@vmware.com 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
On 08/10/2014 12:22 PM, Simon Riggs wrote:
On 8 August 2014 16:03, Heikki Linnakangas hlinnakan...@vmware.com 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
On 08/10/2014 12:42 PM, Simon Riggs wrote:
On 8 August 2014 16:03, Heikki Linnakangas hlinnakan...@vmware.com 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
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
On Tue, Aug 5, 2014 at 10:35 PM, David Rowley dgrowle...@gmail.com 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
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 auth
From: Michael Paquier michael.paqu...@gmail.com
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
-
* 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 reload.
Hi
2014-08-09 10:20 GMT+02:00 Guillaume Lelarge guilla...@lelarge.info:
Hi,
Le 9 août 2014 05:57, Ramirez, Danilo danilo.rami...@hmhco.com 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
On Sat, Aug 9, 2014 at 3:03 PM, Michael Paquier
michael.paqu...@gmail.com 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
On Fri, Aug 8, 2014 at 6:01 AM, Heikki Linnakangas
hlinnakan...@vmware.com 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
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
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
On Thu, Aug 07, 2014 at 09:39:57AM -0400, Robert Haas wrote:
On Wed, Aug 6, 2014 at 9:35 PM, Bruce Momjian br...@momjian.us 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
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
[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 and...@2ndquadrant.com 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
* 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
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
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
On Mon, Aug 11, 2014 at 9:23 AM, Tatsuo Ishii is...@postgresql.org 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
On Mon, Aug 11, 2014 at 9:23 AM, Tatsuo Ishii is...@postgresql.org 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
On Mon, Aug 11, 2014 at 1:31 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Sat, Aug 9, 2014 at 3:03 PM, Michael Paquier
michael.paqu...@gmail.com 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
On Mon, Aug 11, 2014 at 10:48 AM, Tatsuo Ishii is...@postgresql.org wrote:
On Mon, Aug 11, 2014 at 9:23 AM, Tatsuo Ishii is...@postgresql.org 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 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
On Mon, Aug 11, 2014 at 11:54 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Mon, Aug 11, 2014 at 1:31 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Sat, Aug 9, 2014 at 3:03 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
Great! This is really the feature which I really want.
On Mon, Aug 4, 2014 at 11:41 AM, Dilip kumar dilip.ku...@huawei.com 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
On Mon, Aug 11, 2014 at 1:26 PM, Fujii Masao masao.fu...@gmail.com 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
33 matches
Mail list logo
