On Thu, Aug 14, 2014 at 02:50:02AM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
On Wed, Aug 13, 2014 at 10:21:50AM -0400, Tom Lane wrote:
I believe that we deal with this by the expedient of checking the lengths
of tablespace paths in advance, when the tablespace is created.
On Thu, Aug 14, 2014 at 8:34 PM, Fujii Masao masao.fu...@gmail.com wrote:
+At any one time there will be at a number of active
synchronous standbys
+defined by varnamesynchronous_standby_num/; transactions waiting
It's better to use xref linkend=guc-synchronous-standby-num,
On 08/15/2014 02:02 AM, Alvaro Herrera wrote:
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
I'm sure this still needs some cleanup, but here's the patch, based
on your v14. Now that I know what this approach looks like, I still
like it much better. The insert and update code is somewhat
Thank you. The code looks correct. I confirmed that the pg_basebackup
could relocate the tablespace directory on Windows.
I marked this patch as ready for committer.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Mon, Aug 11, 2014 at 10:48 PM, Noah Misch n...@leadboat.com wrote:
Consistency with the MSVC build is desirable, either HAVE_GETADDRINFO for both
or !HAVE_GETADDRINFO for both.
Hm. Looking here getattrinfo has been added in ws2_32 and was not
present in wsock32:
On 08/15/2014 10:26 AM, Heikki Linnakangas wrote:
On 08/15/2014 02:02 AM, Alvaro Herrera wrote:
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
I'm sure this still needs some cleanup, but here's the patch, based
on your v14. Now that I know what this approach looks like, I still
like it
Actually I came up with the same need as Magnus, but a bit later, so...
Attached is a patch to support physical slot creation and drop in
pg_receivexlog with the addition of new options --create and --drop. It
would be nice to have that in 9.4, but I will not the one deciding that
at the end
Hi
On Thu, May 8, 2014 at 4:28 PM, Andres Freund and...@2ndquadrant.com wrote:
Ok. A new version of the patches implementing that are
attached. Including a couple of small fixups and docs. The latter aren't
extensive, but that doesn't seem to be warranted anyway.
Is it really actually useful
Thanks for your review.
On Fri, Aug 15, 2014 at 12:56 AM, furu...@pm.nttdata.co.jp wrote:
At consistency with pg_recvlogical, do you think about --start?
I did not add that for the sake of backward-compatibility as in
pg_recvlogical an action is mandatory. It is not the case now of
On 2014-08-15 11:12:11 +0300, Marti Raudsepp wrote:
Hi
On Thu, May 8, 2014 at 4:28 PM, Andres Freund and...@2ndquadrant.com wrote:
Ok. A new version of the patches implementing that are
attached. Including a couple of small fixups and docs. The latter aren't
extensive, but that doesn't
On 2014-08-14 22:16:31 -0700, Michael Paquier wrote:
And here are some comments about patch 2:
- Patch applies with some hunks.
- Some typos are present
s#memory segments..#memory segments. (double dots)
s#NULL#literalNULL/ (in the docs as this refers to a value)
Will fix.
- Your thoughts
On 2014-08-14 12:21:38 -0400, Robert Haas wrote:
On Sat, Aug 9, 2014 at 12:54 PM, Andres Freund and...@2ndquadrant.com wrote:
I don't think we really need to embed it at that level. And it doesn't
have to be always on - only clients that ask for it need to get the
answer. Something like
Hi,
On 8/8/14 3:18 PM, I wrote:
Currently there's no way to generate or extract armor headers from the
PGP armored format in pgcrypto. I've written a patch to add the
support.
Latest version of the patch here, having fixed some small coding issues.
.marko
*** a/contrib/pgcrypto/Makefile
On 7/16/14 4:33 PM, Tom Lane wrote:
Rajeev rastogi rajeev.rast...@huawei.com writes:
I found and fixed a bug that causes recovery (crash recovery , PITR) to throw
unwanted LOG message if the tablespace symlink is not found during the
processing of DROP TABLESPACE redo.
After publishing some test results with pgbench on SSD with varying page
size, Josh Berkus pointed out that pgbench uses small 100-bytes tuples,
and that results may be different with other tuple sizes.
This patch adds an option to change the default tuple size, so that this
can be tested
On 2014-08-15 11:46:52 +0200, Fabien COELHO wrote:
After publishing some test results with pgbench on SSD with varying page
size, Josh Berkus pointed out that pgbench uses small 100-bytes tuples, and
that results may be different with other tuple sizes.
This patch adds an option to change
Hello Andres,
This patch adds an option to change the default tuple size, so that this can
be tested easily.
I don't think it's beneficial to put this into pgbench. There really
isn't a relevant benefit over using a custom script here.
The scripts to run are the standard ones. The
On 2014-08-15 11:58:41 +0200, Fabien COELHO wrote:
Hello Andres,
This patch adds an option to change the default tuple size, so that this can
be tested easily.
I don't think it's beneficial to put this into pgbench. There really
isn't a relevant benefit over using a custom script here.
I don't think it's beneficial to put this into pgbench. There really
isn't a relevant benefit over using a custom script here.
The scripts to run are the standard ones. The difference is in the
*initialization* phase (-i), namely the filler attribute size. There is no
custom script for
On 2014-08-15 12:17:31 +0200, Fabien COELHO wrote:
I don't think it's beneficial to put this into pgbench. There really
isn't a relevant benefit over using a custom script here.
The scripts to run are the standard ones. The difference is in the
*initialization* phase (-i), namely the
On Fri, Aug 15, 2014 at 3:40 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-08-14 14:37:22 -0400, Robert Haas wrote:
On Thu, Aug 14, 2014 at 2:21 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-08-14 14:19:13 -0400, Robert Haas wrote:
That's about the idea. However, what
I'm not sure about the implication of ALTER on the table storage,
Should be fine in this case. But if that's what you're concerned about -
understandably -
Indeed, my (long) experience with benchmarks is that it is a much more
complicated that it looks if you want to really understand what
On 2014-08-15 13:33:20 +0200, Fabien COELHO wrote:
it seems to make more sense to split -i into two. One to create the
tables, and another to fill them. That'd allow to do manual stuff
inbetween.
Hmmm. This would mean much more changes than the pretty trivial patch I
submitted
FWIW, I find
On Fri, Aug 15, 2014 at 4:05 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Thu, Aug 14, 2014 at 8:34 PM, Fujii Masao masao.fu...@gmail.com wrote:
+At any one time there will be at a number of active
synchronous standbys
+defined by varnamesynchronous_standby_num/;
On Fri, Aug 15, 2014 at 8:36 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-08-15 13:33:20 +0200, Fabien COELHO wrote:
it seems to make more sense to split -i into two. One to create the
tables, and another to fill them. That'd allow to do manual stuff
inbetween.
Hmmm. This would
On Thu, Aug 14, 2014 at 6:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
We really should not be making changes of this type less than a month
from our ostensible release date. That is not enough time for us to
notice if the changes turn out to be not as
http://www.postgresql.org/message-id/blu436-smtp12682d628f61ab9736099c3dc...@phx.gbl
recalls me that I also saw an assertion failure recently. Although I
wanted to isolate and report my issue when my vacation is over, this
report made me curious whether I saw the same. Eventually it seems to be
a
On Fri, Aug 15, 2014 at 8:02 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
I'm sure this still needs some cleanup, but here's the patch, based
on your v14. Now that I know what this approach looks like, I still
like it much better. The
On 2014-08-15 14:53:45 +0200, Antonin Houska wrote:
http://www.postgresql.org/message-id/blu436-smtp12682d628f61ab9736099c3dc...@phx.gbl
recalls me that I also saw an assertion failure recently. Although I
wanted to isolate and report my issue when my vacation is over, this
report made me
Hmmm. This would mean much more changes than the pretty trivial patch I
submitted
FWIW, I find that patch really ugly. Adding the filler's with in a
printf, after the actual DDL declaration. Without so much as a
comment. Brr.
Indeed. I'm not too proud of that very point either:-) You are
On Thu, Aug 14, 2014 at 12:08 PM, Baker, Keith [OCDUS Non-JJ]
kbak...@its.jnj.com wrote:
I tried a combination of PIPE lock and file lock (fcntl) as Tom had suggested.
Attached experimental patch has this logic...
Postmaster :
- get exclusive fcntl lock (to guard against race condition in
On Tue, Jul 15, 2014 at 12:20 AM, Christoph Martin
christoph.r.mar...@gmail.com wrote:
True. Both variants are legal, and most people won't ever notice. I stumbled
across this while writing a test case for a transaction helper that
sets/restores search_path before committing. The test was to
On 2014-08-14 16:03:08 -0400, Steve Singer wrote:
I hit the following on 9.4 testing logical decoding.
TRAP: FailedAssertion(!(prev_first_lsn cur_txn-first_lsn), File:
reorderbuffer.c, Line: 618)
LOG: server process (PID 3801) was terminated by signal 6: Aborted
I saw that recently
Andres Freund and...@2ndquadrant.com writes:
On 2014-08-14 12:21:38 -0400, Robert Haas wrote:
And what does that actually do? Send back a result-set, or a new
protocol message?
What I was thinking of was to return COMMIT X/X instead of
COMMIT. Since that's only sent when COMMIT WITH
Robert Haas robertmh...@gmail.com writes:
On Thu, Aug 14, 2014 at 6:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If it weren't for the fact that we'll be wedded forevermore to a bad
choice of syntax, I might agree with you. But at this point, the
alternatives we have are to fix it now, or fix it
On Fri, Aug 15, 2014 at 10:40:59PM +0900, Fujii Masao wrote:
Heh. I'm not particularly averse to changing this, but I guess I
don't see any particular benefit of changing it either. Either comma
or comma-space is a legal separator, so why worry about it?
This change might cause me to
On 2014-08-15 09:54:01 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-08-14 12:21:38 -0400, Robert Haas wrote:
And what does that actually do? Send back a result-set, or a new
protocol message?
What I was thinking of was to return COMMIT X/X instead of
On 08/15/2014 09:42 AM, Andres Freund wrote:
On 2014-08-14 16:03:08 -0400, Steve Singer wrote:
I hit the following on 9.4 testing logical decoding.
TRAP: FailedAssertion(!(prev_first_lsn cur_txn-first_lsn), File:
reorderbuffer.c, Line: 618)
LOG: server process (PID 3801) was terminated by
On Thu, Aug 14, 2014 at 1:52 PM, MauMau maumau...@gmail.com wrote:
I fixed some minor mistakes.
What's the main purpose of this tool? If it's for WAL archiving, the tool name
pg_copy sounds too generic. We already have pg_archivecleanup, so maybe
pg_archivecopy or something is better for the
Hi
2014-08-14 9:03 GMT+02:00 Heikki Linnakangas hlinnakan...@vmware.com:
On 08/14/2014 06:53 AM, Joachim Wieland wrote:
I'm seeing an assertion failure with pg_dump -c --if-exists which is
not ready to handle BLOBs it seems:
pg_dump: pg_backup_archiver.c:472: RestoreArchive: Assertion
Fujii Masao masao.fu...@gmail.com wrote:
Direct I/O and posix_fadvise are used only for destination file.
But why not source file? That might be useful especially for
restore_command case.
That would prevent people from piping the file through a
compression utility. We should support piped
On Thu, Aug 14, 2014 at 10:03:57AM +0300, Heikki Linnakangas wrote:
On 08/14/2014 06:53 AM, Joachim Wieland wrote:
I'm seeing an assertion failure with pg_dump -c --if-exists which is
not ready to handle BLOBs it seems:
pg_dump: pg_backup_archiver.c:472: RestoreArchive: Assertion `mark !=
Robert Haas robertmh...@gmail.com writes:
How about this locking protocol:
Postmaster:
1. Acquire an exclusive lock on some file in the data directory, maybe
the control file, using fcntl().
2. Open the named pipe for read.
3. Open the named pipe for write.
4. Close the named pipe for
On 08/15/2014 03:16 PM, Andres Freund wrote:
On 2014-08-15 14:53:45 +0200, Antonin Houska wrote:
postgres=# SELECT pg_create_logical_replication_slot('my_slot',
'test_decoding');
pg_create_logical_replication_slot
(my_slot,0/16F3B30)
(1 row)
On Tue, Aug 12, 2014 at 10:52 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 08/06/2014 08:37 PM, Jeff Janes wrote:
But now it looks like 0002 needs a rebase
I've committed the refactoring patch, and here's a rebased and improved
version of the Windows SChannel
On 08/15/2014 02:02 AM, Alvaro Herrera wrote:
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
I'm sure this still needs some cleanup, but here's the patch, based
on your v14. Now that I know what this approach looks like, I still
like it much better. The insert and update code is somewhat
On 08/15/2014 08:16 PM, Jeff Janes wrote:
On Tue, Aug 12, 2014 at 10:52 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 08/06/2014 08:37 PM, Jeff Janes wrote:
But now it looks like 0002 needs a rebase
I've committed the refactoring patch, and here's a rebased and improved
On Thu, Aug 14, 2014 at 2:21 PM, Jeff Davis pg...@j-davis.com wrote:
On Thu, 2014-08-14 at 12:53 -0400, Tom Lane wrote:
Oh? So if we have aggregates like array_agg whose memory footprint
increases over time, the patch completely fails to avoid bloat?
Yes, in its current form.
I might think
On Fri, Aug 15, 2014 at 9:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Aug 14, 2014 at 6:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If it weren't for the fact that we'll be wedded forevermore to a bad
choice of syntax, I might agree with you. But
Fujii Masao wrote:
I've not read the patch yet. But while testing the feature, I found that
* Brin index cannot be created on CHAR(n) column.
Maybe other data types have the same problem.
Yeah, it's just a matter of adding an opclass for it -- pretty simple
stuff really, because you
On Fri, Aug 15, 2014 at 12:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
* I think 5..8 are overly complex: we can just set SIGPIPE to SIG_IGN
(which is its usual setting in the postmaster already) and check for
EPIPE from the write().
wfm.
* There might be some benefit to swapping steps 9 and
On Sun, Jun 29, 2014 at 3:19 AM, Matheus de Oliveira
matioli.math...@gmail.com wrote:
Hi Hackers,
I have worked on that patch a little more. So now I have functional patch
(although still WIP) attached. The feature works as following:
- Added a boolean parameter only_temp_files to
On 08/14/2014 07:24 PM, Tom Lane wrote:
We can certainly reduce that. The question was whether it would be
worth the effort to try. At this point, with three different test
data sets having shown clear space savings, I think it is worth
the effort. I'll poke into it tomorrow or over the
Josh Berkus j...@agliodbs.com writes:
On 08/14/2014 07:24 PM, Tom Lane wrote:
We can certainly reduce that. The question was whether it would be
worth the effort to try. At this point, with three different test
data sets having shown clear space savings, I think it is worth
the effort.
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 08/15/2014 08:16 PM, Jeff Janes wrote:
Should the ereport DEBUG2 be inside the #ifdef USE_SSL?
Yeah.
I've been thinking though, perhaps we should always have the ssl_in_use,
peer_cn and peer_cert_valid members in the Port struct. If not
I'm still getting up to speed on postgres development but I'd like to leave
an opinion.
We should add some sort of versionning to the jsonb format. This can be
explored in the future in many ways.
As for the current problem, we should explore the directory at the end
option. It should improve
CREATE INDEX USING GIST(timerange);
On 1.3 million rows this took only 30 seconds.
on 70 million its already taken over a day. I swear it didn't take this long
on version 9.3
Is there some kind of known bug with GIST? CPU is at 4% or less and ram is
at 150mbs
IO usage is at 100% but most of it
Hi Alvaro
2014-08-15 20:16 GMT+02:00 you answered:
(...)
Yeah, it's just a matter of adding an opclass for it -- pretty simple
(...)
Right now there are opclasses for the following types:
(...)
Of course, the real interesting part is adding a completely different
opclass, such as one that
On 08/15/2014 01:38 PM, Tom Lane wrote:
I've been poking at this, and I think the main explanation for your result
is that with more JSONB documents being subject to compression, we're
spending more time in pglz_decompress. There's no free lunch in that
department: if you want compressed
On Thu, Aug 14, 2014 at 4:13 PM, Noah Misch n...@leadboat.com wrote:
I share your (Kevin's) discomfort with our use of strlcpy(). I wouldn't
mind
someone replacing most strlcpy()/snprintf() calls with calls to wrappers
that
ereport(ERROR) on truncation. Though as reliability problems go,
Arthur Silva arthur...@gmail.com writes:
We should add some sort of versionning to the jsonb format. This can be
explored in the future in many ways.
If we end up making an incompatible change to the jsonb format, I would
support taking the opportunity to stick a version ID in there. But
I
On Fri, Aug 15, 2014 at 12:49:36AM -0700, Michael Paquier wrote:
Btw, how do you determine if MSVC is using HAVE_GETADDRINFO? Is it
decided by the inclusion of getaddrinfo.c in @pgportfiles of
Mkvdbuild.pm?
src/include/pg_config.h.win32 dictates it, and we must keep @pgportfiles
synchronized
On Sat, Aug 16, 2014 at 10:38:39AM +1200, David Rowley wrote:
On Thu, Aug 14, 2014 at 4:13 PM, Noah Misch n...@leadboat.com wrote:
I share your (Kevin's) discomfort with our use of strlcpy(). I wouldn't
mind
someone replacing most strlcpy()/snprintf() calls with calls to wrappers
that
When using pg_service.conf with LDAP, we document[1] the following sample LDIF
for populating the LDAP server:
version:1
dn:cn=mydatabase,dc=mycompany,dc=com
changetype:add
objectclass:top
objectclass:groupOfUniqueNames
cn:mydatabase
uniqueMember:host=dbserver.mycompany.com
uniqueMember:port=5439
64 matches
Mail list logo
