On Thu, Mar 28, 2013 at 9:47 PM, John Mudd 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 projects? Any
> act
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
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
> http://www.postgre
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
http://www.postgresql.org/docs/devel/static/
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 AM
On Wed, Mar 27, 2013 at 10:15 AM, Andres Freund wrote:
> On 2013-03-27 10:06:19 -0400, Robert Haas wrote:
>> On Mon, Mar 18, 2013 at 4:31 PM, Greg Smith wrote:
>> > to get them going again. If the install had checksums, I could have
>> > figured
>> > out which blocks were damaged and manually f
On 28 March 2013 20:34, Dean Rasheed 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 '[4:4][8:7]={{}}', it
> should a
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 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 schrieb:
> >
> > >Bruce Momjian writes:
> > >> Should I just patch pg_upgrade to remove the "indisvalid", skip
> > >> "indisvalid" indexes, and backpa
"anara...@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 IndexIsValid() macro in
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 schrieb:
> >
> > >"anara...@anarazel.de" writes:
> > >> Tom Lane schrieb:
> > >>> Yeah, if you can just ignore !indisvalid indexes that should work
> >
On Thu, Mar 28, 2013 at 10:47:55PM +0100, anara...@anarazel.de wrote:
>
>
> Tom Lane schrieb:
>
> >"anara...@anarazel.de" writes:
> >> Tom Lane 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
Tom Lane schrieb:
>"anara...@anarazel.de" writes:
>> Tom Lane 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
"anara...@anarazel.de" writes:
> Tom Lane 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
> indexes. No?
No, he doesn
On Thu, Mar 28, 2013 at 10:31:51PM +0100, anara...@anarazel.de wrote:
>
>
> Tom Lane schrieb:
>
> >Bruce Momjian 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 ma
Tom Lane schrieb:
>Bruce Momjian 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 che
Bruce Momjian 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"?
Yeah,
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
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
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 Wed, Mar 27, 2013 at 11:27 AM, Thom Brown wrote:
> On 27 March 2013 15:19, Robert Haas wrote:
>> On Wed, Mar 27, 2013 at 10:51 AM, Thom Brown wrote:
create here is referring to the sepgsql permission, not the SQL
command, so it's correct as-is.
>>>
>>> My bad.
>>
>> Here's an attemp
On Thu, Mar 28, 2013 at 12:33 PM, Kohei KaiGai 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: http://www.ente
On 13-03-26 12:40 AM, Tom Lane wrote:
Bruce Momjian 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 that's so marginal
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 actuall
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 sepgsql
* 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
inte
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 trigg
Stephen Frost 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 don't want to
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 rec
* 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 ast
Heikki Linnakangas writes:
> On 28.03.2013 01:01, Tom Lane wrote:
>> Simon Riggs 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 after each WAL record seems
>> to
On 28 March 2013 13:47, Heikki Linnakangas 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 the -R option, t
On 28.03.2013 01:01, Tom Lane wrote:
Simon Riggs writes:
On 27 March 2013 20:40, Heikki Linnakangas 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 useful
during development, to catch bugs ear
On Wed, Mar 27, 2013 at 8:41 AM, Robert Haas 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 ahead and push it
Stephen Frost 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 due to it COMMIT
On 28.03.2013 14:45, Simon Riggs wrote:
On 28 March 2013 11:36, Robert Haas wrote:
On Thu, Mar 28, 2013 at 6:23 AM, Simon Riggs 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 k
On Thu, Mar 28, 2013 at 10:34 AM, Andres Freund wrote:
> On 2013-03-28 10:18:45 +0900, Michael Paquier wrote:
>> On Thu, Mar 28, 2013 at 3:12 AM, Fujii Masao wrote:
>> Since we call relation_open() with lockmode, ISTM that we should also call
>> > relation_close() with the same lockmode instead o
On 28 March 2013 11:36, Robert Haas wrote:
> On Thu, Mar 28, 2013 at 6:23 AM, Simon Riggs 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_dire
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 prett
On Wed, Mar 27, 2013 at 8:22 AM, Robert Haas wrote:
> On Wed, Mar 27, 2013 at 10:47 AM, Tom Lane 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 we don't. You were just argui
On Wed, Mar 27, 2013 at 10:32 AM, Alvaro Herrera
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 .. (except "thi
On Thu, Mar 28, 2013 at 6:23 AM, Simon Riggs 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 would read the rec
On 28 March 2013 08:31, Heikki Linnakangas 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 write
> to $PGDATA
On 28 March 2013 03:01, Tom Lane 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 dimensions
where not just
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 y
45 matches
Mail list logo
