Thanks for the comments!
(2012/02/06 5:08), Kohei KaiGai wrote:
Yes. In my opinion, one significant benefit of pgsql_fdw is to execute
qualifiers on the distributed nodes; that enables to utilize multiple
CPU resources efficiently.
Duplicate checks are reliable way to keep invisible tuples
hi，
there is a problem about type cast that i don't understand, follow is my test.
postgres=# select 10::bit(3);
bit
-
010
(1 row)
postgres=# select 10::bit varying(3);
ERROR: cannot cast type integer to bit varying
LINE 1: select 10::bit varying(3);
^
postgres=#
my
On Mon, Feb 6, 2012 at 4:48 AM, Bruce Momjian br...@momjian.us wrote:
On Sun, Feb 05, 2012 at 08:40:09PM +, Simon Riggs wrote:
On Sun, Feb 5, 2012 at 3:59 AM, Bruce Momjian br...@momjian.us wrote:
On Sat, Dec 24, 2011 at 03:56:58PM +, Simon Riggs wrote:
Also, as far as I can see
On Mon, Feb 6, 2012 at 7:51 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 06.02.2012 05:48, Bruce Momjian wrote:
On Sun, Feb 05, 2012 at 08:40:09PM +, Simon Riggs wrote:
In the proposed scheme there are two flag bits set on the page to
indicate whether the field is
On Sun, Feb 5, 2012 at 10:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
Please post the patch rather than fixing directly. There's some subtle
stuff there and it would be best to discuss first.
Here's a proposed patch for the issues around unlocked
On Sun, Feb 5, 2012 at 11:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
Please post the patch rather than fixing directly. There's some subtle
stuff there and it would be best to discuss first.
And here's a proposed patch for not throwing ERROR during
On 06.02.2012 10:05, Simon Riggs wrote:
On Mon, Feb 6, 2012 at 7:51 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 06.02.2012 05:48, Bruce Momjian wrote:
Thanks. Clearly we don't need 16 bits to represent our page version
number because we rarely change it. The other
On Mon, Feb 6, 2012 at 10:02 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 06.02.2012 10:05, Simon Riggs wrote:
On Mon, Feb 6, 2012 at 7:51 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 06.02.2012 05:48, Bruce Momjian wrote:
Thanks. Clearly
On 06.02.2012 11:25, Simon Riggs wrote:
On Mon, Feb 6, 2012 at 10:02 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Good idea. However, the followup idea to that discussion was to not only
avoid the I/O needed to mark tuples as frozen, but to avoid xid wraparound
altogether,
On Sat, Jan 28, 2012 at 7:31 AM, Dan Scales sca...@vmware.com wrote:
Let me know if you have any thoughts/comments, etc. The patch is
enclosed, and the README.doublewrites is updated a fair bit.
ISTM that the double-write can prevent torn-pages in neither double-write file
nor data file in
src/interfaces/libpq/fe-misc.c #include-s pg_config_paths.h, but in
the makefile that dependency is not declared.
This breaks the build with 'make -jN' (with a big N) ... sometimes
(non-deterministically).
Patch attached. Made from 9.1.1, but from browsing the git master on
the web interface,
Excerpts from Robert Haas's message of jue feb 02 11:24:08 -0300 2012:
On Wed, Feb 1, 2012 at 11:33 PM, Alvaro Herrera alvhe...@alvh.no-ip.org
wrote:
If there's only one remaining member, the problem is easy: replace it
with that transaction's xid, and set the appropriate hint bits. But
On Sat, Feb 4, 2012 at 2:13 PM, Jeff Janes jeff.ja...@gmail.com wrote:
We really need to nail that down. Could you post the scripts (on the
wiki) you use for running the benchmark and making the graph? I'd
like to see how much work it would be for me to change it to detect
checkpoints and do
Excerpts from Gabriele Bartolini's message of mar ene 31 12:29:51 -0300 2012:
Hi Robert,
sorry for the delay.
Il 27/01/12 15:47, Robert Haas ha scritto:
This email thread seems to have trailed off without reaching a
conclusion. The patch is marked as Waiting on Author in the
Ciao Alvaro,
Il 06/02/12 16:02, Alvaro Herrera ha scritto:
FWIW I committed this last week, though I changed the debug message
wording slightly -- hope that's OK; it can be adjusted of course.
On Thu, Feb 2, 2012 at 4:33 AM, Alvaro Herrera alvhe...@alvh.no-ip.org wrote:
However, there are cases where not even that is possible -- consider
tuple freezing during WAL recovery. Recovery is going to need to
replace those multis with other multis, but it cannot create new multis
itself.
On Mon, Feb 6, 2012 at 9:31 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Suppose you have a tuple A which is locked by a series of transactions
T0, T1, T2, ...; AIUI, each new locker is going to have to create a
new mxid with all the existing entries plus a new one for itself.
But,
On Fri, Feb 03, 2012 at 01:15:30PM +0100, Christian Ullrich wrote:
* Peter Eisentraut wrote:
I noticed ecpglib still uses PQconnectdb() with a craftily assembled
connection string. Here is a patch to use PQconnectdbParams() instead.
+ const char *conn_keywords[6];
+ const char
2012/2/6 zoulx1982 zoulx1...@163.com:
hi，
there is a problem about type cast that i don't understand, follow is my
test.
postgres=# select 10::bit(3);
bit
-
010
(1 row)
postgres=# select 10::bit varying(3);
ERROR: cannot cast type integer to bit varying
LINE 1: select 10::bit
Robert Haas robertmh...@gmail.com writes:
2012/2/6 zoulx1982 zoulx1...@163.com:
my question is why int can cast to bit , but bot for bit varying?
Off the top of my head, I'm guessing that it's just a case of nobody
having implemented it.
I have some vague recollection that we didn't want to
On 01/31/2012 11:10 PM, Andrew Dunstan wrote:
Here's a possible patch for the exclude-table-data problem along the
lines you suggest.
Should I apply this?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Mon, Feb 06, 2012 at 09:05:19AM +, Simon Riggs wrote:
In any case, I think it's a very bad idea to remove the page version field.
How are we supposed to ever be able to change the page format again if we
don't even have a version number on the page? I strongly oppose removing it.
On Sat, Feb 4, 2012 at 5:38 AM, Thomas Munro mu...@ip9.org wrote:
On 16 January 2012 21:30, Josh Berkus j...@agliodbs.com wrote:
Useful, yes. Harder than it looks, probably. I tried to mock up a
version of this years ago for a project where I needed it, and ran into
all kinds of race
Hi guys,
Please find attached version 3 of our patch. We thoroughly followed your
suggestions and were able to implement EACH foreign key constraints
with multi-column syntax as well.
EACH foreign key constraints represent PostgreSQL implementation of
what are also known as Foreign Key Arrays.
On Mon, Feb 06, 2012 at 08:51:34AM +0100, Heikki Linnakangas wrote:
I wonder if we should just dedicate 3 page header bits, call that the
page version number, and set this new version number to 1, and assume
all previous versions were zero, and have them look in the old page
version location
Simon Riggs si...@2ndquadrant.com writes:
The existing errmsg of tablespace is not empty doesn't cover all
reasons why tablespace was not removed.
Yeah, in fact that particular statement is really pretty bogus for the
replay case, because as the comment says we know that the tablespace
*is*
On Mon, Feb 06, 2012 at 12:59:59PM -0500, Bruce Momjian wrote:
I'm also not very comfortable with the idea of having flags on the page
indicating whether it has a checksum or not. It's not hard to imagine a
software of firmware bug or hardware failure that would cause pd_flags
field
On Mon, Feb 6, 2012 at 6:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
The existing errmsg of tablespace is not empty doesn't cover all
reasons why tablespace was not removed.
Yeah, in fact that particular statement is really pretty bogus for the
replay
On Fri, Feb 03, 2012 at 01:15:30PM +0100, Christian Ullrich wrote:
Shouldn't these be [7]? You can have up to 6 items, plus the terminator.
I take it only keywords have to be [7], right? Committed, thanks for spotting
this.
There seems to be one more problem that I haven't had time to tackle
Excerpts from Robert Haas's message of lun feb 06 13:19:14 -0300 2012:
On Mon, Feb 6, 2012 at 9:31 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Suppose you have a tuple A which is locked by a series of transactions
T0, T1, T2, ...; AIUI, each new locker is going to have to create
On Fri, Jan 27, 2012 at 09:37:37AM -0500, Robert Haas wrote:
On Fri, Jan 27, 2012 at 9:27 AM, Peter Geoghegan pe...@2ndquadrant.com
wrote:
Well, I don't think it's all that subjective - it's more the case that
it is just difficult, or it gets that way as you consider more
specialisations.
Pavan Deolasee pavan.deola...@gmail.com writes:
If I run the following sequence of commands, I get an assertion
failure in current HEAD.
postgres=# BEGIN;
BEGIN
postgres=# SELECT 1/0;
ERROR: division by zero
postgres=# ROLLBACK TO A;
ERROR: no such savepoint
postgres=# \q
The process
On Mon, Feb 06, 2012 at 04:19:07PM -0500, Bruce Momjian wrote:
Peter Geoghegan obviously has done some serious work in improving
sorting, and worked well with the community process. He has done enough
analysis that I am hard-pressed to see how we would get similar
improvement using a
On 6 February 2012 21:19, Bruce Momjian br...@momjian.us wrote:
Peter Geoghegan obviously has done some serious work in improving
sorting, and worked well with the community process.
Thank you for acknowledging that.
It's unfortunate that C does not support expressing these kinds of
ideas in a
I have a rough proof-of-concept for getting nearest-neighbor searches
working with cubes. When I say rough, I mean I have no idea what I'm
doing and I haven't written C for 15 years but I hear it got standardized
please don't hurt me. It seems to be about 400x faster for a 3D cube with
1
On Mon, Feb 06, 2012 at 10:49:10PM +, Peter Geoghegan wrote:
On 6 February 2012 21:19, Bruce Momjian br...@momjian.us wrote:
Peter Geoghegan obviously has done some serious work in improving
sorting, and worked well with the community process.
Thank you for acknowledging that.
It's
On Mon, Feb 06, 2012 at 06:43:04PM -0500, Bruce Momjian wrote:
On Mon, Feb 06, 2012 at 10:49:10PM +, Peter Geoghegan wrote:
On 6 February 2012 21:19, Bruce Momjian br...@momjian.us wrote:
Peter Geoghegan obviously has done some serious work in improving
sorting, and worked well with
On 11/16/2011 10:38 PM, Tom Lane wrote:
I wrote:
PFC, a patch that does this.
Upon further review, this patch would need some more work even for the
RowExpr case, because there are several places that build RowExprs
without bothering to build a valid colnames list. It's clearly soluble
if
I don't know a lot about base backup, but it sounds like full_page_writes must
be turned on for base backup, in order to deal with the inconsistent reads of
pages (which you might call torn pages) that can happen when you backup the
data files while the database is running. The relevant parts
Hi,
When I compiled HEAD with --disable-integer-datetimes and tested
pg_receivexlog, I encountered unexpected replication timeout. As
far as I read the pg_receivexlog code, the cause of this problem is
that pg_receivexlog handles the standby message timeout incorrectly
in
On Thu, Feb 2, 2012 at 8:11 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 1, 2012 at 5:23 AM, Chetan Suttraway
chetan.suttra...@enterprisedb.com wrote:
Hi All,
This is regarding the TODO item :
Add SPI_gettypmod() to return a field's typemod from a TupleDesc
The related
On Tue, Feb 7, 2012 at 2:58 PM, Fujii Masao masao.fu...@gmail.com wrote:
Hi,
When I compiled HEAD with --disable-integer-datetimes and tested
pg_receivexlog, I encountered unexpected replication timeout. As
far as I read the pg_receivexlog code, the cause of this problem is
that
42 matches
Mail list logo
