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 ques
On Mon, Feb 6, 2012 at 4:48 AM, Bruce Momjian wrote:
> On Sun, Feb 05, 2012 at 08:40:09PM +, Simon Riggs wrote:
>> On Sun, Feb 5, 2012 at 3:59 AM, Bruce Momjian wrote:
>> > On Sat, Dec 24, 2011 at 03:56:58PM +, Simon Riggs wrote:
>> >> > Also, as far as I can see this patch usurps the pag
On Mon, Feb 6, 2012 at 7:51 AM, Heikki Linnakangas
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 used as a checksum ra
On Sun, Feb 5, 2012 at 10:23 PM, Tom Lane wrote:
> Simon Riggs 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 updates of
> shared-memory state. Afte
On Sun, Feb 5, 2012 at 11:14 PM, Tom Lane wrote:
> Simon Riggs 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 replay of DROP
> TABLESPACE. I had
On 06.02.2012 10:05, Simon Riggs wrote:
On Mon, Feb 6, 2012 at 7:51 AM, Heikki Linnakangas
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 good thing is I don't
remember anyone
On Mon, Feb 6, 2012 at 10:02 AM, Heikki Linnakangas
wrote:
> On 06.02.2012 10:05, Simon Riggs wrote:
>>
>> On Mon, Feb 6, 2012 at 7:51 AM, Heikki Linnakangas
>> wrote:
>>>
>>> On 06.02.2012 05:48, Bruce Momjian wrote:
Thanks. Clearly we don't need 16 bits to represent our page ve
On 06.02.2012 11:25, Simon Riggs wrote:
On Mon, Feb 6, 2012 at 10:02 AM, Heikki Linnakangas
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, by allowing clog to grow indefinite
On Sat, Jan 28, 2012 at 7:31 AM, Dan Scales 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 *base backup*. Beca
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, t
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
> 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 if
> > there's mor
On Sat, Feb 4, 2012 at 2:13 PM, Jeff Janes 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 something like c
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 C
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.
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=b2e431a4db81a735d1474c4d1565a20b8358
On Thu, Feb 2, 2012 at 4:33 AM, Alvaro Herrera 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. The only solution h
On Mon, Feb 6, 2012 at 9:31 AM, Alvaro Herrera
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, unless I'm confused, a
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 ch
2012/2/6 zoulx1982 :
> 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(
Robert Haas writes:
> 2012/2/6 zoulx1982 :
>> 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 be squishy about
the length of the
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:
http://ww
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 wrote:
> On 16 January 2012 21:30, Josh Berkus 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 conditions.
>
> Can you remem
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 Arra
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 loc
Simon Riggs 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* empty so far as full-
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
>
On Mon, Feb 6, 2012 at 6:32 PM, Tom Lane wrote:
> Simon Riggs 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 s
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 y
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
> 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 wi
On Fri, Jan 27, 2012 at 09:37:37AM -0500, Robert Haas wrote:
> On Fri, Jan 27, 2012 at 9:27 AM, Peter Geoghegan
> 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.
>
> Sure it'
Pavan Deolasee 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 fails when the
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 diffe
On 6 February 2012 21:19, Bruce Momjian 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 more natural w
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 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 unfortun
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 wrote:
> > > Peter Geoghegan obviously has done some serious work in improving
> > > sorting, and worked well with the commu
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 an
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 o
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 --disable-integer-datetim
On Thu, Feb 2, 2012 at 8:11 PM, Robert Haas wrote:
> On Wed, Feb 1, 2012 at 5:23 AM, Chetan Suttraway
> wrote:
> > Hi All,
> >
> > This is regarding the TODO item :
> > "Add SPI_gettypmod() to return a field's typemod from a TupleDesc"
> >
> > The related message is:
> > http://archives.postgres
On Tue, Feb 7, 2012 at 2:58 PM, Fujii Masao 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 pg_receivexlog handles the s
42 matches
Mail list logo
