On Wed, Aug 13, 2014 at 5:55 PM, wrote:
>> I don't think that it's good idea to control that behavior by using
>> --status-interval. I'm sure that there are some users who both want that
>> behavior and want set the maximum interval between a feedback is sent
>> back to the server because these s
On Fri, Aug 15, 2014 at 8:19 PM, Tom Lane wrote:
> Arthur Silva 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 opportunit
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
On Sat, Aug 16, 2014 at 10:38:39AM +1200, David Rowley wrote:
> On Thu, Aug 14, 2014 at 4:13 PM, Noah Misch 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
> > erep
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
Arthur Silva 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 don't want to force a
On Thu, Aug 14, 2014 at 4:13 PM, Noah Misch 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, this one
> has
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 s
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 tha
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 i
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 com
Heikki Linnakangas 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 compiled
> wit
Josh Berkus 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. I'll poke in
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
On Sun, Jun 29, 2014 at 3:19 AM, Matheus de Oliveira
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 pg_tablespace.spcoptions;
>
On Fri, Aug 15, 2014 at 12:02 PM, Tom Lane 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 10; at the
> ver
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 d
On Fri, Aug 15, 2014 at 9:57 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Aug 14, 2014 at 6:12 PM, Tom Lane 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 t
On Thu, Aug 14, 2014 at 2:21 PM, Jeff Davis 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 a patch
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
ve
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 mor
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 imp
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
Robert Haas 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 read.
> 5. Install
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 `
Fujii Masao 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 I/O for input (and i
Hi
2014-08-14 9:03 GMT+02:00 Heikki Linnakangas :
> 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 !=
>> ((v
On Thu, Aug 14, 2014 at 1:52 PM, MauMau 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 consistency?
pg_c
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
On 2014-08-15 09:54:01 -0400, Tom Lane wrote:
> Andres Freund 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".
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 caus
Robert Haas writes:
> On Thu, Aug 14, 2014 at 6:12 PM, Tom Lane 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 never. I don't
>> like #2.
> O
Andres Freund 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 (report_commit_lsn
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 re
On Tue, Jul 15, 2014 at 12:20 AM, Christoph Martin
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 simply compare
> the string
On Thu, Aug 14, 2014 at 12:08 PM, Baker, Keith [OCDUS Non-J&J]
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 PIPE-based
> loc
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 rig
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 c
On Fri, Aug 15, 2014 at 8: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 u
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 d
On Thu, Aug 14, 2014 at 6:12 PM, Tom Lane wrote:
> Robert Haas 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 good as we think they are.
>
> If
On Fri, Aug 15, 2014 at 8:36 PM, Andres Freund 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 mean much m
On Fri, Aug 15, 2014 at 4:05 PM, Michael Paquier
wrote:
> On Thu, Aug 14, 2014 at 8:34 PM, Fujii Masao wrote:
>> +At any one time there will be at a number of active
>> synchronous standbys
>> +defined by synchronous_standby_num; transactions waiting
>>
>> It's better to use , ins
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'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 Fri, Aug 15, 2014 at 3:40 AM, Andres Freund wrote:
> On 2014-08-14 14:37:22 -0400, Robert Haas wrote:
>> On Thu, Aug 14, 2014 at 2:21 PM, Andres Freund
>> wrote:
>> > On 2014-08-14 14:19:13 -0400, Robert Haas wrote:
>> >> That's about the idea. However, what you've got there is actually
>> >>
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),
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 initial
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
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 differenc
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 ch
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 ea
On 7/16/14 4:33 PM, Tom Lane wrote:
Rajeev rastogi 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.
LOG: could not
On 2014-08-14 12:21:38 -0400, Robert Haas wrote:
> On Sat, Aug 9, 2014 at 12:54 PM, Andres Freund 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 COMMIT WITH (report
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 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#NULL (in the docs as this refers to a value)
Will fix.
> - Your thoughts abo
On 2014-08-15 11:12:11 +0300, Marti Raudsepp wrote:
> Hi
>
> On Thu, May 8, 2014 at 4:28 PM, Andres Freund 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 warr
Thanks for your review.
On Fri, Aug 15, 2014 at 12:56 AM, 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
pg_receivexlog.
> [postgres postgre
Hi
On Thu, May 8, 2014 at 4:28 PM, Andres Freund 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 to expose the segmen
> 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
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 much
On Mon, Aug 11, 2014 at 10:48 PM, Noah Misch 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:
http://msdn.microsoft.com/en-us/library/windo
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 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 mor
On Thu, Aug 14, 2014 at 8:34 PM, Fujii Masao wrote:
> +At any one time there will be at a number of active
> synchronous standbys
> +defined by synchronous_standby_num; transactions waiting
>
> It's better to use , instead.
Fixed.
> +for commit will be allowed to proceed a
65 matches
Mail list logo
