2011/1/21 Florian Pflug :
> On Jan21, 2011, at 03:29 , Tom Lane wrote:
>> "Kevin Grittner" writes:
Robert Haas wrote:
Oh, you mean water that had some things you didn't want taken out
of it?
>>
>>> Right -- God only knows the number of things were filtered out to
>>> leave me with
On Sat, Jan 22, 2011 at 12:33 AM, Robert Haas wrote:
> On Sat, Jan 15, 2011 at 11:52 AM, Greg Smith wrote:
>> Where I was expecting that setting to be "4" instead for 32kB. So there's
>> probably some minor bug left in where I inserted this into the
>> initialization sequence.
>
> So I exposed t
On Sat, Jan 15, 2011 at 11:52 AM, Greg Smith wrote:
> Where I was expecting that setting to be "4" instead for 32kB. So there's
> probably some minor bug left in where I inserted this into the
> initialization sequence.
So I started taking a look at this patch tonight with an eye to
committing i
On Fri, Jan 21, 2011 at 2:30 PM, Jeff Davis wrote:
> On Fri, 2011-01-21 at 12:31 -0500, Robert Haas wrote:
>> On Thu, Jan 20, 2011 at 4:29 AM, Jeff Davis wrote:
>> > New patch. I added a lot of generic range functions, and a lot of
>> > operators.
>> >
>> > There is still more work to do, this is
"When I test your example, though, I'm getting the serialization
failure on T3 rather than T2, so I'd call that a bug. Will
investigate. Thanks again for your tests! You seem to be able to
shake out issues better than anyone else! Once found, fixing them
is not usually very hard, it's coming up
Robert Haas wrote:
> Upon further review, I am wondering if it wouldn't be simpler and
> more logical to allow idempotent changes of these settings at any
> time, and to restrict only changes that actually change something.
I don't care a lot about that either -- if I remember correctly, we
go
> Jeff Davis wrote:
> On Fri, 2011-01-21 at 18:52 -0600, Kevin Grittner wrote:
>> My assumption is that when we have a safe snapshot (which should
>> be pretty close to all the time), we immediately provide it to any
>> serializable transaction requesting a snapshot, except it seems to
>> make sen
On Fri, Jan 21, 2011 at 7:08 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> Jeff Janes wrote:
>>> I found the following message somewhat confusing:
>>> ERROR: read-only property must be set before any query
>>
>> I think what we need here is two messages, this one and a similar
>> one that s
On Fri, Jan 21, 2011 at 1:59 PM, Aidan Van Dyk wrote:
> Yup. And I'm OK with that. In my case, it would be much better to
> have a few quick failures, which can complete automatically a few
> seconds later then to have a big buildup of transactions to re-verify
> by hand upon starting manual pro
On Fri, 2011-01-21 at 18:52 -0600, Kevin Grittner wrote:
> My assumption is that when we have a safe snapshot (which should be
> pretty close to all the time), we immediately provide it to any
> serializable transaction requesting a snapshot, except it seems to
> make sense to use the new DEFERRABL
I wrote:
> We're not talking about passing the backwards. I'm suggesting
> that we probably don't even need to pass them forward, but that
> suggestion has been pretty handwavy so far. I guess I should fill
> it out, because everyone's been ignoring it so far.
It's been too hectic today to fl
Robert Haas wrote:
> Jeff Janes wrote:
>> I found the following message somewhat confusing:
>> ERROR: read-only property must be set before any query
>
> I think what we need here is two messages, this one and a similar
> one that starts with "read-write property...".
Done. I started out by
Tom Lane wrote:
> "Kevin Grittner" writes:
> > Anyone else seeing anything like this on `make world`?
>
> Looks like Bruce didn't bother to test that before committing. Fixed.
Thanks. I built is several times that displayed fine, but I now see
that it throws a warning when built. Thanks for th
Since 8.4, we've been using the definition that join selectivity for
a clause in a semijoin is the fraction of outer-relation tuples that
pass the clause (or more strictly, for which there exists at least
one inner-relation tuple with which the clause succeeds). While this
looks fairly straightfor
"Kevin Grittner" writes:
> Anyone else seeing anything like this on `make world`?
Looks like Bruce didn't bother to test that before committing. Fixed.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
Anyone else seeing anything like this on `make world`?
make[3]: Entering directory
`/home/kgrittn/git/postgresql/kgrittn/doc/src/sgml'
{ \
echo ""; \
echo ""; \
} > version.sgml
"/usr/bin/perl" ./mk_feature_tables.pl YES
../../../src/backend/catalog/sql_feature_package
On Fri, 2011-01-21 at 11:00 -0500, Garick Hamlin wrote:
> I can't tell if PG supports querying a secondary RADIUS server?
>
> I don't see how I would do it with the syntax here ...
> http://developer.postgresql.org/pgdocs/postgres/auth-methods.html
>
> Are multiple servers not supported?
>
>
Heikki Linnakangas writes:
> Some quick comments on that:
> * I wonder if CREATE FOREIGN DATA WRAPPER should automatically create
> the handler function, if it doesn't exist yet. That's what CREATE
> LANGUAGE does, which is similar. Although it doesn't seem to be
> documented for CREATE LANGUA
Hello
I merge your changes and little enhanced comments.
Regards
Pavel Stehule
2011/1/20 Stephen Frost :
> Greetings,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> attached patch contains a implementation of iteration over a array:
>
> I've gone through this patch and, in general, it
On tor, 2011-01-20 at 22:30 +0200, Peter Eisentraut wrote:
> On lör, 2010-12-18 at 18:56 +0100, Jan Urbański wrote:
> > there seems to be a problem in the way we add exceptions to the plpy
> > module in PL/Python compiled with Python 3k.
> >
> > Try this: DO $$ plpy.SPIError $$ language plpython3u
On Fri, 2011-01-21 at 12:31 -0500, Robert Haas wrote:
> On Thu, Jan 20, 2011 at 4:29 AM, Jeff Davis wrote:
> > New patch. I added a lot of generic range functions, and a lot of
> > operators.
> >
> > There is still more work to do, this is just an updated patch. The
> > latest can be seen on the g
Robert Haas writes:
> On Fri, Jan 21, 2011 at 12:44 PM, Bosco Rama wrote:
>> Tom Lane wrote:
>>> So I'm not sure whether to fix it, or leave it as a known failure case
>>> in old branches. Comments?
>> As an end user there is one area of the DB that I want to work correctly
>> 100% of the time
On Fri, Jan 21, 2011 at 1:32 PM, Robert Haas wrote:
>> Again, I'm trying to stop "forward progress" as soon as possible when
>> a sync slave isn't replicating. And I'ld like clients to fail with
>> errors sooner (hopefully they get to the commit point) rather than
>> accumulate the WAL synced to
On Fri, Jan 21, 2011 at 1:09 PM, Aidan Van Dyk wrote:
> On Fri, Jan 21, 2011 at 1:03 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Fri, Jan 21, 2011 at 12:23 PM, Aidan Van Dyk wrote:
When no sync slave is connected, yes, I want to stop things hard.
>>
>>> What you're proposing is to fa
robertmh...@gmail.com (Robert Haas) writes:
> On Mon, Jan 17, 2011 at 8:23 PM, Greg Smith wrote:
>> Quite. It's taken me 12 days of machine time running pgbench to find the
>> spots where this problem occurs on a system with a reasonably sized
>> shared_buffers (I'm testing against 256MB). It's
"Kevin Grittner" wrote:
> When I test your example, though, I'm getting the serialization
> failure on T3 rather than T2, so I'd call that a bug. Will
> investigate. Thanks again for your tests!
Fixed with this:
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=b
On Fri, Jan 21, 2011 at 1:03 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jan 21, 2011 at 12:23 PM, Aidan Van Dyk wrote:
>>> When no sync slave is connected, yes, I want to stop things hard.
>
>> What you're proposing is to fail things earlier than absolutely
>> necessary (when they try
Robert Haas writes:
> On Fri, Jan 21, 2011 at 12:23 PM, Aidan Van Dyk wrote:
>> When no sync slave is connected, yes, I want to stop things hard.
> What you're proposing is to fail things earlier than absolutely
> necessary (when they try to XLOG, rather than at commit) but still
> later than wh
On Fri, Jan 21, 2011 at 12:44 PM, Bosco Rama wrote:
> Tom Lane wrote:
>>
>> So I'm not sure whether to fix it, or leave it as a known failure case
>> in old branches. Comments?
>
> I understand the reluctance to fool with stable code. I have zero insight
> into your installed versions distributi
Josh Berkus wrote:
> On 1/20/11 6:15 AM, Robert Haas wrote:
> > On Thu, Jan 20, 2011 at 9:13 AM, Bruce Momjian wrote:
> >> OK, I am ready to move test_fsync to /contrib. Is pg_test_fsync the
> >> best name? pg_check_fsync? pg_fsync_performance? pg_verify_fsync?
> >
> > I don't see too much re
Tom Lane wrote:
>
> So I'm not sure whether to fix it, or leave it as a known failure case
> in old branches. Comments?
I understand the reluctance to fool with stable code. I have zero insight
into your installed versions distribution and backward compatibility needs
so any comment I may have
Anssi Kääriäinen wrote:
> I am beginning to understand the problem. If you don't mind, here
> is a complete example if somebody else is having troubles
> understanding this.
>
> Let's say we have tables D1 and D2. Both contain a single column,
> id, and a single row. The data in the beginning is
On Thu, Jan 20, 2011 at 4:29 AM, Jeff Davis wrote:
> New patch. I added a lot of generic range functions, and a lot of
> operators.
>
> There is still more work to do, this is just an updated patch. The
> latest can be seen on the git repository, as well:
So is this 9.2 material at this point?
-
On Fri, Jan 21, 2011 at 12:23 PM, Aidan Van Dyk wrote:
> On Fri, Jan 21, 2011 at 11:59 AM, Simon Riggs wrote:
>
>> We all think our own proposed options are the only reasonable thing, but
>> that helps us not at all in moving forwards. I've put much time into
>> delivering options many other peop
On Fri, Jan 21, 2011 at 11:59 AM, Simon Riggs wrote:
> We all think our own proposed options are the only reasonable thing, but
> that helps us not at all in moving forwards. I've put much time into
> delivering options many other people want, so there is a range of
> function. I think we should
On Thu, 2011-01-20 at 21:36 +, Simon Riggs wrote:
> I'll review your patch and commit it, problems or objections excepted.
Tom's comments elsewhere prevent me from committing.
--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and Ser
Em 21-01-2011 12:47, Andrew Dunstan escreveu:
Maybe we could change the hint to say "--file=DESTINATION" or
"--file=FILENAME|DIRNAME" ?
... "--file=OUTPUT" or "--file=OUTPUTNAME".
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
On Fri, 2011-01-21 at 14:34 +0100, Magnus Hagander wrote:
> On Fri, Jan 21, 2011 at 14:24, Simon Riggs wrote:
> > On Fri, 2011-01-21 at 14:45 +0200, Heikki Linnakangas wrote:
> >> * it seems like overkill to not let clients to even connect when
> >> allow_standalone_primary=off and no synchronous
On Fri, 2011-01-21 at 17:33 +0200, Heikki Linnakangas wrote:
> On 21.01.2011 15:24, Simon Riggs wrote:
> > On Fri, 2011-01-21 at 14:45 +0200, Heikki Linnakangas wrote:
> >> * it seems like overkill to not let clients to even connect when
> >> allow_standalone_primary=off and no synchronous standbys
On Fri, Jan 21, 2011 at 11:47 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Fri, Jan 21, 2011 at 16:40, Robert Haas wrote:
>>> So... is there centralized structure which contains the info you're
>>> thinking of exposing?
>
>> No, not today.
>
> I think that most of the info Magnus suggeste
Magnus Hagander writes:
> On Fri, Jan 21, 2011 at 16:40, Robert Haas wrote:
>> So... is there centralized structure which contains the info you're
>> thinking of exposing?
> No, not today.
I think that most of the info Magnus suggested isn't stored at all,
anywhere, at the moment; much less sto
On Mon, Jan 17, 2011 at 8:23 PM, Greg Smith wrote:
> Quite. It's taken me 12 days of machine time running pgbench to find the
> spots where this problem occurs on a system with a reasonably sized
> shared_buffers (I'm testing against 256MB). It's one of those things it's
> hard to reproduce with
Robert Haas writes:
> I don't want to go there, and it's not what Tom was proposing anyway.
> The idea is - if the user creates a function which is NOT a trusted
> procedure and executes it, and then subsequently changes the system
> security policy so that it becomes a trusted procedure, the user
On 18.01.2011 17:26, Shigeru HANADA wrote:
3) 20110118-fdw_handler.patch - This patch adds support for HANDLER
option to FOREIGN DATA WRAPPER object.
Some quick comments on that:
* I wonder if CREATE FOREIGN DATA WRAPPER should automatically create
the handler function, if it doesn't exist ye
Tom Lane wrote:
> Simon Riggs writes:
>> On Fri, 2011-01-21 at 11:19 +0200, Heikki Linnakangas wrote:
>>> It's not the order in which the xid was assigned that matters,
>>> but the order the transactions started and got their snapshots.
>>> The xids might be assigned a lot later, after the transa
2011/1/22 Robert Haas :
> On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> For that matter, I wonder what happens with regular function
>>> permissions. If the plan inlines the function and then somebody goes
>>> and changes the permission on the function and makes it
On Fri, Jan 21, 2011 at 11:00 AM, Kohei KaiGai wrote:
> 2011/1/22 Robert Haas :
>> On Fri, Jan 21, 2011 at 10:46 AM, Tom Lane wrote:
>>> Robert Haas writes:
On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane wrote:
> ALTER FUNCTION is supposed to cause plan invalidation in such a case.
> No
On 21.01.2011 17:57, Robert Haas wrote:
How much review have you done of parts (3) and (4)?
Not much. I'm getting there..
The key issue for
all of the FDW work in progress seems to be what the handler API is
going to look like, and so once we get that committed it will unblock
a lot of other
On Thu, Jan 20, 2011 at 08:55:42PM -0500, Daniel Farina wrote:
> The problem is that running a reliable,
> centralized LDAP service is not justifiable as compared to role
> mangling on a per-node level, and the role mangling seems has some
> shortcomings that are negotiable with gritted teeth.
Wan
2011/1/22 Robert Haas :
> On Fri, Jan 21, 2011 at 10:46 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane wrote:
ALTER FUNCTION is supposed to cause plan invalidation in such a case.
Not sure if GRANT plays nice with that though.
>>
>>> And in the
On Fri, Jan 21, 2011 at 10:17 AM, Heikki Linnakangas
wrote:
> On 18.01.2011 17:26, Shigeru HANADA wrote:
>>
>> 1) 20110118-no_fdw_perm_check.patch - This patch is not included in
>> last post. This had been proposed on 2011-01-05 first, but maybe has
>> not been reviewd yet. I re-propose this pa
On Fri, Jan 21, 2011 at 10:43 AM, Magnus Hagander wrote:
> On Fri, Jan 21, 2011 at 16:40, Robert Haas wrote:
>> On Fri, Jan 21, 2011 at 10:34 AM, Magnus Hagander
>> wrote:
>>> Um, none of the fields I've suggested so far was "connection string".
>>> In fact, that would be Pretty Darn Hard witho
On Fri, Jan 21, 2011 at 10:33 AM, Heikki Linnakangas
wrote:
> It's also possible that most of your transactions in fact do "set
> synchronous_replication=off", and only a few actually do synchronous
> replication. It would be pretty bad to not allow connections in that case.
> And what if you want
On Fri, Jan 21, 2011 at 10:46 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane wrote:
>>> ALTER FUNCTION is supposed to cause plan invalidation in such a case.
>>> Not sure if GRANT plays nice with that though.
>
>> And in the case of SE-Linux, this could ge
On Fri, Jan 21, 2011 at 10:35 AM, Tom Lane wrote:
> Itagaki Takahiro writes:
>> On Fri, Jan 21, 2011 at 13:56, Tatsuo Ishii wrote:
>>> Anyone has better idea? Tom dislikes my patch but I don't know how to
>>> deal with it.
>
>> There was another design in the past discussion:
>> One idea is post
On 01/21/2011 10:34 AM, Heikki Linnakangas wrote:
On 21.01.2011 15:35, Robert Haas wrote:
On Fri, Jan 21, 2011 at 4:41 AM, Heikki Linnakangas
wrote:
There's one UI thing that bothers me. The option to specify the target
directory is called --file. But it's clearly not a file. OTOH, I'd
hat
Robert Haas writes:
> On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane wrote:
>> ALTER FUNCTION is supposed to cause plan invalidation in such a case.
>> Not sure if GRANT plays nice with that though.
> And in the case of SE-Linux, this could get changed from outside the
> database. Not sure how to ha
On Fri, Jan 21, 2011 at 16:40, Robert Haas wrote:
> On Fri, Jan 21, 2011 at 10:34 AM, Magnus Hagander wrote:
>> Um, none of the fields I've suggested so far was "connection string".
>> In fact, that would be Pretty Darn Hard without modifying the client
>> to actually *send* the connection string
On Fri, Jan 21, 2011 at 10:34 AM, Magnus Hagander wrote:
> Um, none of the fields I've suggested so far was "connection string".
> In fact, that would be Pretty Darn Hard without modifying the client
> to actually *send* the connection string. Which id doesn't.
So... is there centralized structur
On 21.01.2011 15:24, Simon Riggs wrote:
On Fri, 2011-01-21 at 14:45 +0200, Heikki Linnakangas wrote:
* it seems like overkill to not let clients to even connect when
allow_standalone_primary=off and no synchronous standbys are available.
What if you just want to run a read-only query?
That's w
On Fri, Jan 21, 2011 at 10:32 AM, Tom Lane wrote:
> Simon Riggs writes:
>> On Fri, 2011-01-21 at 11:19 +0200, Heikki Linnakangas wrote:
>>> It's not the order in which the xid was assigned that matters, but the
>>> order the transactions started and got their snapshots. The xids might
>>> be assi
Itagaki Takahiro writes:
> On Fri, Jan 21, 2011 at 13:56, Tatsuo Ishii wrote:
>> Anyone has better idea? Tom dislikes my patch but I don't know how to
>> deal with it.
> There was another design in the past discussion:
> One idea is postmaster sets a flag in the shared memory area
> indicating i
On 21.01.2011 15:35, Robert Haas wrote:
On Fri, Jan 21, 2011 at 4:41 AM, Heikki Linnakangas
wrote:
There's one UI thing that bothers me. The option to specify the target
directory is called --file. But it's clearly not a file. OTOH, I'd hate to
introduce a parallel --dir option just for this.
On Fri, Jan 21, 2011 at 16:32, Robert Haas wrote:
> On Fri, Jan 21, 2011 at 10:14 AM, Magnus Hagander wrote:
>> On Fri, Jan 21, 2011 at 15:51, Tom Lane wrote:
>>> Magnus Hagander writes:
I came across a case this week where I wanted to be able to determine
more detailed auth informati
On Fri, Jan 21, 2011 at 16:24, Andrew Dunstan wrote:
>
>
> On 01/21/2011 05:24 AM, Magnus Hagander wrote:
>>>
>>> That advice needs to be taken with a grain or two of salt. First, while
>>> you
>>> probably should not use Cygwin postgres as a production server, it is
>>> still
>>> the best way to
Simon Riggs writes:
> On Fri, 2011-01-21 at 11:19 +0200, Heikki Linnakangas wrote:
>> It's not the order in which the xid was assigned that matters, but the
>> order the transactions started and got their snapshots. The xids might
>> be assigned a lot later, after the transactions have already r
On Fri, Jan 21, 2011 at 10:14 AM, Magnus Hagander wrote:
> On Fri, Jan 21, 2011 at 15:51, Tom Lane wrote:
>> Magnus Hagander writes:
>>> I came across a case this week where I wanted to be able to determine
>>> more detailed auth information on already logged in sessions - not
>>> from the clien
On 01/21/2011 05:24 AM, Magnus Hagander wrote:
That advice needs to be taken with a grain or two of salt. First, while you
probably should not use Cygwin postgres as a production server, it is still
the best way to run psql on Windows that I know of. And second, the stuff
Yeah, I agree for ps
Fujii Masao writes:
> Probably true. But we cannot create a tablespace for root-owned directory.
> The directory must be owned by the PostgreSQL system user. So ISTM that
> you says that creating a tablespace on a mount point itself is a security
> hole.
Generally, the root user would have to mo
On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane wrote:
> Robert Haas writes:
>> For that matter, I wonder what happens with regular function
>> permissions. If the plan inlines the function and then somebody goes
>> and changes the permission on the function and makes it SECURITY
>> DEFINER, what happ
On 18.01.2011 17:26, Shigeru HANADA wrote:
1) 20110118-no_fdw_perm_check.patch - This patch is not included in
last post. This had been proposed on 2011-01-05 first, but maybe has
not been reviewd yet. I re-propose this patch for SQL standard
conformance. This patch removes permission check th
On Fri, Jan 21, 2011 at 15:51, Tom Lane wrote:
> Magnus Hagander writes:
>> I came across a case this week where I wanted to be able to determine
>> more detailed auth information on already logged in sessions - not
>> from the client, but from the server. In this specific case, I wanted
>> to ex
2011/1/21 Robert Haas :
> On Fri, Jan 21, 2011 at 8:05 AM, Nicolas Barbier
> wrote:
>
>> 2011/1/21 Anssi Kääriäinen :
>>
>>> Sorry for bothering all of you, but I just don't get this. What if T2 rolls
>>> back instead of committing? Then the snapshot of T3 would have been valid,
>>> right? Now, f
Robert Haas wrote:
> On Thu, Jan 20, 2011 at 4:40 PM, Simone Aiken
> wrote:
> > After playing with this in benchmarks and researching the weird results I
> > got I'm going to advise dropping the todo for now unless something happens
> > to change how postgres handles clustering.
>
> I agree, let'
Robert Haas wrote:
> On Fri, Jan 21, 2011 at 8:05 AM, Nicolas Barbier
>> This has been discussed before; in [1] I summarized:
>>
>> "IOW, one could say that the backup is consistent only if it were
>> never compared against the system as it continued running after
>> the dump took place."
>
> B
Robert Haas writes:
> For that matter, I wonder what happens with regular function
> permissions. If the plan inlines the function and then somebody goes
> and changes the permission on the function and makes it SECURITY
> DEFINER, what happens?
ALTER FUNCTION is supposed to cause plan invalidat
On 01/21/2011 02:21 PM, Florian Pflug wrote:
Still, the would dump reflects a database state that *logically* never existed
(i.e. not in any serial schedule). If you dump for disaster recovery, you might
not care. If you dump to copy the data onto some reporting server you might.
best regards,
Magnus Hagander writes:
> I came across a case this week where I wanted to be able to determine
> more detailed auth information on already logged in sessions - not
> from the client, but from the server. In this specific case, I wanted
> to examine the "is ssl" flag on the connection. But I can s
"Kevin Grittner" wrote:
> (1) A read write transaction might need to be canceled to
> prevent the view of the data a committed read only transaction has
> already seen from becoming inconsistent. (Dan's example)
And this one seems entirely a theoretical possibility. I spent a
little time lo
I came across a case this week where I wanted to be able to determine
more detailed auth information on already logged in sessions - not
from the client, but from the server. In this specific case, I wanted
to examine the "is ssl" flag on the connection. But I can see other
things being interesting
On Fri, Jan 21, 2011 at 8:59 AM, Itagaki Takahiro
wrote:
> On Fri, Jan 21, 2011 at 22:12, Shigeru HANADA
> wrote:
>>> My concern is the explainInfo interface is not ideal for the purpose
>>> and therefore it will be unstable interface. If we support nested plans
>>> in FDWs, each FDW should rece
2011/1/21 KaiGai Kohei :
> - Add checks to avoid inlining function without db_procedure:{execute}
> permission. Sorry, process:{transition} shall be checked in other place.
Hrm. What happens if permissions change between plan time and execution time?
For that matter, I wonder what happens with
On Fri, Jan 21, 2011 at 22:12, Shigeru HANADA wrote:
>> My concern is the explainInfo interface is not ideal for the purpose
>> and therefore it will be unstable interface. If we support nested plans
>> in FDWs, each FDW should receive a tree writer used internally in
>> explain.c. explainInfo, th
On Thu, Jan 20, 2011 at 6:14 PM, Tom Lane wrote:
> So I'm not sure whether to fix it, or leave it as a known failure case
> in old branches. Comments?
Since there is a workaround, I think it is best to document it and
leave it as-is.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
On Fri, Jan 21, 2011 at 8:05 AM, Nicolas Barbier
wrote:
> 2011/1/21 Anssi Kääriäinen :
>
>> Sorry for bothering all of you, but I just don't get this. What if T2 rolls
>> back instead of committing? Then the snapshot of T3 would have been valid,
>> right? Now, for the snapshot of T3 it doesn't mat
Heikki Linnakangas wrote:
> It's not the order in which the xid was assigned that matters, but
> the order the transactions started and got their snapshots. The
> xids might be assigned a lot later, after the transactions have
> already read data.
>From the "Apparent Serial Order of Execution"
On Fri, Jan 21, 2011 at 4:41 AM, Heikki Linnakangas
wrote:
> There's one UI thing that bothers me. The option to specify the target
> directory is called --file. But it's clearly not a file. OTOH, I'd hate to
> introduce a parallel --dir option just for this. Any thoughts on this?
If we were star
On Fri, Jan 21, 2011 at 14:24, Simon Riggs wrote:
> On Fri, 2011-01-21 at 14:45 +0200, Heikki Linnakangas wrote:
>> * it seems like overkill to not let clients to even connect when
>> allow_standalone_primary=off and no synchronous standbys are available.
>> What if you just want to run a read-onl
On Fri, Jan 21, 2011 at 7:45 AM, Heikki Linnakangas
wrote:
> * it seems like overkill to not let clients to even connect when
> allow_standalone_primary=off and no synchronous standbys are available. What
> if you just want to run a read-only query?
For what it's worth, +1.
--
Robert Haas
Enter
On Fri, Jan 21, 2011 at 7:48 AM, Simon Riggs wrote:
> Ah, thanks Florian. Now I understand. There are two related issues here.
>
> 1. The discussion around ERRCODE_ADMIN_SHUTDOWN is incorrect and the
> specific patch should be rejected as is. No changes are required in
> ProcessInterrupts(), nor n
On Fri, 2011-01-21 at 14:45 +0200, Heikki Linnakangas wrote:
> (grr, I wrote this on Monday already, but just found it in my drafts
> folder, unsent)
No worries, thanks for commenting.
> Thanks! Some quick observations after first read-through:
>
> * The docs for synchronous_replication still c
On Thu, Jan 20, 2011 at 03:48, Peter Geoghegan
wrote:
> I think that a major goal of the DocBook format is that it separates
> content from presentation, so whatever tool is used to render that
> content as HTML for .org isn't necessarily publicly available.
Sure it is. And FWIW, it just uses the
On Thu, 20 Jan 2011 22:21:37 +0900
Itagaki Takahiro wrote:
> On Wed, Jan 19, 2011 at 00:34, Shigeru HANADA
> wrote:
> > Attached patch requires FDW API patches and copy_export-20110114.patch.
>
> Some minor comments:
Thanks for the comments.
I'll post revised version of patches in new threads.
2011/1/21 Anssi Kääriäinen :
> Sorry for bothering all of you, but I just don't get this. What if T2 rolls
> back instead of committing? Then the snapshot of T3 would have been valid,
> right? Now, for the snapshot of T3 it doesn't matter if T2 commits or if it
> doesn't, because it can't see the
On Jan21, 2011, at 10:19 , Heikki Linnakangas wrote:
> On 21.01.2011 11:10, Simon Riggs wrote:
>> So any xid that commits in a different sequence to the order in which
>> the xid was assigned creates a potential for unserialization? Or?
>
> It's not the order in which the xid was assigned that mat
On Fri, 2011-01-21 at 13:09 +0100, Florian Pflug wrote:
> >
> >>> I'd also be in favor of changing the one that uses
> >>> ERRCODE_QUERY_CANCELLED to use ERRCODE_T_R_SERIALIZATION_FAILURE, as
> >>> the former might be taken to imply active user intervention, and for
> >>> consistency.
> >>
> >> +
(grr, I wrote this on Monday already, but just found it in my drafts
folder, unsent)
On 15.01.2011 23:40, Simon Riggs wrote:
Here's the latest patch for sync rep.
From here, I will be developing the patch further on public git
repository towards commit. My expectation is that commit is at l
On Fri, Jan 21, 2011 at 07:02, Fujii Masao wrote:
> On Fri, Jan 21, 2011 at 1:00 AM, Tom Lane wrote:
>> Fujii Masao writes:
>>> On Thu, Jan 20, 2011 at 10:53 AM, Tom Lane wrote:
>> In the case you sketch, there would be nothing to stop the (non root)
>> postgres user from renaming $PGDATA/mnt t
On Jan21, 2011, at 03:29 , Tom Lane wrote:
> "Kevin Grittner" writes:
>>> Robert Haas wrote:
>>> Oh, you mean water that had some things you didn't want taken out
>>> of it?
>
>> Right -- God only knows the number of things were filtered out to
>> leave me with filtered water. What's "filtered"
On Jan21, 2011, at 12:55 , Anssi Kääriäinen wrote:
> On 01/21/2011 03:25 AM, Florian Pflug wrote:
>> The COMMIT order in the actual, concurrent, schedule doesn't not necessarily
>> represent the order of the transaction in an equivalent serial schedule.
>> Here's
>> an example
>>
>> T1: BEGIN SER
1 - 100 of 112 matches
Mail list logo
