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
significant
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
column(s). This is a widely-used feature, however the implementation has
On Sat, Jun 7, 2014 at 1:28 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-06-06 15:44:25 -0400, Tom Lane wrote:
I figured it'd be easy enough to get a better estimate by adding another
counter to count just LIVE and INSERT_IN_PROGRESS tuples (thus
effectively
assuming that
On Monday, June 9, 2014, Ian Barwick i...@2ndquadrant.com 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
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
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
On Wednesday, June 4, 2014, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net javascript:; writes:
On Tue, Jun 3, 2014 at 6:38 PM, Tom Lane t...@sss.pgh.pa.us
javascript:; wrote:
Another thought is we could make pg_basebackup simply skip any files
that
exceed
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 Sun, Jun 8, 2014 at 3:36 PM, David Rowley dgrowle...@gmail.com 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
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
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/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
keys
On Monday, June 9, 2014, Heikki Linnakangas hlinnakan...@vmware.com 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,
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
David G Johnston david.g.johns...@gmail.com 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
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 I
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:
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
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.
On Mon, Jun 9, 2014 at 10:07 AM, MauMau maumau...@gmail.com 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
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
for
On Mon, Jun 9, 2014 at 3:19 PM, Andreas Karlsson andr...@proxel.se 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
On Mon, Jun 9, 2014 at 3:02 PM, Marko Kreen mark...@gmail.com 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
From: Fabrízio de Royes Mello fabriziome...@gmail.com
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
Marti Raudsepp ma...@juffo.org writes:
On Sun, Jun 8, 2014 at 3:36 PM, David Rowley dgrowle...@gmail.com 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
On Fri, Jun 6, 2014 at 3:44 PM, Tom Lane t...@sss.pgh.pa.us 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
Heikki Linnakangas hlinnakan...@vmware.com 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
On 2014-06-09 10:14:32 -0400, Robert Haas wrote:
On Fri, Jun 6, 2014 at 3:44 PM, Tom Lane t...@sss.pgh.pa.us 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.
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
released
On Mon, Jun 2, 2014 at 11:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Stephen Frost sfr...@snowman.net 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
Andres Freund and...@2ndquadrant.com 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
From: Heikki Linnakangas hlinnakan...@vmware.com
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/09/2014 08:58 AM, MauMau wrote:
From: Fabrízio de Royes Mello fabriziome...@gmail.com 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
On Mon, Jun 09, 2014 at 03:35:23PM +0200, Magnus Hagander wrote:
On Mon, Jun 9, 2014 at 3:19 PM, Andreas Karlsson andr...@proxel.se 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.
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
On 2014-06-09 10:30:43 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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;
Ian Barwick i...@2ndquadrant.com 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
On Sun, Jun 8, 2014 at 5:45 PM, Kevin Grittner kgri...@ymail.com 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
On Mon, Jun 9, 2014 at 10:40 AM, Heikki Linnakangas
hlinnakan...@vmware.com 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,
On 05/06/14 23:09, Linos wrote:
On 05/06/14 19:39, Tom Lane wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Thu, Jun 5, 2014 at 9:54 AM, Linos i...@linos.es wrote:
What I don't understand is why the statistics have this bad information,
all my tests are done on a database just restored
Noah Misch n...@leadboat.com 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
On Mon, Jun 9, 2014 at 9:51 AM, Linos i...@linos.es 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
On 09/06/14 16:55, Merlin Moncure wrote:
On Mon, Jun 9, 2014 at 9:51 AM, Linos i...@linos.es 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
Andres Freund and...@2ndquadrant.com 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
On Mon, Jun 9, 2014 at 4:06 AM, b8flowerfire b8flowerf...@gmail.com 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
On Mon, Jun 9, 2014 at 4:39 PM, Martijn van Oosterhout klep...@svana.org
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 andr...@proxel.se
wrote:
On 06/09/2014 01:45 PM, Heikki Linnakangas wrote:
There was a
Robert Haas robertmh...@gmail.com 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
On Mon, Jun 09, 2014 at 11:39:17PM +0900, MauMau wrote:
From: Heikki Linnakangas hlinnakan...@vmware.com
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
On Mon, Jun 9, 2014 at 10:00 AM, Linos i...@linos.es wrote:
On 09/06/14 16:55, Merlin Moncure wrote:
On Mon, Jun 9, 2014 at 9:51 AM, Linos i...@linos.es 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
On 09/06/14 17:30, Merlin Moncure wrote:
On Mon, Jun 9, 2014 at 10:00 AM, Linos i...@linos.es wrote:
On 09/06/14 16:55, Merlin Moncure wrote:
On Mon, Jun 9, 2014 at 9:51 AM, Linos i...@linos.es wrote:
Hello,
Is this information enough? I could try to assemble a complete test case
but I
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
Merlin Moncure mmonc...@gmail.com wrote:
On Sun, Jun 8, 2014 at 5:45 PM, Kevin Grittner kgri...@ymail.com 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
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
invalidate any of
Linos i...@linos.es 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
Andres Freund and...@2ndquadrant.com 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
On 2014-06-09 09:45:12 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com 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
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 johnlu...@hotmail.com wrote:
updated version of patch compatible with git head of
Andres Freund and...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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
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
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 bit
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 Mon, Jun 9, 2014 at 7:45 PM, Heikki Linnakangas hlinnakan...@vmware.com
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
On Mon, Jun 09, 2014 at 10:52:34AM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com 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
Andres Freund and...@2ndquadrant.com 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
On 09/06/14 18:31, Tom Lane wrote:
Linos i...@linos.es 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:
Tom Lane t...@sss.pgh.pa.us 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
Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com 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
Tom Lane t...@sss.pgh.pa.us 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
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
On Sun, Jun 8, 2014 at 5:36 AM, David Rowley dgrowle...@gmail.com 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
Jeff Janes jeff.ja...@gmail.com writes:
On Sun, Jun 8, 2014 at 5:36 AM, David Rowley dgrowle...@gmail.com 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
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 his
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 style.
I'd
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
build
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 j...@nasby.net
On Monday, June 9, 2014, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Janes jeff.ja...@gmail.com javascript:; writes:
On Sun, Jun 8, 2014 at 5:36 AM, David Rowley dgrowle...@gmail.com
javascript:; wrote:
The attached patch allows an ANTI-join plan to be generated in cases
like:
CREATE TABLE a
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 regular
Jeff Janes jeff.ja...@gmail.com writes:
On Monday, June 9, 2014, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Jun 9, 2014 at 6:37 PM, MauMau maumau...@gmail.com 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
Robert Haas wrote
On Mon, Jun 9, 2014 at 4:06 AM, b8flowerfire lt;
b8flowerfire@
gt; 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 where
81 matches
Mail list logo
