Folks,
Please find attached a patch implementing and documenting, to some
extent, $subject. I did this in aid of being able to import SQL
standard catalogs and other entities where a known example could
provide a template for a foreign table.
Should there be errhint()s, too? Should we pile up
On Tue, Oct 8, 2013 at 4:57 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Oct 5, 2013 at 8:10 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
Here is the test case failing:
=# create sequence foo;
CREATE SEQUENCE
=# select nextval('foo');
nextval
-
1
(1 row)
***
/home/kgrittn/pg/master/src/test/isolation/expected/drop-index-concurrently-1.out
2013-07-10 14:58:41.641205557 -0500
---
/home/kgrittn/pg/master/src/test/isolation/results/drop-index-concurrently-1.out
2013-10-07 12:20:49.269277851 -0500
***
*** 30,40
id
Sent from my iPad
On 08-Oct-2013, at 10:41, Claudio Freire klaussfre...@gmail.com wrote:
On Tue, Oct 8, 2013 at 1:23 AM, Atri Sharma atri.j...@gmail.com wrote:
Consider the aspects associated with open addressing.Open addressing
can quickly lead to growth in the main table.Also, chaining
On Fri, Oct 4, 2013 at 4:32 PM, Fujii Masao masao.fu...@gmail.com wrote:
You added several checks into SyncRepWaitForLSN() so that it can handle both
synchronous_transfer=data_flush and =commit. This change made the source code
of the function very complicated, I'm afraid. To simplify the
On 8 Říjen 2013, 6:23, Atri Sharma wrote:
Hi Tomas,
Consider the aspects associated with open addressing.Open addressing
can quickly lead to growth in the main table.Also, chaining is a much
cleaner way of collision resolution,IMHO.
What do you mean by growth in the main table?
Sorry, I
On Tue, Oct 8, 2013 at 2:33 PM, Sawada Masahiko sawada.m...@gmail.comwrote:
On Fri, Oct 4, 2013 at 4:32 PM, Fujii Masao masao.fu...@gmail.com wrote:
I attached the v12 patch which have modified based on above suggestions.
There are still some parts of this design/patch which I am concerned
Heikki Linnakangas hlinnakan...@vmware.com wrote:
A comment somewhere would be nice to explain why we're no longer worried
about confusing an old tuple version with a new tuple in the same slot.
Not sure where.
For now I counted on the commit message. Perhaps we also want to
add something to
Sent from my iPad
However I'm unable to make it at least comparable to chaining. The trick
is that the hash table performs reasonably only until it's ~ 65-70% full,
it gets really slow after that. So to maintain performance comparable to
chaining, I'd have to keep the table below this
On 10/7/13 9:46 PM, Robert Haas wrote:
Looks good to me. Committed.
Thanks.
Also huge thanks to Ian for a phenomenal first review. :-)
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 2013-10-08 15:07:02 +0530, Pavan Deolasee wrote:
On Tue, Oct 8, 2013 at 2:33 PM, Sawada Masahiko sawada.m...@gmail.comwrote:
On Fri, Oct 4, 2013 at 4:32 PM, Fujii Masao masao.fu...@gmail.com wrote:
I attached the v12 patch which have modified based on above suggestions.
There are
(2013/10/08 17:33), Haribabu kommi wrote:
The checkpoint_timeout and checkpoint_segments are increased to make sure no
checkpoint happens during the test run.
Your setting is easy occurred checkpoint in checkpoint_segments = 256. I don't
know number of disks in your test server, in my test
On 2013-09-11 12:43:21 +0200, Andres Freund wrote:
On 2013-09-11 19:39:14 +0900, Fujii Masao wrote:
* Benchmark
pgbench -c 32 -j 4 -T 900 -M prepared
scaling factor: 100
checkpoint_segments = 1024
checkpoint_timeout = 5min
(every checkpoint during benchmark were triggered
On Tue, Oct 8, 2013 at 3:16 PM, Andres Freund and...@2ndquadrant.comwrote:
It is my impression that there still are several people having pretty
fundamental doubts about this approach in general. From what I remember
neither Heikki, Simon, Tom nor me were really convinced about this
On 8 Říjen 2013, 11:42, Atri Sharma wrote:
I've made some significant improvements in the chaining version (in the
master branch), now getting about the memory consumption I've estimated.
I agree, we can hope to reduce the memory consumption by making changes in
the current chaining
I had got this message while running vacuum full from backend . Now My
database is not starting , Help pls.
backend vacuum full debug;
WARNING: database debug must be vacuumed within 99 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
debug.
ERROR:
On 08 October 2013 15:22 KONDO Mitsumasa wrote:
(2013/10/08 17:33), Haribabu kommi wrote:
The checkpoint_timeout and checkpoint_segments are increased to make sure no
checkpoint happens during the test run.
Your setting is easy occurred checkpoint in checkpoint_segments = 256. I don't
know
On Tue, Oct 8, 2013 at 1:34 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Oct 7, 2013 at 12:41 AM, Rushabh Lathia
rushabh.lat...@gmail.com wrote:
Hmm right it has some inconsistency when year length is 6. But the patch
is based on assumption that 5-digit number is a year, because YMD
On Tue, Oct 8, 2013 at 4:15 PM, Tomas Vondra t...@fuzzy.cz wrote:
On 8 Říjen 2013, 11:42, Atri Sharma wrote:
I've made some significant improvements in the chaining version (in the
master branch), now getting about the memory consumption I've estimated.
I agree, we can hope to reduce the
On Sat, Oct 5, 2013 at 6:10 PM, Noah Misch n...@leadboat.com wrote:
The sum of the squares of the latencies wraps after 2^63/(10^12 * avg_latency
* nclients) seconds. That's unlikely to come up with the ordinary pgbench
script, but one can reach it in a few hours when benchmarking a command
On 10/07/2013 11:34 PM, Amit Kapila wrote:
On Tue, Oct 8, 2013 at 12:55 AM, Andrew Dunstan and...@dunslane.net wrote:
On 10/07/2013 03:06 PM, Robert Haas wrote:
Also if your use case is to treat empty strings as NULL (as per above
documentation), can't it be handled with WITH NULL AS
On 10/08/2013 03:55 AM, shailesh singh wrote:
I had got this message while running vacuum full from backend . Now My
database is not starting , Help pls.
backend vacuum full debug;
WARNING: database debug must be vacuumed within 99 transactions
HINT: To avoid a database shutdown, execute
Hi,
I tested dbt-2 benchmark in single instance and synchronous replication.
Unfortunately, my benchmark results were not seen many differences...
* Test server
Server: HP Proliant DL360 G7
CPU:Xeon E5640 2.66GHz (1P/4C)
Memory: 18GB(PC3-10600R-9)
Disk: 146GB(15k)*4 RAID1+0
On Tue, Oct 8, 2013 at 05:08:17PM +0530, Rushabh Lathia wrote:
This
might be a case where throwing an error is actually better than trying
to make sense of the input.
I don't feel super-strongly about this, but I offer it as a question
for reflection.
At the same
(2013/10/08 20:13), Haribabu kommi wrote:
I chosen the sync_commit=off mode because it generates more tps, thus it
increases the volume of WAL.
I did not think to there. Sorry...
I will test with sync_commit=on mode and provide the test results.
OK. Thanks!
--
Mitsumasa KONDO
NTT Open
On 10/07/2013 08:47 PM, Peter Eisentraut wrote:
I suspect this line
submake-libpq: $(libdir)/libpq.so ;
will cause problems on platforms with a different extension (e.g. OS X).
suggested fix is below.
cheers
andrew
diff --git a/src/Makefile.global.in b/src/Makefile.global.in
index
Heikki Linnakangas hlinnakan...@vmware.com wrote:
On 07.10.2013 23:45, Heikki Linnakangas wrote:
To fix the bug that Hannu pointed out, we also need to apply these fixes:
http://www.postgresql.org/message-id/52440266.5040...@vmware.com
Per a chat with Bruce, I'm going to apply that patch
On Tue, Oct 8, 2013 at 01:25:30PM +0900, KONDO Mitsumasa wrote:
(2013/10/08 10:35), Bruce Momjian wrote:
docs: update release notes for 8.4.18, 9.0.14, 9.1.10, 9.2.5, 9.3.1
Thank you for creating good release note. I have one comment.
In 9.1 and 9.2 release note, Is Improve WAL segment
On 8 Říjen 2013, 13:52, Atri Sharma wrote:
On Tue, Oct 8, 2013 at 4:15 PM, Tomas Vondra t...@fuzzy.cz wrote:
On 8 Říjen 2013, 11:42, Atri Sharma wrote:
I've made some significant improvements in the chaining version (in
the
master branch), now getting about the memory consumption I've
Hi, Tomas!
On Sun, Oct 6, 2013 at 3:58 AM, Tomas Vondra t...@fuzzy.cz wrote:
I've attempted to rerun the benchmarks tests I did a few weeks ago, but
I got repeated crashes when loading the data (into a table with
tsvector+gin index).
Right before a crash, theres this message in the log:
Dear all,
First of all i wish to share actual error meassge,
Below are the queries i had executed on the terminal on my server
-bash-3.2$ touch fix.sql
-bash-3.2$ echo VACUUM FULL; fix.sql
-bash-3.2$ postgres -D /var/lib/pgsql/data patnadbold fix.sql
WARNING: database patnadbold must be
On 10/08/2013 08:03 AM, shailesh singh wrote:
Dear all,
First of all i wish to share actual error meassge,
Below are the queries i had executed on the terminal on my server
-bash-3.2$ touch fix.sql
-bash-3.2$ echo VACUUM FULL; fix.sql
-bash-3.2$ postgres -D /var/lib/pgsql/data patnadbold
Hi,
Thanks for your review, sorry about the delays in answering, I've been
quite busy with other matters recently, it seems like things are going
to be smoother this week.
Peter Eisentraut pete...@gmx.net writes:
Review of the PL/Tcl part: The functionality looks OK. There are some
cosmetic
On 08.10.2013 13:00, Pavan Deolasee wrote:
On Tue, Oct 8, 2013 at 3:16 PM, Andres Freundand...@2ndquadrant.comwrote:
It is my impression that there still are several people having pretty
fundamental doubts about this approach in general. From what I remember
neither Heikki, Simon, Tom nor me
*Don't* VACUUM FULL. Just VACUUM. It's not the same thing.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Sep 5, 2013 at 05:14:37PM -0400, Bruce Momjian wrote:
On Thu, Sep 5, 2013 at 06:14:33PM +0200, Magnus Hagander wrote:
I have developed the attached patch which implements an auto-tuned
effective_cache_size which is 4x the size of shared buffers. I had to
set
On Mon, Oct 7, 2013 at 9:32 AM, Andres Freund and...@2ndquadrant.com wrote:
- RelationIsDoingTimetravel is still a crappy name. How about
RelationRequiredForLogicalDecoding? And maybe the reloption
treat_as_catalog_table can become required_for_logical_decoding.
Hm. I don't really like the
On Tue, Sep 24, 2013 at 05:36:58PM -0400, Bruce Momjian wrote:
On Tue, Sep 17, 2013 at 10:15:47AM -0400, Robert Haas wrote:
On Sat, Sep 14, 2013 at 9:42 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I have developed the attached patch based on your suggestion. I did not
see
On Mon, Oct 7, 2013 at 4:47 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-10-07 13:25:17 -0400, Robert Haas wrote:
On Fri, Oct 4, 2013 at 8:19 AM, Andres Freund and...@2ndquadrant.com wrote:
Could it be that MAXALIGN/TYPEALIGN doesn't really work for values
bigger than 32bit?
On Mon, Oct 7, 2013 at 7:51 AM, Andrew Dunstan
andrew.duns...@pgexperts.com wrote:
Given that we have not supported releases older than 8.3 for quite a while,
do we need to keep this in extend.sgml any longer?
+1 for removing that (but only in master, not the back-branches).
--
Robert Haas
The commit below, specifically the change mentioned in the last paragraph
to fix isLockedRel broke the following comment in addRangeTableEntry:
* If pstate is NULL, we just build an RTE and return it without adding it
* to an rtable list.
In fact isLockedRefname() will seg fault promptly if
On Tue, Oct 8, 2013 at 8:33 AM, Andrew Dunstan and...@dunslane.net wrote:
On 10/07/2013 11:34 PM, Amit Kapila wrote:
On Tue, Oct 8, 2013 at 12:55 AM, Andrew Dunstan and...@dunslane.net
wrote:
On 10/07/2013 03:06 PM, Robert Haas wrote:
Also if your use case is to treat empty strings as NULL
2013/10/8 Bruce Momjian br...@momjian.us
On Tue, Sep 24, 2013 at 05:36:58PM -0400, Bruce Momjian wrote:
On Tue, Sep 17, 2013 at 10:15:47AM -0400, Robert Haas wrote:
On Sat, Sep 14, 2013 at 9:42 AM, Pavel Stehule
pavel.steh...@gmail.com wrote:
I have developed the attached patch based
On Tue, Oct 8, 2013 at 06:31:03PM +0200, Pavel Stehule wrote:
2013/10/8 Bruce Momjian br...@momjian.us
On Tue, Sep 24, 2013 at 05:36:58PM -0400, Bruce Momjian wrote:
On Tue, Sep 17, 2013 at 10:15:47AM -0400, Robert Haas wrote:
On Sat, Sep 14, 2013 at 9:42 AM, Pavel
2013/10/8 Bruce Momjian br...@momjian.us
On Tue, Oct 8, 2013 at 06:31:03PM +0200, Pavel Stehule wrote:
2013/10/8 Bruce Momjian br...@momjian.us
On Tue, Sep 24, 2013 at 05:36:58PM -0400, Bruce Momjian wrote:
On Tue, Sep 17, 2013 at 10:15:47AM -0400, Robert Haas wrote:
On Mon, Oct 7, 2013 at 12:32 PM, Marc Cousin cousinm...@gmail.com wrote:
I was using the lo contrib a few days ago and wasn't paying attention, and
forgot the for each row in the create trigger command... PostgreSQL
segfaulted, when the trigger tried to access the row's attributes.
Please
On Tue, Oct 8, 2013 at 06:38:30PM +0200, Pavel Stehule wrote:
I am not sure - does pg_upgrade change of flag after upgrade without
increasing
version number?
What happens in pg_upgrade is that the CREATE EXTENSION command is
pg_dump'ed, and run by pg_uprade, and it then pulls from the SQL
On 10/08/2013 12:30 PM, Robert Haas wrote:
On Tue, Oct 8, 2013 at 8:33 AM, Andrew Dunstan and...@dunslane.net wrote:
On 10/07/2013 11:34 PM, Amit Kapila wrote:
On Tue, Oct 8, 2013 at 12:55 AM, Andrew Dunstan and...@dunslane.net
wrote:
On 10/07/2013 03:06 PM, Robert Haas wrote:
Also if your
2013/10/8 Bruce Momjian br...@momjian.us
On Tue, Oct 8, 2013 at 06:38:30PM +0200, Pavel Stehule wrote:
I am not sure - does pg_upgrade change of flag after upgrade without
increasing
version number?
What happens in pg_upgrade is that the CREATE EXTENSION command is
pg_dump'ed, and run
On Tuesday 08 October 2013 12:28:46 Robert Haas wrote:
On Mon, Oct 7, 2013 at 12:32 PM, Marc Cousin cousinm...@gmail.com wrote:
I was using the lo contrib a few days ago and wasn't paying attention, and
forgot the for each row in the create trigger command... PostgreSQL
segfaulted, when the
Bruce Momjian escribió:
Do we need to update any version or anything? I didn't think so.
I think there should be an 1.1 version here. That way, if somebody is
using the existing definition from the 1.0 module, they can get the new
definition by doing an extension upgrade.
--
Álvaro Herrera
On Tue, Oct 8, 2013 at 02:25:25PM -0300, Alvaro Herrera wrote:
Bruce Momjian escribió:
Do we need to update any version or anything? I didn't think so.
I think there should be an 1.1 version here. That way, if somebody is
using the existing definition from the 1.0 module, they can get
Bruce Momjian escribió:
On Tue, Oct 8, 2013 at 02:25:25PM -0300, Alvaro Herrera wrote:
Bruce Momjian escribió:
Do we need to update any version or anything? I didn't think so.
I think there should be an 1.1 version here. That way, if somebody is
using the existing definition
On 10/08/2013 12:47 PM, Andrew Dunstan wrote:
On 10/08/2013 12:30 PM, Robert Haas wrote:
Andrew, are you planning to review commit this?
Yes.
Incidentally, the patch doesn't seem to add the option to file_fdw,
which I really think it should.
cheers
andrew
--
Sent via
On 04.10.2013 14:13, Alexander Korotkov wrote:
On Fri, Oct 4, 2013 at 12:28 PM, Heikki Linnakangashlinnakan...@vmware.com
wrote:
In the attached patch, I in fact already did that for data leaf pages, but
didn't change the format of non-leaf pages yet. If we want to support
pg_upgrade, we
On Oct 8, 2013 6:27 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Oct 7, 2013 at 7:51 AM, Andrew Dunstan
andrew.duns...@pgexperts.com wrote:
Given that we have not supported releases older than 8.3 for quite a
while,
do we need to keep this in extend.sgml any longer?
+1 for
On 10/07/2013 09:32 AM, Andres Freund wrote:
Todo:
* rename treat_as_catalog_table, after agreeing on the new name
* rename remaining timetravel function names
* restrict SuspendDecodingSnapshots usage to RelationInitPhysicalAddr,
that ought to be enough.
* add InLogicalDecoding() function.
*
The patch contains a small typo in config.sgml. Probably just drop the
is from is can.
+results if this database cluster is can utilize most of the memory
Kevin.
On 8 October 2013 10:13, Bruce Momjian br...@momjian.us wrote:
On Thu, Sep 5, 2013 at 05:14:37PM -0400, Bruce Momjian
Although I asked this question, I've reconsidered about these parameters, and it
seems that these parameters not only make code rather complex but are a little
confusing to users. So I'd like to propose to introduce only one parameter:
fast_cache_size. While users that give weight to update
On Thu, Sep 26, 2013 at 9:27 AM, Noah Misch n...@leadboat.com wrote:
There's no data corruption problem if we proceed - but there likely
has been one leading to the current state.
+1 for making this one a PANIC, though. With startup behind us, a valid dsm
state file pointed us to a control
On 2013-10-08 15:02:39 -0400, Steve Singer wrote:
On 10/07/2013 09:32 AM, Andres Freund wrote:
Todo:
* rename treat_as_catalog_table, after agreeing on the new name
* rename remaining timetravel function names
* restrict SuspendDecodingSnapshots usage to RelationInitPhysicalAddr,
that
On 2013-10-08 12:20:22 -0400, Robert Haas wrote:
On Mon, Oct 7, 2013 at 9:32 AM, Andres Freund and...@2ndquadrant.com wrote:
- RelationIsDoingTimetravel is still a crappy name. How about
RelationRequiredForLogicalDecoding? And maybe the reloption
treat_as_catalog_table can become
On 08.10.2013 17:47, Alexander Korotkov wrote:
Hi, Tomas!
On Sun, Oct 6, 2013 at 3:58 AM, Tomas Vondrat...@fuzzy.cz wrote:
I've attempted to rerun the benchmarks tests I did a few weeks ago, but
I got repeated crashes when loading the data (into a table with
tsvector+gin index).
Right
On 2013-10-08 15:40:04 -0400, Robert Haas wrote:
I am tempted to commit the latest version of this patch as I have it.
I haven't looked at the latest version of the patch, but based on the
previous version I have no problem with that.
If you'd feel more comfortable with another round of review,
Kevin Grittner kgri...@ymail.com wrote:
[ isolation test failed at snapshot-based isolation levels ]
Fix pushed, that looks for the right results based on isolation level.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing
On 2013-10-08 12:26:17 -0400, Robert Haas wrote:
On Mon, Oct 7, 2013 at 4:47 PM, Andres Freund and...@2ndquadrant.com wrote:
So I guess it's either a separate macro, or we rewrite that piece of
code to work slightly differently and work directly on the lenght or
such.
Maybe we should
2013/10/9 Andrew Dunstan and...@dunslane.net:
On 10/08/2013 12:47 PM, Andrew Dunstan wrote:
On 10/08/2013 12:30 PM, Robert Haas wrote:
Andrew, are you planning to review commit this?
Yes.
Incidentally, the patch doesn't seem to add the option to file_fdw, which I
really think it
On Tue, Oct 8, 2013 at 01:04:18PM -0600, Kevin Hale Boyes wrote:
The patch contains a small typo in config.sgml. Probably just drop the is
from is can.
+results if this database cluster is can utilize most of the memory
Kevin.
Thank you, fixed.
--
Bruce Momjian
On 8.10.2013 21:59, Heikki Linnakangas wrote:
On 08.10.2013 17:47, Alexander Korotkov wrote:
Hi, Tomas!
On Sun, Oct 6, 2013 at 3:58 AM, Tomas Vondrat...@fuzzy.cz wrote:
I've attempted to rerun the benchmarks tests I did a few weeks ago, but
I got repeated crashes when loading the data
On Tue, Oct 08, 2013 at 03:40:04PM -0400, Robert Haas wrote:
On Thu, Sep 26, 2013 at 9:27 AM, Noah Misch n...@leadboat.com wrote:
There's no data corruption problem if we proceed - but there likely
has been one leading to the current state.
+1 for making this one a PANIC, though. With
On Tue, Oct 8, 2013 at 6:03 PM, Andrew Dunstan and...@dunslane.net wrote:
On 10/07/2013 11:34 PM, Amit Kapila wrote:
On Tue, Oct 8, 2013 at 12:55 AM, Andrew Dunstan and...@dunslane.net
wrote:
On 10/07/2013 03:06 PM, Robert Haas wrote:
Also if your use case is to treat empty strings as
Hi,
In the release notes for 9.2.5,
Should the following:
Fix rare GROUP BY query error caused by improperly processed date
type modifiers (Tom Lane)
be:
Fix rare GROUP BY query error caused by improperly processed *data*
type modifiers (Tom Lane)
Assuming the change has to do with the
On Wed, Oct 9, 2013 at 5:26 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Oct 7, 2013 at 4:47 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2013-10-07 13:25:17 -0400, Robert Haas wrote:
On Fri, Oct 4, 2013 at 8:19 AM, Andres Freund and...@2ndquadrant.com
wrote:
Could it be
Where did this patch come from?
I think part of that patch should be reverted, but I can't find the
original submission for the rationale.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Thu, 2013-10-03 at 17:50 +0530, Jeevan Chalke wrote:
Will you please attach new patch with above block removed ? Then I
will quickly check that new patch and mark as Ready For Committer.
Here you go.
From ba421c778cc3f7c32886ac038389cfbad3c0df67 Mon Sep 17 00:00:00 2001
From: Peter
75 matches
Mail list logo
