On Sat, Jan 31, 2015 at 3:20 PM, Sawada Masahiko wrote:
> On Sat, Jan 31, 2015 at 2:00 PM, Sawada Masahiko
> wrote:
>> On Sat, Jan 31, 2015 at 4:56 AM, Tom Lane wrote:
>>> David Johnston writes:
On Fri, Jan 30, 2015 at 12:05 PM, David Fetter wrote:
> Why might the contents of pg_sett
On Sat, Jan 31, 2015 at 2:00 PM, Sawada Masahiko wrote:
> On Sat, Jan 31, 2015 at 4:56 AM, Tom Lane wrote:
>> David Johnston writes:
>>> On Fri, Jan 30, 2015 at 12:05 PM, David Fetter wrote:
Why might the contents of pg_settings be different from what would be
in pg_file_settings, apa
On Fri, Jan 30, 2015 at 10:58 PM, Robert Haas wrote:
>
> On Thu, Jan 29, 2015 at 10:13 PM, Amit Kapila
wrote:
> > I think the big problem you are mentioning can be resolved in
> > a similar way as we have done for ALTER SYSTEM which is
> > to have a separate file (.auto.conf) for settings done vi
On Sat, Jan 31, 2015 at 4:56 AM, Tom Lane wrote:
> David Johnston writes:
>> On Fri, Jan 30, 2015 at 12:05 PM, David Fetter wrote:
>>> Why might the contents of pg_settings be different from what would be
>>> in pg_file_settings, apart from the existence of this column?
>
>> The contents of pg_s
On 01/15/2015 03:03 AM, Andres Freund wrote:
0002: Use a nonblocking socket for FE/BE communication and block using
latches.
s/suceeds/succeeds/
0004: Process 'die' interrupts while reading/writing from the client socket.
+* Check for interrupts here, in addi
On Tue, Nov 18, 2014 at 10:03 AM, Heikki Linnakangas
wrote:
> So there's clearly some room for improvement here. A couple of ideas:
>
> 1. Replace the qsort with something cheaper. The itemid arrays being sorted
> are small, a few hundred item at most, usually even smaller. In this pgbench
> test
On 1/30/15 11:08 AM, Robert Haas wrote:
The final patch attached her (parallel-dummy-v2.patch) has been
updated slightly to incorporate some prefetching logic. It's still
just demo code and is not intended for commit. I'm not sure whether
the prefetching logic can actually be made to improve pe
On 1/30/15 11:54 AM, Roger Pack wrote:
On 1/29/15, Roger Pack wrote:
Hello. I see on this page a mention of basically a 4B row limit for
tables that have BLOB's
Oops I meant for BYTEA or TEXT columns, but it's possible the
reasoning is the same...
It only applies to large objects, not byte
On 1/29/15 9:13 PM, Amit Kapila wrote:
> Aside from Tom's concern about sets not being a good way to handle
this (which I agree with), the idea of "editing" pg_hba.conf via SQL
raises all the problems that were brought up when ALTER SYSTEM was being
developed. One of the big problems is a questi
On Fri, Jan 30, 2015 at 6:59 AM, Geoff Winkless wrote:
> I appreciate the work you're doing and (as a user rather than a
> pg-hacker) don't want to butt in but if it would be possible to allow
> support for IGNORE for unique but not exclusion constraints that would
> be really helpful for my own u
Robert, Stephen, etc.:
Apparently you can create a tablespace in the tablespace directory:
josh=# create tablespace tbl location '/home/josh/pg94/data/pg_tblspc/';
CREATE TABLESPACE
josh=# create table test_tbl ( test text ) tablespace tbl;
CREATE TABLE
josh=# \q
josh@Radegast:~/pg94/data/pg_tbls
Daniel,
* Daniel Bausch (bau...@dvs.tu-darmstadt.de) wrote:
> I have been researching this topic long time ago. One notably fact is
> that active prefetching disables automatic readahead prefetching (by
> Linux kernel), which can occour in larger granularities than 8K.
> Automatic readahead prefe
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> Don't forget the ALTER POLICY page. This and some of the other things
> being discussed on this thread ought to be copied there too.
Thanks, I've fixed this also.
Stephen
signature.asc
Description: Digital signature
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 30 January 2015 at 03:40, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> On Thu, Jan 29, 2015 at 9:04 PM, Stephen Frost wrote:
> >> > A policy grants the ability to SELECT, INSERT, UPDATE, or DELETE rows
> >> > whic
On 01/30/2015 11:00 AM, Tom Lane wrote:
I do see that macque is having issues, but it's been busted for the past
3 days it looks like.
Yeah. Several of the critters have been having git issues for weeks
to months. I wonder whether we couldn't teach the buildfarm script
to recover from this
On 2015-01-27 20:16:43 +0100, Andres Freund wrote:
> Here's an alternative approach. I think it generally is superior and
> going in the right direction, but I'm not sure it's backpatchable.
>
> It basically consists out of:
> 1) Make GetLockConflicts() actually work.
already commited as being a
On 2015-01-29 11:01:51 -0500, Robert Haas wrote:
> On Wed, Jan 28, 2015 at 2:41 AM, Michael Paquier
> wrote:
> > Andres Freund wrote:
> >> I think this isn't particularly pretty, but it seems to be working well
> >> enough, and changing it would be pretty invasive. So keeping in line
> >> with all
David Johnston writes:
> On Fri, Jan 30, 2015 at 12:05 PM, David Fetter wrote:
>> Why might the contents of pg_settings be different from what would be
>> in pg_file_settings, apart from the existence of this column?
> ââThe contents of pg_settings uses the setting name as a primary key.
> T
On Fri, Jan 30, 2015 at 12:05 PM, David Fetter wrote:
> On Sat, Jan 31, 2015 at 12:50:20AM +0900, Sawada Masahiko wrote:
> >
> > [postgres][5432](1)=# select * from pg_file_settings where name =
> 'work_mem';
> > -[ RECORD 1 ]--
> > name |
On Sat, Jan 31, 2015 at 12:50:20AM +0900, Sawada Masahiko wrote:
> On Sat, Jan 31, 2015 at 12:24 AM, David Fetter wrote:
> > On Fri, Jan 30, 2015 at 09:38:10PM +0900, Sawada Masahiko wrote:
> >> On Tue, Jan 27, 2015 at 3:34 AM, Robert Haas wrote:
> >> > On Thu, Jan 22, 2015 at 5:19 PM, Tom Lane
On 01/30/2015 09:19 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Given all this, it seems like a good idea to at least give a warning
>> if somebody tries to create a tablespace instead the data directory.
>
> A warning seems like a good idea. I actually thought we *
On 01/30/2015 07:48 AM, Michael Paquier wrote:
Ok, so the deal is to finally reduce the locks to
ShareRowExclusiveLock for the following commands :
- CREATE TRIGGER
- ALTER TABLE ENABLE/DISABLE
- ALTER TABLE ADD CONSTRAINT
Correct. I personally still find this useful enough to justify a patch.
>From nobody Fri Jan 30 18:20:23 2015
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: Parallel Seq Scan
To: pgsql-hackers@postgresql.org
From: Jeff Janes
Date: Fri, 30 Jan 2015 18:20:23 +
User-Agent: pgcommitfest
X-cfsender: jjanes
In-Re
On 01/15/2015 03:03 AM, Andres Freund wrote:
0004: Process 'die' interrupts while reading/writing from the client socket.
This is the reason Horiguchi-san started this thread.
+ ProcessClientWriteInterrupt(!port->noblock);
...
+/*
+ * ProcessClientWriteInterrupt() - Pro
On Fri, Jan 30, 2015 at 1:10 AM, Michael Paquier
wrote:
> I wrote:
>> Yes, this refactoring was good for testing actually...
> Oops, I have been too hasty when sending previous patch, there was a
> bug related to huge allocations. Patch correcting this bug is
> attached.
Committed. I didn't thin
>> On 1/29/15, Roger Pack wrote:
>>> Hello. I see on this page a mention of basically a 4B row limit for
>>> tables that have BLOB's
>>
>> Oops I meant for BYTEA or TEXT columns, but it's possible the
>> reasoning is the same...
>
> It only applies to large objects, not bytea or text.
OK I think
Robert Haas wrote
> Arguably, we should prohibit it altogether, but there are obviously
> people that want to do it, and there could even be somewhat valid
> reasons for that,
Lots of hand-waving here and it is just as likely they simply are not aware
of the downsides and the only reason they put
On Thu, Jan 29, 2015 at 10:13 PM, Amit Kapila wrote:
> I think the big problem you are mentioning can be resolved in
> a similar way as we have done for ALTER SYSTEM which is
> to have a separate file (.auto.conf) for settings done via
> ALTER SYSTEM command, do you see any major problem
> with th
* Robert Haas (robertmh...@gmail.com) wrote:
> Given all this, it seems like a good idea to at least give a warning
> if somebody tries to create a tablespace instead the data directory.
A warning seems like a good idea. I actually thought we *did* prevent
it..
> Arguably, we should prohibit it
On 1/30/15 11:43 AM, Joshua D. Drake wrote:
> On 01/30/2015 08:19 AM, Bruce Momjian wrote:
>>
>> On Fri, Jan 30, 2015 at 11:12:43AM -0500, Robert Haas wrote:
>>> I think everyone who has read this mailing list for a while is
>>> probably already aware of this problem. When you create a tablespace
On Fri, Jan 30, 2015 at 11:43 AM, Joshua D. Drake
wrote:
> I mean yes a warning is good but it is after the fact, the tablespace is
> already created. We know that tablespaces in $PGDATA are a bad idea, why not
> protect the user?
Please go back and read the discussion of that option in the OP.
On 01/30/2015 08:19 AM, Bruce Momjian wrote:
On Fri, Jan 30, 2015 at 11:12:43AM -0500, Robert Haas wrote:
I think everyone who has read this mailing list for a while is
probably already aware of this problem. When you create a tablespace
somewhere inside the data directory, weird things happe
On Sat, Jan 31, 2015 at 12:58 AM, Mike Blackwell wrote:
> This would default to being available to superusers only, right? Details of
> the file system shouldn't be available to any random user.
>
This WIP patch does not behave like that, but I agree.
This view would be effective combine with AL
On Fri, Jan 30, 2015 at 11:12:43AM -0500, Robert Haas wrote:
> I think everyone who has read this mailing list for a while is
> probably already aware of this problem. When you create a tablespace
> somewhere inside the data directory, weird things happen. If you
> pg_upgrade and then incautiously
I think everyone who has read this mailing list for a while is
probably already aware of this problem. When you create a tablespace
somewhere inside the data directory, weird things happen. If you
pg_upgrade and then incautiously run the delete_old_cluster.sh script
thus created, you will blow awa
Stephen Frost writes:
> * Kevin Grittner (kgri...@ymail.com) wrote:
>> My push to branches 9.3 and up seems to have broken the buildfarm
>> with this:
> I don't think it has anything to do with your push. A number of members
> have built with your latest and look fine at this point, and I'm not
This would default to being available to superusers only, right? Details
of the file system shouldn't be available to any random user.
__
*Mike Blackwell | Technical Analyst, Distribution Services/Rollout
Management
On Sat, Jan 31, 2015 at 12:24 AM, David Fetter wrote:
> On Fri, Jan 30, 2015 at 09:38:10PM +0900, Sawada Masahiko wrote:
>> On Tue, Jan 27, 2015 at 3:34 AM, Robert Haas wrote:
>> > On Thu, Jan 22, 2015 at 5:19 PM, Tom Lane wrote:
>> >> David Johnston writes:
>> >>> On Thu, Jan 22, 2015 at 3:04
Kevin,
* Kevin Grittner (kgri...@ymail.com) wrote:
> My push to branches 9.3 and up seems to have broken the buildfarm
> with this:
I don't think it has anything to do with your push. A number of members
have built with your latest and look fine at this point, and I'm not
seeing any issues here
On 2015-01-30 15:34:02 +, Kevin Grittner wrote:
> My push to branches 9.3 and up seems to have broken the buildfarm
> with this:
I think this isn't anything related to your commit. Both racoon and
macaque have failed for a while. They just happened to run quickly after
your commit, giving the
Kevin Grittner wrote:
> My push to branches 9.3 and up seems to have broken the buildfarm
> with this:
>
> error: object file
> /home/pgfarm/buildroot/pgmirror.git/objects/93/d7706cbf2ce58e63ab8bbc9d16453b2c792ed4
> is empty
> error: unable to find 93d7706cbf2ce58e63ab8bbc9d16453b2c792ed4
> fat
My push to branches 9.3 and up seems to have broken the buildfarm
with this:
error: object file
/home/pgfarm/buildroot/pgmirror.git/objects/93/d7706cbf2ce58e63ab8bbc9d16453b2c792ed4
is empty
error: unable to find 93d7706cbf2ce58e63ab8bbc9d16453b2c792ed4
fatal: SHA1 COLLISION FOUND WITH 93d7706c
On Fri, Jan 30, 2015 at 12:07:22AM -0500, Tom Lane wrote:
> Matt Kelly writes:
> > On Thu, Jan 29, 2015 at 8:42 PM, Tom Lane wrote:
> >> ... or double. Have you checked that the code behaves properly with
> >> --disable-integer-timestamps?
>
> > I presume you meant --disable-integer-datetimes.
On Fri, Jan 30, 2015 at 09:38:10PM +0900, Sawada Masahiko wrote:
> On Tue, Jan 27, 2015 at 3:34 AM, Robert Haas wrote:
> > On Thu, Jan 22, 2015 at 5:19 PM, Tom Lane wrote:
> >> David Johnston writes:
> >>> On Thu, Jan 22, 2015 at 3:04 PM, Tom Lane wrote:
> Is that a requirement, and if so
Tom Lane wrote:
> Kevin Grittner writes:
>> I propose to apply the attached to master and back-patch to 9.3
>> Objections?
>
> Only the nit-picky one that I quite dislike putting a comment
> block inside an if-condition like that.
Comment moved above the if-condition, and pushed.
Thanks for
On 2015-01-30 09:29:59 -0500, Robert Haas wrote:
> On Wed, Jan 14, 2015 at 9:03 PM, Andres Freund wrote:
> > 0002: Use a nonblocking socket for FE/BE communication and block using
> > latches.
> >
> > Has previously been reviewed by Heikki. I think Noah also had a
> > look, altho
On Thu, Jan 29, 2015 at 11:38 PM, Peter Geoghegan wrote:
> Simply removing IGNORE support until such time as we straighten
> that all out (9.6?) seems like the simplest solution. No need to block
> the progress of "UPSERT", since exclusion constraint support was
> only ever going to be useful for
On Wed, Jan 14, 2015 at 9:03 PM, Andres Freund wrote:
> 0002: Use a nonblocking socket for FE/BE communication and block using
> latches.
>
> Has previously been reviewed by Heikki. I think Noah also had a
> look, although I'm not sure how close that was.
>
> I think this c
On Tue, Jan 27, 2015 at 3:34 AM, Robert Haas wrote:
> On Thu, Jan 22, 2015 at 5:19 PM, Tom Lane wrote:
>> David Johnston writes:
>>> On Thu, Jan 22, 2015 at 3:04 PM, Tom Lane wrote:
Is that a requirement, and if so why? Because this proposal doesn't
guarantee any such knowledge AFAIC
Hi all,
Coverity is pointing out that _int_split.c has unnecessary checks for
deferenced pointers in 5 places.
- if (inter_d != (ArrayType *) NULL)
- pfree(inter_d);
+ pfree(inter_d);
In this case inter_d is generated by in
On 1 January 2015 at 02:47, David Rowley wrote:
> Hi,
>
> I've been hacking a bit at the join code again... This time I've been
> putting some effort into optimising the case where the inner side of the
> join is known to be unique.
> For example, given the tables:
>
> create table t1 (id int pr
Hi,
I noticed that when updating security barrier views on foreign tables,
we fail to give FOR UPDATE to selection queries issued at ForeignScan.
Here is an example.
postgres=# create foreign table base_ftbl (person text, visibility text)
server loopback options (table_name 'base_tbl');
CREATE FO
On 01/30/2015 04:48 AM, Venkata Balaji N wrote:
I performed series of tests for this patch and would like to share the
results. My comments are in-line.
Thanks for the testing!
*Test 1 :*
In this test, i see removed+recycled segments = 3 (except for the first 3
checkpoint cycles) and has bee
On 30 January 2015 at 03:40, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Thu, Jan 29, 2015 at 9:04 PM, Stephen Frost wrote:
>> > A policy grants the ability to SELECT, INSERT, UPDATE, or DELETE rows
>> > which match the relevant policy expression. Existing table rows
On Thu, Jan 29, 2015 at 11:28 PM, Tom Lane wrote:
>> The point of JSONB is that we take a position on certain aspects like
>> this. We're bridging a pointedly loosey goosey interchange format,
>> JSON, with native PostgreSQL types. For example, we take a firm
>> position on encoding. The JSON type
55 matches
Mail list logo
