On Wed, Jan 19, 2011 at 1:12 PM, Fujii Masao wrote:
>>> + r = PQgetCopyData(conn, ©buf, 0);
>>> + if (r == -1)
>>>
>>> Since -1 of PQgetCopyData might indicate an error, in this case,
>>> we would need to call PQgetResult?.
>>
>> Uh, -1 means end of data, no? -2 means e
On Thu, Jan 20, 2011 at 8:13 PM, Itagaki Takahiro
wrote:
> On Fri, Jan 21, 2011 at 09:11, Bruce Momjian wrote:
>> What happened to our work to add a JSON data type for PG 9.1?
>
> Nothing will happen in 9.1.
> I assume we are in "competition" status:
>
> http://archives.postgresql.org/pgsql-hacke
On Fri, 2011-01-21 at 02:32 -0500, Dan Ports wrote:
> On Fri, Jan 21, 2011 at 08:44:59AM +0200, Heikki Linnakangas wrote:
> > We have enough information in the standby to reconstruct all writes done
> > in the master. I gather that's not enough, in order to roll back
> > read-only transaction T3
On Fri, 2011-01-21 at 13:49 +0900, Tatsuo Ishii wrote:
> >
> > I'm pretty well convinced that we should NOT be issuing
> > ERRCODE_ADMIN_SHUTDOWN for a recovery conflict, but that could be
> > fixed by a trivial simplification of the code posted above, without
> > introducing any new error code.
>
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 matters, but the
order the transactions started and got their sn
On 20.01.2011 17:22, Heikki Linnakangas wrote:
(I'm working on this, no need to submit a new patch)
Ok, here's a heavily refactored version of this (also available at
git://git.postgresql.org/git/users/heikki/postgres.git, branch
pg_dump_directory). The directory format is now identical to th
On Fri, 2011-01-21 at 11:19 +0200, 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 assigne
On Fri, Jan 21, 2011 at 13:56, Tatsuo Ishii wrote:
>> Here is the patch to implement the feature.
>>
>> 1) pg_terminate_backend() sends SIGUSR1 signal rather than SIGTERM to
>> the target backend.
>> 2) The infrastructure used for message passing is
>> storage/ipc/procsignal.c The new messag
On Fri, Jan 21, 2011 at 04:06, Andrew Dunstan wrote:
>
>
> On 01/20/2011 09:52 PM, Robert Haas wrote:
>>
>> On Thu, Jan 20, 2011 at 10:17 AM, XiaoboGu wrote:
>>>
>>> Hi,
>>> We are using R to work with 64bit PostgreSQL client libraries, and
>>> to avoid compiler compatibility issues the R
On Tue, Jan 18, 2011 at 09:33, Kevin Grittner
wrote:
> Review for CF:
Thank your for the review!
> Since it doesn't appear to be intended to change any user-visible
> behavior, I don't see any need for docs or changes to the regression
> tests.
There might be some user-visible behaviors in erro
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 SERIALIZABLE; -- (Assume snapshot is set here)
T1: UPDATE D1 ... ;
T2: BE
On Jan21, 2011, at 10:16 , Simon Riggs wrote:
> On Fri, 2011-01-21 at 13:49 +0900, Tatsuo Ishii wrote:
>>
>>> I'm pretty well convinced that we should NOT be issuing
>>> ERRCODE_ADMIN_SHUTDOWN for a recovery conflict, but that could be
>>> fixed by a trivial simplification of the code posted above
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
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 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
(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, 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.
> >>
> >> +
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
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 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.
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 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 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, 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 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 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
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 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
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 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
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 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
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
"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
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
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,
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
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 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'
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
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
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 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
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 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
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
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 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
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 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.
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 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
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: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 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
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 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
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 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: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: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: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
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 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
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 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
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
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
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
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 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
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 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
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, 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
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 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
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 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 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?
-
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
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
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
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
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 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
"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
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
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
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
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, 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
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
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
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
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?
>
>
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
"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
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
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
1 - 100 of 112 matches
Mail list logo