Robert Haas wrote
> On Mon, Jun 9, 2014 at 4:06 AM, b8flowerfire <
> b8flowerfire@
> > wrote:
>
> This has come up before. Basically, the problem is that if you reduce
> NTUP_PER_BUCKET, the bucket array gets larger, which might reduce the
> amount of space available for tuples to the point whe
On Mon, Jun 9, 2014 at 6:37 PM, MauMau wrote:
>
> Hello,
>
> I've fixed and tested a memory leak bug in dblink. Could you review and
commit this? I'll add this to the CommitFest shortly.
Is there a need to free memory context in PG_CATCH()?
In error path the memory due to this temporary context
Jeff Janes writes:
> On Monday, June 9, 2014, Tom Lane wrote:
>> Huh? The point of an antijoin (or indeed most join methods) is that we
>> *don't* have to examine the whole inner input to make a decision.
> But all hash join methods needs to examine the entire *outer* input, no?
> Have I screw
On Mon, Jun 09, 2014 at 09:12:27PM -0400, Peter Eisentraut wrote:
> On Thu, 2014-06-05 at 21:57 -0400, Noah Misch wrote:
> > I recommend "TMPDIR => 1" instead of setting DIR.
>
> I originally decided against doing that, because
>
> 1) I don't know if all systems would have enough space in their r
On Monday, June 9, 2014, Tom Lane wrote:
> Jeff Janes > writes:
> > On Sun, Jun 8, 2014 at 5:36 AM, David Rowley > wrote:
> >> The attached patch allows an ANTI-join plan to be generated in cases
> like:
> >> CREATE TABLE a (id INT PRIMARY KEY, b_id INT NOT NULL);
> >> CREATE TABLE b (id INT NOT
A definite +1 on this feature. A while ago I got partway through hacking
the hibernate postgres dialect to make it issue a RETURNING clause to spit
out the primary key before I realised that the driver was already doing a
RETURNING * internally.
On 10 June 2014 05:53, Jim Nasby wrote:
> I was wo
On Thu, 2014-06-05 at 21:57 -0400, Noah Misch wrote:
> I recommend "TMPDIR => 1" instead of setting DIR.
I originally decided against doing that, because
1) I don't know if all systems would have enough space in their regular
temporary directory for the kinds of things we put there. Using the
bu
On Sun, 2014-06-08 at 21:55 -0400, Noah Misch wrote:
> After upgrading to GNU Emacs 23.4.1 from a version predating directory-local
> variables, I saw switch/case indentation go on the fritz. My hooks were
> issuing (c-set-style "postgresql"), but ".dir-locals.el" set it back to plain
> "bsd" styl
Hi Amit,
Thank you for your response.
> There can be similar observation if the server goes off (power
> outage or anything like) after committing transaction, client will
> receive connection broken, so he can misunderstand that as well.
> I think for such corner cases, client needs to reconfirm
Jeff Janes writes:
> On Sun, Jun 8, 2014 at 5:36 AM, David Rowley wrote:
>> The attached patch allows an ANTI-join plan to be generated in cases like:
>> CREATE TABLE a (id INT PRIMARY KEY, b_id INT NOT NULL);
>> CREATE TABLE b (id INT NOT NULL);
>> SELECT * FROM a WHERE b_id NOT IN(SELECT id FRO
On Sun, Jun 8, 2014 at 5:36 AM, David Rowley wrote:
> Currently pull_up_sublinks_qual_recurse only changes the plan for NOT
> EXISTS queries and leaves NOT IN alone. The reason for this is because the
> values returned by a subquery in the IN clause could have NULLs.
>
> A simple example of this
On 6/9/14, 8:35 AM, Hannu Krosing wrote:
On 06/09/2014 06:58 AM, Ian Barwick wrote:
Hi,
The JDBC API provides the getGeneratedKeys() method as a way of
retrieving
primary key values without the need to explicitly specify the primary key
column(s).
Is it defined by the standard, to return _only
Tom Lane wrote:
> Assuming that Kevin's describing his needs correctly, we could resolve
> this by inventing HEAPTUPLE_INSERT_AND_DELETE_IN_PROGRESS. VACUUM could
> assume that that's a probably-dead tuple, while SSI could do something
> different.
That could work.
On the other hand, the old c
Kevin Grittner wrote:
> Andres Freund wrote:
> > On 2014-06-09 09:45:12 -0700, Kevin Grittner wrote:
> >>> old:
> >>> 1) xmin has committed, xmax is in progress, xmax is not just a locker
> >>> 2) xmin is in progress, xmax is set and not not just a locker
> >>>
> >>> Note that the 2) case here ne
Tom Lane wrote:
> The reason this stuff is not too carefully spec'd is that when
> HTSV was written, there was no expectation that there was any
> correctness issue around which of these cases was returned. I
> wonder whether SSI should be using HTSV at all.
That's certainly a reasonable questi
On 09/06/14 18:31, Tom Lane wrote:
> Linos writes:
>> On 05/06/14 19:39, Tom Lane wrote:
>>> I'd like to see a self-contained test case, by which I mean full details
>>> about the table/view schemas; it's not clear whether the actual data
>>> is very important here.
>> query1 schema file:
>> http:
Andres Freund wrote:
> On 2014-06-09 09:45:12 -0700, Kevin Grittner wrote:
> I am not sure, given predicate.c's coding, how
> HEAPTUPLE_DELETE_IN_PROGRESS could cause problems. Could you elaborate,
> since that's the contentious point with Tom? Since 'both in
> progress'
> can only happen if xmin
On Mon, Jun 09, 2014 at 10:52:34AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Wed, Aug 07, 2013 at 07:57:53AM -0400, Peter Eisentraut wrote:
> >> Did anyone have any outstanding concerns about this latest version? I
> >> thought it looked ready to commit.
>
> > After upgrading to GNU Ema
On Mon, Jun 9, 2014 at 7:45 PM, Heikki Linnakangas
wrote:
> On 06/09/2014 06:03 PM, Magnus Hagander wrote:
>
>> One tricky part is that programs like to use libpq for the
>>
>>> >authentication, and then they hijack the connection using PGgetssl().
>>> >
>>>
>> Is there*anybody* other than odbc
On 06/09/2014 06:03 PM, Magnus Hagander wrote:
One tricky part is that programs like to use libpq for the
>authentication, and then they hijack the connection using PGgetssl().
>
Is there*anybody* other than odbc that does that? Do we actually need a
published API for that, or just a hack for
On 2014-06-09 13:42:22 +0200, Vik Fearing wrote:
> On 06/09/2014 09:06 AM, Gavin Flower wrote:
> > From memory all unique keys can be considered 'candidate primary keys',
> > but only one can be designated 'the PRIMARY KEY'.
>
> Almost. Candidate keys are also NOT NULL.
The list actually is a bi
On 09/06/14 23:42, Vik Fearing wrote:
On 06/09/2014 09:06 AM, Gavin Flower wrote:
From memory all unique keys can be considered 'candidate primary keys',
but only one can be designated 'the PRIMARY KEY'.
Almost. Candidate keys are also NOT NULL.
Yeah, obviously!
(Except, I did actually forge
Andres Freund writes:
> On 2014-06-09 09:45:12 -0700, Kevin Grittner wrote:
>> For purposes of predicate.c, if the "also deleted" activity might
>> be rolled back without rolling back the insert, INSERT_IN_PROGRESS
>> is the only correct value.
> That's basically the argument for the new behaviou
Andres Freund wrote:
> On 2014-06-09 08:59:03 -0700, Kevin Grittner wrote:
>>> *) There is a lot of advice floating around (for example here:
>>> http://frosty-postgres.blogspot.com/2012/08/postgresql-numa-and-zone-reclaim-mode.html
>>> )
>>> to instruct operators to disable zone_reclaim. Will y
I'm having trouble setting max_async_io_prefetchers in postgresql.conf
It says it cannot be changed.
Is that fixed at initdb time? (sounds like a bad idea if it is)
On Sun, Jun 8, 2014 at 11:12 PM, johnlumby wrote:
> updated version of patch compatible with git head of 140608,
> (adjusted proc
On 2014-06-09 09:45:12 -0700, Kevin Grittner wrote:
> Andres Freund wrote:
> > HEAPTUPLE_INSERT_IN_PROGRESS, /* inserting xact is still in progress
> >*/
> > HEAPTUPLE_DELETE_IN_PROGRESS /* deleting xact is still in progress */
> > the current code will return INSERT_IN_PROGRESS eve
Andres Freund wrote:
> On 2014-06-09 08:00:52 -0700, Kevin Grittner wrote:
> I tried to make things a bit clearer there - but I am not sure I've
> succeed. I'm certainly willing to explain things further if you can tell
> me which are is unclear.
Thanks! IMO, something like this should be inclu
Linos writes:
> On 05/06/14 19:39, Tom Lane wrote:
>> I'd like to see a self-contained test case, by which I mean full details
>> about the table/view schemas; it's not clear whether the actual data
>> is very important here.
> query1 schema file:
> http://pastebin.com/JpqM87dr
Sorry about the d
On 2014-06-09 08:59:03 -0700, Kevin Grittner wrote:
> > *) There is a lot of advice floating around (for example here:
> > http://frosty-postgres.blogspot.com/2012/08/postgresql-numa-and-zone-reclaim-mode.html
> > )
> > to instruct operators to disable zone_reclaim. Will your changes
> > invalida
Merlin Moncure wrote:
> On Sun, Jun 8, 2014 at 5:45 PM, Kevin Grittner wrote:
> Hm, your patch seems to boil down to
> interleave_memory(start, size, numa_all_nodes_ptr)
> inside PGSharedMemoryCreate().
That's the functional part -- the rest is about not breaking the
builds for environments w
On 2014-06-09 08:00:52 -0700, Kevin Grittner wrote:
> I'm not actually sure yet whether the current state of affairs
> causes a problem for the serializable transaction isolation level
> implementation.
I'd replied in the other thread before noticing you'd replied
here... From what I understand ri
On 09/06/14 17:30, Merlin Moncure wrote:
> On Mon, Jun 9, 2014 at 10:00 AM, Linos wrote:
>> On 09/06/14 16:55, Merlin Moncure wrote:
>>> On Mon, Jun 9, 2014 at 9:51 AM, Linos wrote:
Hello,
Is this information enough? I could try to assemble a complete test case
but I have ver
On Mon, Jun 9, 2014 at 10:00 AM, Linos wrote:
> On 09/06/14 16:55, Merlin Moncure wrote:
>> On Mon, Jun 9, 2014 at 9:51 AM, Linos wrote:
>>> Hello,
>>>
>>> Is this information enough? I could try to assemble a complete test case
>>> but I have very little time right now because I am trying to me
On Mon, Jun 09, 2014 at 11:39:17PM +0900, MauMau wrote:
> From: "Heikki Linnakangas"
> >Thoughts? While we're at it, we'll probably want to refactor
> >things so that it's easy to support other SSL implementations too,
> >like gnutls.
>
> That may be good because it provides users with choices.
Robert Haas writes:
> This has come up before. Basically, the problem is that if you reduce
> NTUP_PER_BUCKET, the bucket array gets larger, which might reduce the
> amount of space available for tuples to the point where the hash join
> overflows to multiple batches. That will be more expensive
On Mon, Jun 9, 2014 at 4:39 PM, Martijn van Oosterhout
wrote:
> On Mon, Jun 09, 2014 at 03:35:23PM +0200, Magnus Hagander wrote:
> > On Mon, Jun 9, 2014 at 3:19 PM, Andreas Karlsson
> wrote:
> >
> > > On 06/09/2014 01:45 PM, Heikki Linnakangas wrote:
> > > There was a patch set for this from Mar
On Mon, Jun 9, 2014 at 4:06 AM, b8flowerfire wrote:
> When I read the source code about the hashjoin, I was very confused that the
> postgresql define the NTUP_PER_BUCKET value as 10.
> Since this value is used to estimate the tuple count in one bucket, is it
> better if we have a smaller value?
>
Andres Freund wrote:
> Well, I think reverting surely wouldn't be the right cure. It
> fixes a somewhat nasty bug. I'd certainly be prepared to add the
> two lines necessary to make it return DELETE_IN_PROGRESS after
> trying to understand Kevin's email about predicate.c and going
> through the o
On 09/06/14 16:55, Merlin Moncure wrote:
> On Mon, Jun 9, 2014 at 9:51 AM, Linos wrote:
>> Hello,
>>
>> Is this information enough? I could try to assemble a complete test case but
>> I have very little time right now because I am trying to meet a very
>> difficult deadline.
>>
>> I will do ASAP
On Mon, Jun 9, 2014 at 9:51 AM, Linos wrote:
> Hello,
>
> Is this information enough? I could try to assemble a complete test case but
> I have very little time right now because I am trying to meet a very
> difficult deadline.
>
> I will do ASAP if needed.
It is not -- it was enough to diagnos
Noah Misch writes:
> On Wed, Aug 07, 2013 at 07:57:53AM -0400, Peter Eisentraut wrote:
>> Did anyone have any outstanding concerns about this latest version? I
>> thought it looked ready to commit.
> After upgrading to GNU Emacs 23.4.1 from a version predating directory-local
> variables, I saw
On 05/06/14 23:09, Linos wrote:
> On 05/06/14 19:39, Tom Lane wrote:
>> Merlin Moncure writes:
>>> On Thu, Jun 5, 2014 at 9:54 AM, Linos wrote:
What I don't understand is why the statistics have this bad information,
all my tests are done on a database just restored and analyzed. Can I
On Mon, Jun 9, 2014 at 10:40 AM, Heikki Linnakangas
wrote:
> Right. I have no idea what SChannel's track record is, but when there's a
> vulnerability in the native SSL implementation in Windows, you better
> upgrade anyway, regardless of PostgreSQL. So when we rely on that, we don't
> put any ext
On Sun, Jun 8, 2014 at 5:45 PM, Kevin Grittner wrote:
> I ran into a situation where a machine with 4 NUMA memory nodes and
> 40 cores had performance problems due to NUMA. The problems were
> worst right after they rebooted the OS and warmed the cache by
> running a script of queries to read all
Ian Barwick writes:
> [ RETURNING PRIMARY KEY ]
It looks to me like this is coded to have the expansion of the "primary
key" done at parse time, which seems like fundamentally the wrong thing.
Consider a view or rule containing this clause; the pkey might be
different by the time execution rolls
On 2014-06-09 10:30:43 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-06-09 10:14:32 -0400, Robert Haas wrote:
> >> I think that would be a good idea for conceptual clarity if nothing
> >> else. If callers are OK with it, then they can treat both of those
> >> codes alike; but then at
On 06/09/2014 05:22 PM, Andres Freund wrote:
Hi,
On 2014-06-09 10:18:40 -0400, Tom Lane wrote:
Does SChannel have a better security track record than OpenSSL? Or is
the point here just that we can define it as not our problem when a
vulnerability surfaces?
Well, it's patched as part of the O
On Mon, Jun 09, 2014 at 03:35:23PM +0200, Magnus Hagander wrote:
> On Mon, Jun 9, 2014 at 3:19 PM, Andreas Karlsson wrote:
>
> > On 06/09/2014 01:45 PM, Heikki Linnakangas wrote:
> > There was a patch set for this from Martijn van Oosterhout which was quite
> > complete.
> >
> > http://www.postgr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/09/2014 08:58 AM, MauMau wrote:
> From: "Fabrízio de Royes Mello" I think
> there no need to add it to the commitfest, because it's a bugfix
> and not a new feature. Or am I missing something?
>
> The CommitFest app has an option "bug fix" in
From: "Heikki Linnakangas"
Thoughts? While we're at it, we'll probably want to refactor things so
that it's easy to support other SSL implementations too, like gnutls.
That may be good because it provides users with choices. But I wonder if it
is worth the complexity and maintainability of P
Andres Freund writes:
> On 2014-06-09 10:14:32 -0400, Robert Haas wrote:
>> I think that would be a good idea for conceptual clarity if nothing
>> else. If callers are OK with it, then they can treat both of those
>> codes alike; but then at least there's clear evidence as to the
>> author's inte
On Mon, Jun 2, 2014 at 11:42 AM, Tom Lane wrote:
> Stephen Frost writes:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> TBH I think that trying to do anything at all for inner joins is probably
>>> a bad idea. The cases where the optimization could succeed are so narrow
>>> that it's unlikely to
Hi,
On 2014-06-09 10:18:40 -0400, Tom Lane wrote:
> Does SChannel have a better security track record than OpenSSL? Or is
> the point here just that we can define it as not our problem when a
> vulnerability surfaces?
Well, it's patched as part of the OS - so no new PG binaries have to be
releas
On 2014-06-09 10:14:32 -0400, Robert Haas wrote:
> On Fri, Jun 6, 2014 at 3:44 PM, Tom Lane wrote:
> > It did not use to blow this question off: back around 8.3 you got
> > DELETE_IN_PROGRESS if the tuple had a delete pending. I think we need
> > less laziness + fuzzy thinking here. Maybe we sho
Heikki Linnakangas writes:
> I've been looking at Windows' native SSL implementatation, the SChannel
> API. It would be nice to support that as a replacement for OpenSSL on
> Windows. Currently, we bundle the OpenSSL library in the PostgreSQL,
> installers, which is annoying because whenever Op
On Fri, Jun 6, 2014 at 3:44 PM, Tom Lane wrote:
> It did not use to blow this question off: back around 8.3 you got
> DELETE_IN_PROGRESS if the tuple had a delete pending. I think we need
> less laziness + fuzzy thinking here. Maybe we should have a separate
> HEAPTUPLE_INSERT_AND_DELETE_IN_PROG
Marti Raudsepp writes:
> On Sun, Jun 8, 2014 at 3:36 PM, David Rowley wrote:
>> Currently pull_up_sublinks_qual_recurse only changes the plan for NOT EXISTS
>> queries and leaves NOT IN alone. The reason for this is because the values
>> returned by a subquery in the IN clause could have NULLs.
From: "Fabrízio de Royes Mello"
I think there no need to add it to the commitfest, because it's a bugfix
and not a new feature. Or am I missing something?
The CommitFest app has an option "bug fix" in the list of topic choices.
I suppose the reason is that if the bug fix is only posted to pgsql
On Mon, Jun 9, 2014 at 3:02 PM, Marko Kreen wrote:
> On Mon, Jun 09, 2014 at 02:45:08PM +0300, Heikki Linnakangas wrote:
> > Thoughts? While we're at it, we'll probably want to refactor things
> > so that it's easy to support other SSL implementations too, like
> > gnutls.
>
> One project that is
On Mon, Jun 9, 2014 at 3:19 PM, Andreas Karlsson wrote:
> On 06/09/2014 01:45 PM, Heikki Linnakangas wrote:
>
>> Thoughts? While we're at it, we'll probably want to refactor things so
>> that it's easy to support other SSL implementations too, like gnutls.
>>
>
> There was a patch set for this fr
On 06/09/2014 06:58 AM, Ian Barwick wrote:
> Hi,
>
> The JDBC API provides the getGeneratedKeys() method as a way of
> retrieving
> primary key values without the need to explicitly specify the primary key
> column(s).
Is it defined by the standard, to return _only_ generated primary keys,
and not
On Mon, Jun 9, 2014 at 10:07 AM, MauMau wrote:
> Hello,
>
> I've fixed and tested a memory leak bug in dblink. Could you review and
> commit this? I'll add this to the CommitFest shortly.
>
>
I think there no need to add it to the commitfest, because it's a bugfix
and not a new feature. Or am I
On 06/09/2014 01:45 PM, Heikki Linnakangas wrote:
Thoughts? While we're at it, we'll probably want to refactor things so
that it's easy to support other SSL implementations too, like gnutls.
There was a patch set for this from Martijn van Oosterhout which was
quite complete.
http://www.postg
Hello,
I've fixed and tested a memory leak bug in dblink. Could you review and
commit this? I'll add this to the CommitFest shortly.
[Problem]
A user reported a problem in pgsql-jp ML that he encountered a "out of
memory" error when he ran the ran the following function on 32-bit
PostgreS
On Mon, Jun 09, 2014 at 02:45:08PM +0300, Heikki Linnakangas wrote:
> Thoughts? While we're at it, we'll probably want to refactor things
> so that it's easy to support other SSL implementations too, like
> gnutls.
One project that is proud to support several SSL implementations
is curl: http://cu
On 2014-06-09 13:53:15 +0200, Magnus Hagander wrote:
> The main other entries I've been looking at are NSS and gnutls, both of
> which can speak our current file formats. I think the right thing is to
> start with those and thereby make it more pluggable, and only after that
> tackle schannel. But
David G Johnston wrote:
>> ERROR: Relation does not have any primary key(s)
>
> "Relation does not have a primary key."
> or
> "Relation has no primary key." (preferred)
Project style says that the primary message should not capitalize
the first word, nor should it end in a period. Detai
On 06/09/2014 02:53 PM, Magnus Hagander wrote:
Also, my memory says that SChannel doesn't support the key file format that
we use now, which makes a much bigger break with the supported platforms.
That may have changed of course - have you researched that part?
A quick web search turned up a fe
On Monday, June 9, 2014, Heikki Linnakangas wrote:
> Hi,
>
> I've been looking at Windows' native SSL implementatation, the SChannel
> API. It would be nice to support that as a replacement for OpenSSL on
> Windows. Currently, we bundle the OpenSSL library in the PostgreSQL,
> installers, which i
On 06/08/2014 02:36 PM, David Rowley wrote:
> + if (!get_attnotnull(tle->resorigtbl, tle->resorigcol))
> + return false;
As Marti says, you can't do this because NOT NULL doesn't have an oid to
attach a dependency to. You'll have to restrict this test to primary
ke
Hi,
I've been looking at Windows' native SSL implementatation, the SChannel
API. It would be nice to support that as a replacement for OpenSSL on
Windows. Currently, we bundle the OpenSSL library in the PostgreSQL,
installers, which is annoying because whenever OpenSSL puts out a new
release
On 06/09/2014 09:06 AM, Gavin Flower wrote:
> From memory all unique keys can be considered 'candidate primary keys',
> but only one can be designated 'the PRIMARY KEY'.
Almost. Candidate keys are also NOT NULL.
--
Vik
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
On Sun, Jun 8, 2014 at 3:36 PM, David Rowley wrote:
> Currently pull_up_sublinks_qual_recurse only changes the plan for NOT EXISTS
> queries and leaves NOT IN alone. The reason for this is because the values
> returned by a subquery in the IN clause could have NULLs.
I believe the reason why this
On Mon, Jun 09, 2014 at 12:36:30AM +1200, David Rowley wrote:
> Currently pull_up_sublinks_qual_recurse only changes the plan for NOT
> EXISTS queries and leaves NOT IN alone. The reason for this is because the
> values returned by a subquery in the IN clause could have NULLs.
Awesome. I've had a
On Wednesday, June 4, 2014, Tom Lane wrote:
> Magnus Hagander > writes:
> > On Tue, Jun 3, 2014 at 6:38 PM, Tom Lane > wrote:
> >> Another thought is we could make pg_basebackup simply skip any files
> that
> >> exceed RELSEG_SIZE, on the principle that you don't really need/want
> >> enormous l
When I read the source code about the hashjoin, I was very confused that the
postgresql define the NTUP_PER_BUCKET value as 10.
Since this value is used to estimate the tuple count in one bucket, is it
better if we have a smaller value?
I have not done some experiments, but it seems that we could a
On 09/06/14 17:47, David G Johnston wrote:
Ian Barwick wrote
Hi,
The JDBC API provides the getGeneratedKeys() method as a way of retrieving
primary key values without the need to explicitly specify the primary key
column(s). This is a widely-used feature, however the implementation has
signific
On Monday, June 9, 2014, Ian Barwick wrote:
>
>
> On 09/06/14 14:47, David G Johnston wrote:
>
>> Ian Barwick wrote
>>
>>> Hi,
>>>
>>> The JDBC API provides the getGeneratedKeys() method as a way of
>>> retrieving
>>> primary key values without the need to explicitly specify the primary key
>>> c
78 matches
Mail list logo
