On Wed, Jan 19, 2011 at 1:12 PM, Fujii Masao masao.fu...@gmail.com wrote:
+ r = PQgetCopyData(conn, copybuf, 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
On Thu, Jan 20, 2011 at 8:13 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Fri, Jan 21, 2011 at 09:11, Bruce Momjian br...@momjian.us 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:
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 the
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.
I agree
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
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
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 assigned that
On Fri, Jan 21, 2011 at 13:56, Tatsuo Ishii is...@postgresql.org 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
On Fri, Jan 21, 2011 at 04:06, Andrew Dunstan and...@dunslane.net wrote:
On 01/20/2011 09:52 PM, Robert Haas wrote:
On Thu, Jan 20, 2011 at 10:17 AM, XiaoboGuguxiaobo1...@gmail.com wrote:
Hi,
We are using R to work with 64bit PostgreSQL client libraries, and
to avoid compiler
On Tue, Jan 18, 2011 at 09:33, Kevin Grittner
kevin.gritt...@wicourts.gov 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
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:
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, without
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 SERIALIZABLE;
On Jan21, 2011, at 03:29 , Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov 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
On Fri, Jan 21, 2011 at 07:02, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Jan 21, 2011 at 1:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
On Thu, Jan 20, 2011 at 10:53 AM, Tom Lane t...@sss.pgh.pa.us wrote:
In the case you sketch, there would be
(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
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.
+1.
We already use
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 matters,
2011/1/21 Anssi Kääriäinen anssi.kaariai...@thl.fi:
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,
On Thu, 20 Jan 2011 22:21:37 +0900
Itagaki Takahiro itagaki.takah...@gmail.com wrote:
On Wed, Jan 19, 2011 at 00:34, Shigeru HANADA han...@metrosystems.co.jp
wrote:
Attached patch requires FDW API patches and copy_export-20110114.patch.
Some minor comments:
Thanks for the comments.
I'll
On Thu, Jan 20, 2011 at 03:48, Peter Geoghegan
peter.geoghega...@gmail.com 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.
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 claim
On Fri, Jan 21, 2011 at 7:48 AM, Simon Riggs si...@2ndquadrant.com 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
On Fri, Jan 21, 2011 at 7:45 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Fri, Jan 21, 2011 at 14:24, Simon Riggs si...@2ndquadrant.com 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
On Fri, Jan 21, 2011 at 4:41 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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
nicolas.barb...@gmail.com wrote:
2011/1/21 Anssi Kääriäinen anssi.kaariai...@thl.fi:
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?
On Thu, Jan 20, 2011 at 6:14 PM, Tom Lane t...@sss.pgh.pa.us 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
On Fri, Jan 21, 2011 at 22:12, Shigeru HANADA han...@metrosystems.co.jp 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
2011/1/21 KaiGai Kohei kai...@ak.jp.nec.com:
- 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
On Fri, Jan 21, 2011 at 8:59 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Fri, Jan 21, 2011 at 22:12, Shigeru HANADA han...@metrosystems.co.jp
wrote:
My concern is the explainInfo interface is not ideal for the purpose
and therefore it will be unstable interface. If we support
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 kevin.gritt...@wicourts.gov 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
Magnus Hagander mag...@hagander.net 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
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
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
Robert Haas wrote:
On Thu, Jan 20, 2011 at 4:40 PM, Simone Aiken
sai...@quietlycompetent.com 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
2011/1/21 Robert Haas robertmh...@gmail.com:
On Fri, Jan 21, 2011 at 8:05 AM, Nicolas Barbier
nicolas.barb...@gmail.com wrote:
2011/1/21 Anssi Kääriäinen anssi.kaariai...@thl.fi:
Sorry for bothering all of you, but I just don't get this. What if T2 rolls
back instead of committing? Then
On Fri, Jan 21, 2011 at 15:51, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net 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
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
On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Fujii Masao masao.fu...@gmail.com 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
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
On Fri, Jan 21, 2011 at 10:14 AM, Magnus Hagander mag...@hagander.net wrote:
On Fri, Jan 21, 2011 at 15:51, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
I came across a case this week where I wanted to be able to determine
more detailed auth information on
Simon Riggs si...@2ndquadrant.com 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
On Fri, Jan 21, 2011 at 16:24, Andrew Dunstan and...@dunslane.net 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 robertmh...@gmail.com wrote:
On Fri, Jan 21, 2011 at 10:14 AM, Magnus Hagander mag...@hagander.net wrote:
On Fri, Jan 21, 2011 at 15:51, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
I came across a case this week
On 21.01.2011 15:35, Robert Haas wrote:
On Fri, Jan 21, 2011 at 4:41 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
Itagaki Takahiro itagaki.takah...@gmail.com writes:
On Fri, Jan 21, 2011 at 13:56, Tatsuo Ishii is...@postgresql.org 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
On Fri, Jan 21, 2011 at 10:32 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com 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
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
On Fri, Jan 21, 2011 at 10:34 AM, Magnus Hagander mag...@hagander.net 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
On Fri, Jan 21, 2011 at 16:40, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 21, 2011 at 10:34 AM, Magnus Hagander mag...@hagander.net 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
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us 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
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
heikki.linnakan...@enterprisedb.com wrote:
There's one UI thing that bothers me. The option to specify the target
directory is called --file. But
On Fri, Jan 21, 2011 at 10:35 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Itagaki Takahiro itagaki.takah...@gmail.com writes:
On Fri, Jan 21, 2011 at 13:56, Tatsuo Ishii is...@postgresql.org wrote:
Anyone has better idea? Tom dislikes my patch but I don't know how to
deal with it.
There was
On Fri, Jan 21, 2011 at 10:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
ALTER FUNCTION is supposed to cause plan invalidation in such a case.
Not sure if GRANT plays nice with that
On Fri, Jan 21, 2011 at 10:33 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Fri, Jan 21, 2011 at 10:43 AM, Magnus Hagander mag...@hagander.net wrote:
On Fri, Jan 21, 2011 at 16:40, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 21, 2011 at 10:34 AM, Magnus Hagander mag...@hagander.net
wrote:
Um, none of the fields I've suggested so far was connection string.
On Fri, Jan 21, 2011 at 10:17 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
2011/1/22 Robert Haas robertmh...@gmail.com:
On Fri, Jan 21, 2011 at 10:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
ALTER FUNCTION is supposed to cause plan invalidation in such a case.
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.
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 kai...@kaigai.gr.jp wrote:
2011/1/22 Robert Haas robertmh...@gmail.com:
On Fri, Jan 21, 2011 at 10:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us
2011/1/22 Robert Haas robertmh...@gmail.com:
On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
For that matter, I wonder what happens with regular function
permissions. If the plan inlines the function and then somebody goes
and
Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com 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
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
Robert Haas robertmh...@gmail.com 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
On Mon, Jan 17, 2011 at 8:23 PM, Greg Smith g...@2ndquadrant.com 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
Magnus Hagander mag...@hagander.net writes:
On Fri, Jan 21, 2011 at 16:40, Robert Haas robertmh...@gmail.com 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,
On Fri, Jan 21, 2011 at 11:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Fri, Jan 21, 2011 at 16:40, Robert Haas robertmh...@gmail.com wrote:
So... is there centralized structure which contains the info you're
thinking of exposing?
No, not today.
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 are
On Fri, 2011-01-21 at 14:34 +0100, Magnus Hagander wrote:
On Fri, Jan 21, 2011 at 14:24, Simon Riggs si...@2ndquadrant.com 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
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
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
On Fri, Jan 21, 2011 at 11:59 AM, Simon Riggs si...@2ndquadrant.com 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.
On Fri, Jan 21, 2011 at 12:23 PM, Aidan Van Dyk ai...@highrise.ca wrote:
On Fri, Jan 21, 2011 at 11:59 AM, Simon Riggs si...@2ndquadrant.com 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
On Thu, Jan 20, 2011 at 4:29 AM, Jeff Davis pg...@j-davis.com 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
Anssi Kääriäinenanssi.kaariai...@thl.fi 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
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 br...@momjian.us 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
On Fri, Jan 21, 2011 at 12:44 PM, Bosco Rama postg...@boscorama.com 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
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 21, 2011 at 12:23 PM, Aidan Van Dyk ai...@highrise.ca 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
On Fri, Jan 21, 2011 at 1:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 21, 2011 at 12:23 PM, Aidan Van Dyk ai...@highrise.ca wrote:
When no sync slave is connected, yes, I want to stop things hard.
What you're proposing is to fail things
Kevin Grittner kevin.gritt...@wicourts.gov 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:
robertmh...@gmail.com (Robert Haas) writes:
On Mon, Jan 17, 2011 at 8:23 PM, Greg Smith g...@2ndquadrant.com 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
On Fri, Jan 21, 2011 at 1:09 PM, Aidan Van Dyk ai...@highrise.ca wrote:
On Fri, Jan 21, 2011 at 1:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 21, 2011 at 12:23 PM, Aidan Van Dyk ai...@highrise.ca wrote:
When no sync slave is connected, yes, I
On Fri, Jan 21, 2011 at 1:32 PM, Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 21, 2011 at 12:44 PM, Bosco Rama postg...@boscorama.com 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
On Fri, 2011-01-21 at 12:31 -0500, Robert Haas wrote:
On Thu, Jan 20, 2011 at 4:29 AM, Jeff Davis pg...@j-davis.com 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 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 sfr...@snowman.net:
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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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?
Garick
Anyone else seeing anything like this on `make world`?
make[3]: Entering directory
`/home/kgrittn/git/postgresql/kgrittn/doc/src/sgml'
{ \
echo !entity version \9.1devel\; \
echo !entity majorversion \9.1\; \
} version.sgml
/usr/bin/perl ./mk_feature_tables.pl YES
Kevin Grittner kevin.gritt...@wicourts.gov 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
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
Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov 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
1 - 100 of 112 matches
Mail list logo
