On 27.03.2013 23:36, Simon Riggs wrote:
Why do you think recovery_config_directory are different to
config_file with respect to pg_basebackup?
pg_basebackup doesn't try to *write* anything to config_file. It does
write to $PGDATA/recovery.conf, with the expectation that it takes
effect when
On 28 March 2013 03:01, Tom Lane t...@sss.pgh.pa.us wrote:
[snip]
ranges *are not arrays*.
OK, fair enough. I guess it's the mathematician in me seeing patterns
in things that behave similarly, but which are admittedly different.
Is the patch also going to allow empty arrays in higher
On 28 March 2013 08:31, Heikki Linnakangas hlinnakan...@vmware.com wrote:
On 27.03.2013 23:36, Simon Riggs wrote:
Why do you think recovery_config_directory are different to
config_file with respect to pg_basebackup?
pg_basebackup doesn't try to *write* anything to config_file. It does
On Thu, Mar 28, 2013 at 6:23 AM, Simon Riggs si...@2ndquadrant.com wrote:
No, it *would* take effect. The parameter is set in a config file that
is not part of the backup, so if you start the server from the backup
then it doesn't know that the recovery_config_directory had been set
and so it
On Wed, Mar 27, 2013 at 10:32 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Surely creating an extension template must be a superuser-only
operation, in which case this is an issue because Mallory could also
have just blown up the world directly if he's already a superuser
anyway.
Yeah
On Wed, Mar 27, 2013 at 8:22 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 27, 2013 at 10:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Use a service file maybe? But you can't have it both ways: either we
like the behavior of libpq absorbing defaults from the postmaster
environment, or
Tom, all,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Another thing I was wondering about, but did not change, is that if we're
having the remote transaction inherit the local transaction's isolation
level, shouldn't it inherit the READ ONLY property as well?
Apologies for bringing this up pretty
On 28 March 2013 11:36, Robert Haas robertmh...@gmail.com wrote:
On Thu, Mar 28, 2013 at 6:23 AM, Simon Riggs si...@2ndquadrant.com wrote:
No, it *would* take effect. The parameter is set in a config file that
is not part of the backup, so if you start the server from the backup
then it
On Thu, Mar 28, 2013 at 10:34 AM, Andres Freund and...@anarazel.de wrote:
On 2013-03-28 10:18:45 +0900, Michael Paquier wrote:
On Thu, Mar 28, 2013 at 3:12 AM, Fujii Masao masao.fu...@gmail.com wrote:
Since we call relation_open() with lockmode, ISTM that we should also call
relation_close()
On 28.03.2013 14:45, Simon Riggs wrote:
On 28 March 2013 11:36, Robert Haasrobertmh...@gmail.com wrote:
On Thu, Mar 28, 2013 at 6:23 AM, Simon Riggssi...@2ndquadrant.com wrote:
No, it *would* take effect. The parameter is set in a config file that
is not part of the backup, so if you start
Stephen Frost sfr...@snowman.net writes:
Apologies for bringing this up pretty late, but wrt writable FDW
transaction levels, I was *really* hoping that we'd be able to implement
autonomous transactions on top of writeable FDWs. It looks like there's
no way to do this using the postgres_fdw
On Wed, Mar 27, 2013 at 8:41 AM, Robert Haas robertmh...@gmail.com wrote:
Based on KaiGai's analysis, it seems to me that there is no serious
problem here in terms of versioning, and as this patch represents a
small but useful step forward in our support for SELinux integration,
I'd like to go
On 28.03.2013 01:01, Tom Lane wrote:
Simon Riggssi...@2ndquadrant.com writes:
On 27 March 2013 20:40, Heikki Linnakangashlinnakan...@vmware.com wrote:
While looking at bug #7969, it occurred to me that it would be nice if we
could catch resource leaks in WAL redo routines better. It would be
On 28 March 2013 13:47, Heikki Linnakangas hlinnakan...@vmware.com wrote:
Therefore anybody using pg_basebackup and the config_file parameter
does *not* have an executable backup when used with the -R option, as
Heikki was suggesting was a requirement for this patch.
That's not related to
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 28.03.2013 01:01, Tom Lane wrote:
Simon Riggssi...@2ndquadrant.com writes:
I'm inclined to think that the overhead isn't worth the trouble. This
is the only bug of its type we had in recent years.
I agree that checking for resource leaks
* Tom Lane (t...@sss.pgh.pa.us) wrote:
TBH I think this is a fairly bad idea. You can get that behavior via
dblink if you need it,
While I appreciate that dblink can do it, I simply don't see it as a
good solution to this.
but there's no way to do it in an FDW without
ending up with
What we want to do is make recovery parameters into GUCs, allowing
them to be reset by SIGHUP and also to allow all users to see the
parameters in use, from any session.
The existing mechanism for recovery is that
1. we put parameters in a file called recovery.conf
2. we use the existence of a
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
... The only way to
make this sane at all would be to provide user control of which
operations go to which connections; which is inherent in dblink's API
but is simply not a concept in the FDW universe. And I
Pushed, with some further minor changes. One not-so-minor change I
introduced was that pg_event_trigger_dropped_objects() now only works
within a sql_drop event function. The reason I decided to do this was
that if we don't have that protection, then it is possible to have a
ddl_command_end
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I don't want to have API features that make connections
explicit, because I don't think that can be shoehorned into the FDW
model without considerable strain and weird corner cases.
It seems we're talking past each other here. I'm not particularly
Thanks for your checking.
I doubt of whether security policy module for this regression test is not
installed on your test environment.
Could you try ./test_sepgsql after:
$ make -f /usr/share/selinux/devel/Makefile clean
$ make -f /usr/share/selinux/devel/Makefile
$ sudo semodule -i
The core committee has decided that one of the security issues due to be
fixed next week is sufficiently bad that we need to take extra measures
to prevent it from becoming public before packages containing the fix
are available. (This is a scenario we've discussed before, but never
had to
On 13-03-26 12:40 AM, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Mon, Mar 25, 2013 at 07:07:42PM -0400, Tom Lane wrote:
Well, plan B would be to invent a replacement function that does have
the ability to return an error message, but that seems like a lot of
work for a problem
On Thu, Mar 28, 2013 at 12:33 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
Thanks for your checking.
I doubt of whether security policy module for this regression test is not
installed on your test environment.
Ah, you are right. Sorry for the noise.
Committed.
--
Robert Haas
EnterpriseDB:
On Wed, Mar 27, 2013 at 11:27 AM, Thom Brown t...@linux.com wrote:
On 27 March 2013 15:19, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 27, 2013 at 10:51 AM, Thom Brown t...@linux.com wrote:
create here is referring to the sepgsql permission, not the SQL
command, so it's correct as-is.
Hi,
I've been asked by a local student to be his mentor in GSoC. He is
interested in working on parallelizing hash join/aggregation.
So I'd like to volunteer to be a mentor for this project (if it gets
accepted).
I've asked him to post his project proposal on pgsql-students.
kind regards
Tomas
On Tue, Mar 26, 2013 at 09:43:54PM +, Tom Lane wrote:
Ignore invalid indexes in pg_dump.
Dumping invalid indexes can cause problems at restore time, for example
if the reason the index creation failed was because it tried to enforce
a uniqueness condition not satisfied by the table's
On Thu, Mar 28, 2013 at 03:06:30PM -0400, Steve Singer wrote:
So to summarise:
Plan A: The first patch I attached for pg_upgrade + documentation
changes, and changing the other places that call PQconndefaults() to
accept failures on either out of memory, or an invalid PGSERVICE
Plan B:
Bruce Momjian br...@momjian.us writes:
Should I just patch pg_upgrade to remove the indisvalid, skip
indisvalid indexes, and backpatch it? Users should be using the
version of pg_upgrade to match new pg_dump. Is there any case where
they don't match? Do I still need to check for indisready?
Tom Lane t...@sss.pgh.pa.us schrieb:
Bruce Momjian br...@momjian.us writes:
Should I just patch pg_upgrade to remove the indisvalid, skip
indisvalid indexes, and backpatch it? Users should be using the
version of pg_upgrade to match new pg_dump. Is there any case where
they don't match?
On Thu, Mar 28, 2013 at 10:31:51PM +0100, anara...@anarazel.de wrote:
Tom Lane t...@sss.pgh.pa.us schrieb:
Bruce Momjian br...@momjian.us writes:
Should I just patch pg_upgrade to remove the indisvalid, skip
indisvalid indexes, and backpatch it? Users should be using the
version of
anara...@anarazel.de and...@anarazel.de writes:
Tom Lane t...@sss.pgh.pa.us schrieb:
Yeah, if you can just ignore !indisvalid indexes that should work fine.
I see no need to look at indisready if you're doing that.
You need to look at inisready in 9.2 since thats used for about to be dropped
Tom Lane t...@sss.pgh.pa.us schrieb:
anara...@anarazel.de and...@anarazel.de writes:
Tom Lane t...@sss.pgh.pa.us schrieb:
Yeah, if you can just ignore !indisvalid indexes that should work
fine.
I see no need to look at indisready if you're doing that.
You need to look at inisready in 9.2
On Thu, Mar 28, 2013 at 10:47:55PM +0100, anara...@anarazel.de wrote:
Tom Lane t...@sss.pgh.pa.us schrieb:
anara...@anarazel.de and...@anarazel.de writes:
Tom Lane t...@sss.pgh.pa.us schrieb:
Yeah, if you can just ignore !indisvalid indexes that should work
fine.
I see no need to look
On 2013-03-28 17:54:08 -0400, Bruce Momjian wrote:
On Thu, Mar 28, 2013 at 10:47:55PM +0100, anara...@anarazel.de wrote:
Tom Lane t...@sss.pgh.pa.us schrieb:
anara...@anarazel.de and...@anarazel.de writes:
Tom Lane t...@sss.pgh.pa.us schrieb:
Yeah, if you can just ignore
anara...@anarazel.de and...@anarazel.de writes:
9.2 represents inisdead as live !ready, doesn't it? So just looking at
indislive will include about to be dropped or partially dropped indexes?
Ooooh ... you're right, in 9.2 (only) we need to check both indisvalid
and indisready (cf
On 2013-03-28 17:35:08 -0400, Bruce Momjian wrote:
On Thu, Mar 28, 2013 at 10:31:51PM +0100, anara...@anarazel.de wrote:
Tom Lane t...@sss.pgh.pa.us schrieb:
Bruce Momjian br...@momjian.us writes:
Should I just patch pg_upgrade to remove the indisvalid, skip
indisvalid indexes,
All,
Marty's issue w/ NestLoop reminded me that I'd put together a test
case which illustrates a HashJoin doing the wrong thing.
The test case is here:
http://snowman.net/~sfrost/test_case.sql
Simply load that up and then check out this plan:
explain select * from small_table join
On 28 March 2013 20:34, Dean Rasheed dean.a.rash...@gmail.com wrote:
Is the patch also going to allow empty arrays in higher dimensions
where not just the last dimension is empty?
It doesn't allow that at present.
It seems as though, if
it's allowing 1-by-0 arrays like '{{}}' and
On Wed, Mar 27, 2013 at 10:15 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-03-27 10:06:19 -0400, Robert Haas wrote:
On Mon, Mar 18, 2013 at 4:31 PM, Greg Smith g...@2ndquadrant.com wrote:
to get them going again. If the install had checksums, I could have
figured
out which
Hi,
The main argument on which this proposal is based on is to keep
backward-compatibility.
This has been discussed before many times and the position of each people
is well-known,
so I am not going back to that...
So, based on *only* what I see in this thread...
On Fri, Mar 29, 2013 at 12:48
Since there has been some, um, grumbling about the quality of the
release notes of late, I've prepared draft notes for next week's
releases, covering commits through today. These are now committed
into the master branch for review, and should show up at
Tom Lane wrote:
Since there has been some, um, grumbling about the quality of the
release notes of late, I've prepared draft notes for next week's
releases, covering commits through today. These are now committed
into the master branch for review, and should show up at
I see a few old messages referring to ISAM to SQL emulation.
For example:
http://www.postgresql.org/message-id/200402171616.i1hgg9u11...@candle.pha.pa.us
Does anyone know of any actual source code to one of these projects? Any
active projects?
John
On Thu, Mar 28, 2013 at 9:47 PM, John Mudd johnbm...@gmail.com wrote:
I see a few old messages referring to ISAM to SQL emulation.
For example:
http://www.postgresql.org/message-id/200402171616.i1hgg9u11...@candle.pha.pa.us
Does anyone know of any actual source code to one of these
45 matches
Mail list logo
