On Thu, Mar 6, 2014 at 12:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
On 03/05/2014 09:11 AM, Michael Paquier wrote:
After testing this feature, I noticed that FORCE_NULL and
FORCE_NOT_NULL can both be specified with COPY on the same column.
Strictly
On 03/07/2014 08:24 AM, Michael Paquier wrote:
In the documentation, particularly the doc index, syslog_ident is
incorrectly mentioned as syslog_identify. The attached patch fixes
that. This error is in the docs since 8.0.
Thanks, fixed.
- Heikki
--
Sent via pgsql-hackers mailing list
On 6 March 2014 22:43, Noah Misch n...@leadboat.com wrote:
On Tue, Mar 04, 2014 at 06:50:17PM +0100, Andres Freund wrote:
On 2014-03-04 11:40:10 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes: I think this is all too
late for 9.4, though.
I agree with the feeling that a
On 03/06/2014 09:34 PM, Robert Haas wrote:
On Thu, Mar 6, 2014 at 8:11 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I don't think it's necessary to improve concurrency just to get WAL-logging.
Better concurrency is a worthy goal of its own, of course, but it's a
separate concern.
To
On 03/06/2014 02:18 AM, Bruce Momjian wrote:
On Tue, Nov 5, 2013 at 08:36:32PM +0100, Andres Freund wrote:
On 2013-11-04 13:48:32 +0100, Andres Freund wrote:
What about just unowning the smgr entry with
if (rel-rd_smgr != NULL)
smgrsetowner(NULL, rel-rd_smgr)
when closing the fake
On 2/27/14, 6:04 AM, Dimitri Fontaine wrote:
What about allowing a control file like this:
# hstore extension
comment = 'data type for storing sets of (key, value) pairs'
default_version = '1.3'
directory = 'local/hstore-new'
module_pathname = '$directory/hstore'
Hello,
After all, I have confirmed that this fixes the problem on crash
recovery of hot-standby botfor 9.3 and HEAD and no problem was
found except unreadability :(
Ok, committed. Thanks!
Thank you.
Any concrete suggestions about the readability? Is there some
particular spot that
Hi,
On 2014-03-05 23:20:57 +0100, Andres Freund wrote:
On 2014-03-05 17:05:24 -0500, Robert Haas wrote:
I very much dislike having the three different event loops, but it's
pretty much forced by the design of the xlogreader. My xlogreader
version didn't block when it neeeded to wait for
Andres Freund escribió:
fprintf(stderr,
- _(%s: could not identify system: got
%d rows and %d fields, expected %d rows and %d fields\n),
- progname, PQntuples(res),
PQnfields(res), 1, 3);
+
On Thu, Mar 6, 2014 at 7:07 PM, Greg Stark st...@mit.edu wrote:
On Thu, Mar 6, 2014 at 11:14 PM, Robert Haas robertmh...@gmail.com wrote:
I've been tempted to implement a new type of hash index that allows both WAL
and high concurrency, simply by disallowing bucket splits. At the index
On 2014-03-07 10:17:21 -0300, Alvaro Herrera wrote:
Andres Freund escribió:
fprintf(stderr,
- _(%s: could not identify system: got
%d rows and %d fields, expected %d rows and %d fields\n),
-
On 03/05/2014 11:02 AM, Craig Ringer wrote:
The main known issue remaining is plan invalidation.
I've pushed a version with a plan invalidation implementation. It's tagged:
rls-9.4-upd-sb-views-v9
in
g...@github.com:ringerc/postgres.git
The invalidation implementation does not yet handle
On Fri, Mar 7, 2014 at 9:41 AM, Bruce Momjian br...@momjian.us wrote:
On Fri, Mar 7, 2014 at 09:07:24AM +0530, Amit Kapila wrote:
One reason could be that as we are already returning special exit code
for 'status' option of pg_ctl (exit(3)), this seems to be inline with it as
this
also get
[ I just sent a reply to Greg Stark's email which touches on some of
the same points you mentioned here; that was mostly written last
night, and finished this morning before seeing this. ]
On Fri, Mar 7, 2014 at 4:34 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Hmm. You suggested
On 03/07/2014 03:48 PM, Robert Haas wrote:
So, there seems to be a few fairly simple and independent improvements to be
made:
1. Replace the heavy-weight lock with pin vacuum-lock.
2. Make it crash-safe, by adding WAL-logging
3. Only acquire the exclusive-lock (vacuum-lock after step 1) in
On Thu, Mar 06, 2014 at 06:14:21PM -0500, Robert Haas wrote:
On Thu, Mar 6, 2014 at 3:44 PM, Jeff Janes jeff.ja...@gmail.com wrote:
I've been tempted to implement a new type of hash index that allows both WAL
and high concurrency, simply by disallowing bucket splits. At the index
On 03/07/2014 09:33 PM, Craig Ringer wrote:
On 03/05/2014 11:02 AM, Craig Ringer wrote:
The main known issue remaining is plan invalidation.
I've pushed a version with a plan invalidation implementation. It's tagged:
rls-9.4-upd-sb-views-v9
in
g...@github.com:ringerc/postgres.git
On 03/07/2014 03:48 PM, Robert Haas wrote:
On Fri, Mar 7, 2014 at 4:34 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Hmm. You suggested ensuring that a scan always has at least a pin, and split
takes a vacuum-lock. That ought to work. There's no need for the more
complicated maneuvers
* Peter Eisentraut (pete...@gmx.net) wrote:
On 2/27/14, 6:04 AM, Dimitri Fontaine wrote:
What about allowing a control file like this:
# hstore extension
comment = 'data type for storing sets of (key, value) pairs'
default_version = '1.3'
directory = 'local/hstore-new'
On 03/07/2014 06:03 AM, Tom Lane wrote:
In the bug thread I proposed making atexit_callback check whether getpid()
still matches MyProcPid. If it doesn't, then presumably we inherited the
atexit callback list, along with the value of MyProcPid, from some parent
backend process whose elbow we
On Fri, Mar 7, 2014 at 07:18:04PM +0530, Amit Kapila wrote:
OK, done with the attached patch Three is returned for status, but one
for other cases.
I think it would have been better if it return status as 4 for cases where
directory/file is not accessible (current new cases added by this
On 03/07/2014 04:23 PM, Florian Weimer wrote:
On 03/07/2014 06:03 AM, Tom Lane wrote:
In the bug thread I proposed making atexit_callback check whether getpid()
still matches MyProcPid. If it doesn't, then presumably we inherited the
atexit callback list, along with the value of MyProcPid,
On 2014-03-07 00:03:48 -0500, Tom Lane wrote:
In the bug thread I proposed making atexit_callback check whether getpid()
still matches MyProcPid.
What are you proposing to do in that case? This is only one of the
failure cases of forking carelessly, right?
I think the only appropriate thing
On 03/07/2014 10:07 PM, Craig Ringer wrote:
On 03/07/2014 09:33 PM, Craig Ringer wrote:
On 03/05/2014 11:02 AM, Craig Ringer wrote:
The main known issue remaining is plan invalidation.
I've pushed a version with a plan invalidation implementation. It's tagged:
rls-9.4-upd-sb-views-v9
in
Andres Freund and...@2ndquadrant.com writes:
On 2014-03-07 00:03:48 -0500, Tom Lane wrote:
In the bug thread I proposed making atexit_callback check whether getpid()
still matches MyProcPid.
What are you proposing to do in that case? This is only one of the
failure cases of forking
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 03/07/2014 04:23 PM, Florian Weimer wrote:
There's the PID reuse problem. Forking twice (with a delay) could end
up with the same PID as MyProcPid.
Not if the parent process is still running.
If the original parent backend is *not* still
On 03/07/2014 03:57 PM, Tom Lane wrote:
I think Florian's right that there's a risk there, but it seems pretty
remote, and I don't see any reliable way to detect the case anyhow.
(Process start time? Where would you get that from portably?)
I don't think there's a portable source for that.
I just noticed that the DSM patch has introduced a whole new class of
failures related to the bug #9464 issue: to wit, any on_detach
actions registered in a parent process will also be performed when a
child process exits, because nothing has been added to on_exit_reset
to prevent that. It seems
On 2014-03-07 09:49:05 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-03-07 00:03:48 -0500, Tom Lane wrote:
In the bug thread I proposed making atexit_callback check whether getpid()
still matches MyProcPid.
What are you proposing to do in that case? This is
Florian Weimer fwei...@redhat.com writes:
On 03/07/2014 03:57 PM, Tom Lane wrote:
It's not a reason not to do something about the much larger chance of
this happening in a direct child process, which certainly won't have a
matching PID.
Indeed. Checking getppid() in addition might narrow
On 03/07/2014 04:10 PM, Tom Lane wrote:
Florian Weimer fwei...@redhat.com writes:
On 03/07/2014 03:57 PM, Tom Lane wrote:
It's not a reason not to do something about the much larger chance of
this happening in a direct child process, which certainly won't have a
matching PID.
Indeed.
Andres Freund and...@2ndquadrant.com writes:
On 2014-03-07 09:49:05 -0500, Tom Lane wrote:
No, I think it should do nothing. The coding pattern shown in bug #9464
seems perfectly reasonable and I think we should allow it.
I don't think it's a reasonable pattern run background processes that
Hi,
On 2014-03-06 02:39:37 +0100, Andres Freund wrote:
Unless somebody protests I'll try to get the remaining walsender and
docs patches ready before sending in the patch fixing this as it's not
disturbing the buildfarm. I'll be onsite/travelling tomorrow; so I am
not sure I'll be done then,
Hi,
On 2014-03-07 10:24:31 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-03-07 09:49:05 -0500, Tom Lane wrote:
No, I think it should do nothing. The coding pattern shown in bug #9464
seems perfectly reasonable and I think we should allow it.
I don't think
On Thu, Mar 6, 2014 at 10:33 PM, Bruce Momjian br...@momjian.us wrote:
On Thu, Mar 6, 2014 at 09:50:56PM +0400, Oleg Bartunov wrote:
Hi there,
Looks like consensus is done. I and Teodor are not happy with it, but
what we can do :) One thing I want to do is to reserve our
contribution to
On 03/06/2014 11:33 PM, Bruce Momjian wrote:
On Thu, Mar 6, 2014 at 09:50:56PM +0400, Oleg Bartunov wrote:
Hi there,
Looks like consensus is done. I and Teodor are not happy with it, but
what we can do :) One thing I want to do is to reserve our
contribution to the flagship feature
Hi,
Peter Eisentraut pete...@gmx.net writes:
On 2/27/14, 6:04 AM, Dimitri Fontaine wrote:
directory = 'local/hstore-new'
module_pathname = '$directory/hstore'
I think your previously proposed patch to add extension_control_path
plus my suggestion to update existing de facto best
On Fri, Mar 7, 2014 at 11:35:41AM -0500, Andrew Dunstan wrote:
IIRC The sacrifice was one bit in the header (i.e. in the first int
after the varlena header). We could now repurpose that (for example
if we ever decided to use a new format).
Oleg and Teodor made most of the adjustments on the
On 03/07/2014 11:45 AM, Bruce Momjian wrote:
On Fri, Mar 7, 2014 at 11:35:41AM -0500, Andrew Dunstan wrote:
IIRC The sacrifice was one bit in the header (i.e. in the first int
after the varlena header). We could now repurpose that (for example
if we ever decided to use a new format).
Oleg
On Fri, Mar 7, 2014 at 11:57:48AM -0500, Andrew Dunstan wrote:
If they can be done for 9.4, great, if not, we have to decide if these
suboptimal cases are enough for us to delay the data type until 9.5. I
don't know the answer, but I have to ask the question.
AFAIK, there is no sacrifice
Craig Ringer cr...@2ndquadrant.com writes:
On 03/06/2014 02:58 AM, Tom Lane wrote:
The PlanInvalItem could perfectly well be generated by the planner,
no, if it has the user OID? But I'm not real sure why you need it.
I don't see the reason for an invalidation triggered by user ID.
What
There are a few threads floating around currently in which some of
the cc'd addresses are various-people at hobby.2ndquadrant.com.
Addresses like that seem not to work, or at least not work reliably.
I believe the official addresses are just soandso at 2ndquadrant.com.
If you're replying to any
Sorry for the bit of top-posting, but I wanted to make some things
clear. Also, I wasn't subscribed to pgsql-hackers at the time this
thread began, so I apologize for the missing headers that might cause
threading issues.
I'm the submitter of bug #9464. Here's the background on what we are
Craig Ringer cr...@2ndquadrant.com writes:
What I'm concerned about is the locking. It looks to me like we're
causing the user to lock rows that they may not intend to lock, by
applying a LockRows step *before* the user supplied qual. (I'm going to
test that tomorrow, it's sleep time in
On 7 March 2014 17:46, Tom Lane t...@sss.pgh.pa.us wrote:
There are a few threads floating around currently in which some of
the cc'd addresses are various-people at hobby.2ndquadrant.com.
Addresses like that seem not to work, or at least not work reliably.
I believe the official addresses are
Hi,
On 2014-03-07 09:50:15 -0800, Peter LaDow wrote:
Also, the on_exit_reset() does clear up the issue, and we have
implemented it as suggested in this thread (calling it immediately
after the fork() in the child). And Andres' keen eye noted we were
calling exit() after an exec() failure,
Hello
I am returning back to this topic. Last time I proposed styles:
http://www.postgresql.org/message-id/cafj8prclgoktryjpbtoncpgyftrcz-zgfowdc1jqulb+ede...@mail.gmail.com
http://postgres.cz/wiki/Pretty_borders_in_psql
This experiment fails, but there are some interesting tips in discuss.
Andres Freund and...@2ndquadrant.com writes:
A patch fixing this is attached. I've added some more local variables to
deal with the longer lines...
Since I've got a compiler in captivity that complains about this,
I'll take care of checking and committing this patch.
I still think it might be
On Fri, Mar 7, 2014 at 10:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I just noticed that the DSM patch has introduced a whole new class of
failures related to the bug #9464 issue: to wit, any on_detach
actions registered in a parent process will also be performed when a
child process exits,
On 2014-03-07 13:27:28 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
A patch fixing this is attached. I've added some more local variables to
deal with the longer lines...
Since I've got a compiler in captivity that complains about this,
I'll take care of checking
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 7, 2014 at 10:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I just noticed that the DSM patch has introduced a whole new class of
failures related to the bug #9464 issue: to wit, any on_detach
actions registered in a parent process will also be
Hi,
On 2014-03-07 13:54:42 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
I don't think this can actually happen. There are quite a number of
things that would go belly-up if you tried to use dynamic shared
memory from the postmaster, which is why dsm_create() and
Andres Freund and...@2ndquadrant.com writes:
On 2014-03-07 13:54:42 -0500, Tom Lane wrote:
The big picture here is that in the scenario being debated in the other
thread, exit() in a child process forked from a backend will execute that
backend's on_detach actions *even if the code had done
On 2014-03-07 14:14:17 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-03-07 13:54:42 -0500, Tom Lane wrote:
The big picture here is that in the scenario being debated in the other
thread, exit() in a child process forked from a backend will execute that
On Fri, Mar 7, 2014 at 1:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 7, 2014 at 10:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I just noticed that the DSM patch has introduced a whole new class of
failures related to the bug #9464 issue: to
On Friday, March 7, 2014, Andres Freund and...@2ndquadrant.com wrote:
If the third party library is suitably careful it will only use fork()
and then exec() or _exit(), otherwise there are other things that'll be
But that is not possible* in our case of trying to spawn an asynchronous
On 2014-03-07 12:09:45 -0800, Peter LaDow wrote:
On Friday, March 7, 2014, Andres Freund and...@2ndquadrant.com wrote:
If the third party library is suitably careful it will only use fork()
and then exec() or _exit(), otherwise there are other things that'll be
But that is not possible*
On Fri, Mar 7, 2014 at 12:17 PM, Andres Freund and...@2ndquadrant.com wrote:
Man. The point is that that the library code is carefully written to not
use exit() but _exit() after a fork failure, that's it.
I understand your point. I understand that in the case of the
postmaster we don't want
On Fri, Mar 7, 2014 at 12:17 PM, Andres Freund and...@2ndquadrant.com wrote:
Forking twice is ok as well, as long as you just use _exit() after the
fork. The thing is that you shouldn't run any nontrivial code in the
fork, as long as you're connected to the original environment (fd's,
memory
I am reworking this patch, both to accomodate earlier review comments
and to fix the multiple verify step of namespaces, as noted by Tom in
4530.1390023...@sss.pgh.pa.us
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Hi,
We use Postgres in our product and we have a client that requires a
static code analysis scan to detect vulnerabilities. They are concerned
because the tool (Veracode) found several flaws in Postgres and they
believe there might be a security risk. I'm sure there are lots of
companies
On Thu, Mar 6, 2014 at 7:44 AM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
Hi all,
There are some place with the next commitfest deadlines (2014/06 and
2014/09) ?
Regards,
Those deadlines won't be finalized until after PGCon, but it seems
likely to me that we'll do about what we
On Mar 6, 2014, at 1:51 AM, Peter Geoghegan p...@heroku.com wrote:
It's true for perl. Syntax of hstore is close to hash/array syntax and it's
easy serialize/deserialize hstore to/from perl. Syntax of hstore was
inspired by perl.
I understand that. There is a module on CPAN called
On Fri, Mar 7, 2014 at 12:55 PM, Peter LaDow pet...@gocougs.wsu.edu wrote:
Just to be clear, what do you mean by nontrivial code? Do you mean
C library calls, other than fork/exec/_exit?
I think I've answered my own question:
http://man7.org/linux/man-pages/man7/signal.7.html
The
On Fri, Mar 7, 2014 at 5:56 PM, Alvaro Herrera alvhe...@2ndquadrant.comwrote:
I am reworking this patch, both to accomodate earlier review comments
and to fix the multiple verify step of namespaces, as noted by Tom in
4530.1390023...@sss.pgh.pa.us
This link is broken...
--
Fabrízio de
On Fri, Mar 7, 2014 at 7:21 PM, Andres Freund and...@2ndquadrant.comwrote:
On 2014-03-07 19:14:48 -0300, Fabrízio de Royes Mello wrote:
On Fri, Mar 7, 2014 at 5:56 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
I am reworking this patch, both to accomodate earlier review comments
Patrick Curran pcur...@contentanalyst.com writes:
We use Postgres in our product and we have a client that requires a
static code analysis scan to detect vulnerabilities. They are concerned
because the tool (Veracode) found several flaws in Postgres and they
believe there might be a
I was testing some builds I was doing and found that the regression
tests fails when doing the against a Hot Standby server:
$ make standbycheck
[...]
== running regression test queries==
test hs_standby_check ... ok
test hs_standby_allowed ... FAILED
On 2014-03-07 19:14:48 -0300, Fabrízio de Royes Mello wrote:
On Fri, Mar 7, 2014 at 5:56 PM, Alvaro Herrera
alvhe...@2ndquadrant.comwrote:
I am reworking this patch, both to accomodate earlier review comments
and to fix the multiple verify step of namespaces, as noted by Tom in
On Wed, Nov 13, 2013 at 10:28:07AM +0100, Colin 't Hart wrote:
David et al,
How about something like this?
I have applied a modified version of your patch. I didn't like the
idea of putting SELECT inside an OR syntax clauses --- the syntax is
already too complicated. I also didn't like
On Thu, Nov 14, 2013 at 11:32:23AM +0100, Marko Tiikkaja wrote:
On 11/14/13 7:08 AM, Tatsuo Ishii wrote:
It means the connection is idle except for keepalive packets.
We could perhaps just drop the word otherwise, if people find
it confusing.
Wah. I seemed to completely misunderstand what
On Fri, Mar 7, 2014 at 10:03:42PM -0500, Bruce Momjian wrote:
On Thu, Nov 14, 2013 at 11:32:23AM +0100, Marko Tiikkaja wrote:
On 11/14/13 7:08 AM, Tatsuo Ishii wrote:
It means the connection is idle except for keepalive packets.
We could perhaps just drop the word otherwise, if people find
On 05/03/14 15:44, Craig Ringer wrote:
On 03/05/2014 05:25 PM, Yeb Havinga wrote:
Maybe a naive thought, but shouldn't all plans that include a table with
an RLS clause be invalidated when the session role switches, regardless
of which users from and to?
Only if the plan is actually accessed
Florian Pflug f...@phlo.org writes:
On Mar5, 2014, at 18:37 , Tom Lane t...@sss.pgh.pa.us wrote:
My advice is to lose the EXPLAIN output entirely. If the authors of
the patch can't agree on what it means, what hope have everyday users
got of making sense of it?
The question isn't what the
On Mar5, 2014, at 23:49 , Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org writes:
On Mar5, 2014, at 18:37 , Tom Lane t...@sss.pgh.pa.us wrote:
My advice is to lose the EXPLAIN output entirely. If the authors of
the patch can't agree on what it means, what hope have everyday
On 3/7/14, 11:39 AM, Dimitri Fontaine wrote:
Just please make sure that it's still possible to use full absolute path
for the module path name so that the packager can have control too.
I can't think of any package system where absolute paths are part of a
recommended workflow. There is always
On Mar5, 2014, at 23:49 , Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org writes:
On Mar5, 2014, at 18:37 , Tom Lane t...@sss.pgh.pa.us wrote:
My advice is to lose the EXPLAIN output entirely. If the authors of
the patch can't agree on what it means, what hope have everyday
[I answered most of these concerns in more detail in the reply to Dimitri.]
On 3/7/14, 9:16 AM, Stephen Frost wrote:
Being able to have a self-contained module which requires a minimum of
modification to postgresql.conf is a reduction in complexity, imv.
Having to maintain two config options
On Fri, Mar 7, 2014 at 7:59 PM, Bruce Momjian br...@momjian.us wrote:
On Fri, Mar 7, 2014 at 07:18:04PM +0530, Amit Kapila wrote:
OK, done with the attached patch Three is returned for status, but one
for other cases.
I think it would have been better if it return status as 4 for cases
On Mon, Nov 18, 2013 at 10:13:19PM -0500, Bruce Momjian wrote:
On Tue, Nov 12, 2013 at 10:35:58AM +, Marc Mamin wrote:
Hello,
IMHO, there is a serious issue in the script to clean the old data directory
when running pg_upgrade in link mode.
in short: When working with symbolic
On Sun, Dec 1, 2013 at 12:07:21PM -0500, Gurjeet Singh wrote:
On Wed, Nov 27, 2013 at 9:12 AM, Robert Haas robertmh...@gmail.com wrote:
This is a performance patch, so it should come with benchmark results
demonstrating that it accomplishes its intended purpose. I don't see
On Fri, Mar 7, 2014 at 5:56 PM, Alvaro Herrera alvhe...@2ndquadrant.comwrote:
I am reworking this patch, both to accomodate earlier review comments
and to fix the multiple verify step of namespaces, as noted by Tom in
4530.1390023...@sss.pgh.pa.us
Alvaro,
Do you need some help?
Regards,
82 matches
Mail list logo
