On Sun, Feb 19, 2012 at 05:04:06PM -0500, Robert Haas wrote:
> On Sun, Feb 19, 2012 at 11:35 AM, Simon Riggs wrote:
> >> So, when the page has a checksum, PD_CHECKSUM2 is not set, and when it
> >> doesn't have a checksum, PD_CHECKSUM2 is not set? ?What good does that
> >> do?
> >
> > As explained
On Tue, Feb 14, 2012 at 02:04:26AM -0500, Jaime Casanova wrote:
> On Wed, Jan 25, 2012 at 9:47 PM, Noah Misch wrote:
> >
> > With all that done, run some quick benchmarks: see how "SELECT free_percent
> > FROM pgstattuple(rel)" fares compared to "SELECT relation_free_space(rel)"
> > for
> > a lar
I just took this for spin. Everything I tried worked, docs built and
read fine. The description of how "dirty" differs from "written" is a
bit cryptic, but I don't see an easy way to do better without a whole
new section on that topic. Once the extension upgrade questions are
sorted out, I'd
On 02/21/2012 04:44 PM, Dimitri Fontaine wrote:
The solution would be to be able to create hstore 1.1 from 1.0
automatically and I sent over a very simple patch to do that, albeit
after the deadline for the current CF (that's why it's not listed).
Maybe that's simple enough to be considered? (re
On Tue, Feb 21, 2012 at 8:19 PM, Fujii Masao wrote:
> On Sat, Feb 18, 2012 at 12:36 AM, Heikki Linnakangas
> wrote:
>> Attached is a new version, fixing that, and off-by-one bug you pointed out
>> in the slot wraparound handling. I also moved code around a bit, I think
>> this new division of lab
Alvaro Herrera writes:
> Excerpts from Alvaro Herrera's message of mar feb 21 15:54:03 -0300 2012:
>> Excerpts from Tom Lane's message of lun feb 20 12:37:45 -0300 2012:
>>> As per http://archives.postgresql.org/pgsql-general/2012-02/msg00304.php
>>> there is no switch case in shdepReassignOwned f
On Wed, Feb 22, 2012 at 12:27:57AM +0900, Kyotaro HORIGUCHI wrote:
> fe-exec.c
> - PQskipResult() is added instead of PGskipRemainigResults().
It must free the PGresults that PQgetResult() returns.
Also, please fix 2 issues mentined here:
http://archives.postgresql.org/message-id/CACMqXCLvpkj
Hello Erik,
Il 21/02/12 16:22, Erik Rijkers ha scritto:
(I reply to an older message but I did use the newest patch, version 3)
I wanted to have a look at v3 of this patch today, but it seems it won't apply
and compile anymore.
As Peter pointed out, it is due to a new Boolean field added in
Excerpts from Alvaro Herrera's message of mar feb 21 15:54:03 -0300 2012:
> Excerpts from Tom Lane's message of lun feb 20 12:37:45 -0300 2012:
> > Robert Haas writes:
> > > On Wed, Feb 15, 2012 at 12:58 PM, Tom Lane wrote:
> > >> As per http://archives.postgresql.org/pgsql-general/2012-02/msg003
Fujii Masao writes:
>>> Though I'm not familiar with CREATE EXTENSION. Why did you exclude 1.0.sql
>>> from DATA? In hstore/Makefile, 1.0.sql is included. You think we should
>>> prevent
>>> old version (i.e., 1.0) of pg_stat_statements from being used in 9.2?
>>
>> I'm not sure. My feeling is t
Sandro Santilli writes:
> On Tue, Feb 21, 2012 at 10:21:17AM -0500, Tom Lane wrote:
>> Sandro Santilli writes:
>> > I'm trying to understand what options I have to test "CREATE EXTENSION"
>> > w/out installing the extension files in their final destination.
>>
>> There aren't any. Generally spe
Fujii Masao writes:
> [Reminder]
> New minor version updates are about to be released in the next Monday.
> Could you backport this commit to 9.1 and 9.0?
Note that Monday is not the deadline to get patches in; it's more like
tomorrow, if you'd like to see a full buildfarm cycle on your patch
bef
On 21 February 2012 20:30, Tom Lane wrote:
> Peter Geoghegan writes:
>> My pg_stat_statements normalisation patch actually extends the
>> underlying hash_any() function to support 8 byte results,
>
> ... er, what? That seems rather out of scope for that patch,
> not to mention unnecessary.
Well
On Tue, Feb 21, 2012 at 12:14:03PM -0800, David E. Wheeler wrote:
> On Feb 21, 2012, at 12:11 PM, Michael Glaesemann wrote:
>
> > And hashtext *has* changed across versions, which is why Peter Eisentraut
> > published a version-independent hash function library:
> > https://github.com/petere/pgv
Peter Geoghegan writes:
> My pg_stat_statements normalisation patch actually extends the
> underlying hash_any() function to support 8 byte results,
... er, what? That seems rather out of scope for that patch,
not to mention unnecessary.
regards, tom lane
--
Sent via p
On Feb 21, 2012, at 12:14 PM, David E. Wheeler wrote:
>> And hashtext *has* changed across versions, which is why Peter Eisentraut
>> published a version-independent hash function library:
>> https://github.com/petere/pgvihash
>
> Yes, Marko wrote one, too:
>
> https://github.com/markokr/pgha
On Feb 21, 2012, at 12:11 PM, Michael Glaesemann wrote:
> And hashtext *has* changed across versions, which is why Peter Eisentraut
> published a version-independent hash function library:
> https://github.com/petere/pgvihash
Yes, Marko wrote one, too:
https://github.com/markokr/pghashlib
B
On 21 February 2012 20:01, Tom Lane wrote:
> "David E. Wheeler" writes:
>> Is there a reason that hashtext() and friends are not documented?
>
> Yes. They are internal functions that exist for the convenience of the
> system, not for users. We've discussed this before, and decided that
> we don
On Feb 21, 2012, at 15:01, Tom Lane wrote:
> "David E. Wheeler" writes:
>> Is there a reason that hashtext() and friends are not documented?
>
> Yes. They are internal functions that exist for the convenience of the
> system, not for users. We've discussed this before, and decided that
> we d
"David E. Wheeler" writes:
> Is there a reason that hashtext() and friends are not documented?
Yes. They are internal functions that exist for the convenience of the
system, not for users. We've discussed this before, and decided that
we don't want people to rely on them continuing to have exac
Hackers,
Is there a reason that hashtext() and friends are not documented? Given that
they’re likely to be used more and more for partitioning and sharding, I think
it would be useful to do so, starting with something like this. Comments?
*** a/doc/src/sgml/func.sgml
--- b/doc/src/sgml/func.sgm
Excerpts from Tom Lane's message of lun feb 20 12:37:45 -0300 2012:
> Robert Haas writes:
> > On Wed, Feb 15, 2012 at 12:58 PM, Tom Lane wrote:
> >> As per http://archives.postgresql.org/pgsql-general/2012-02/msg00304.php
> >> there is no switch case in shdepReassignOwned for foreign data wrappe
On 21 February 2012 15:22, Erik Rijkers wrote:
> (I reply to an older message but I did use the newest patch, version 3)
>
> I wanted to have a look at v3 of this patch today, but it seems it won't
> apply and compile anymore.
That's just because a new column has been added to pg_proc -
proleakp
Maxim Boguk writes:
> On Tue, Feb 21, 2012 at 5:32 PM, Tom Lane wrote:
>> If the index key values are not private information, could we see that
>> with "pg_filedump -i -f" not just bare?
> There is it:
> http://maximboguk.com/static/etc/agency_statistics_pkey.pg_full_filedump.gz
Thanks. The i
On Tue, Feb 21, 2012 at 10:21:17AM -0500, Tom Lane wrote:
> Sandro Santilli writes:
> > I'm trying to understand what options I have to test "CREATE EXTENSION"
> > w/out installing the extension files in their final destination.
>
> There aren't any. Generally speaking, if you want to be testing
Reference:
http://archives.postgresql.org/message-id/4f00ca9e.9000...@dunslane.net
This patch adds support for two new environment variables:
PSQL_HISTORY: Alternative location for the command history file.
PSQLRC: Alternative location of the user's .psqlrc file.
The context diff patch applies
On 21/02/12 18:05, Peter Eisentraut wrote:
> On sön, 2012-02-19 at 22:29 -0500, Tom Lane wrote:
>> My only comment is whether elog(ERROR) is appropriate, ie, do we
>> consider these to be internal errors that users will never see in
>> practice? If there's a significant risk of the error being thro
On Tue, Feb 21, 2012 at 4:46 PM, Fujii Masao wrote:
> [Reminder]
> New minor version updates are about to be released in the next Monday.
> Could you backport this commit to 9.1 and 9.0?
Sure
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, T
On sön, 2012-02-19 at 22:29 -0500, Tom Lane wrote:
> My only comment is whether elog(ERROR) is appropriate, ie, do we
> consider these to be internal errors that users will never see in
> practice? If there's a significant risk of the error being thrown in
> the field, it might be better to use ere
On Sun, Feb 19, 2012 at 6:20 PM, Don Baccus wrote:
>
> On Feb 19, 2012, at 5:42 PM, Tom Lane wrote:
>
>> Robert Haas writes:
>>> Having now spent far too much time in bed with that patch, I'm feeling
>>> like the concept that we are really looking for there is what some
>>> languages call "pure"
On Mon, Feb 13, 2012 at 11:17 AM, Fujii Masao wrote:
> On Mon, Jan 16, 2012 at 10:44 AM, Fujii Masao wrote:
>> On Fri, Jan 13, 2012 at 10:05 PM, Simon Riggs wrote:
>>> Correctly initialise shared recoveryLastRecPtr in recovery.
>>> Previously we used ReadRecPtr rather than EndRecPtr, which was
>
2012/2/15 MauMau :
> Hello
>
> I encountered a bug which always causes PostgreSQL to crash on Windows.
> Attached is a patch that fixes it. Please review it and include it in the
> upcoming minor releases of supported versions.
Thanks - good analysis, and good patch. Applied for head and
backpatch
On Sun, Feb 19, 2012 at 8:20 PM, Don Baccus wrote:
>
> On Feb 19, 2012, at 5:42 PM, Tom Lane wrote:
>
>> Robert Haas writes:
>>> Having now spent far too much time in bed with that patch, I'm feeling
>>> like the concept that we are really looking for there is what some
>>> languages call "pure"
Peter Eisentraut writes:
> On mån, 2012-02-20 at 01:17 -0500, Robert Haas wrote:
>> For the present application (pushdown into security views), we really
>> only care whether the function has side effects, such as throwing an
>> error or mutating global state.
> How about [NO] SIDEEFFECTS?
Well
On mån, 2012-02-20 at 01:17 -0500, Robert Haas wrote:
> For the present application (pushdown into security views), we really
> only care whether the function has side effects, such as throwing an
> error or mutating global state.
How about [NO] SIDEEFFECTS?
--
Sent via pgsql-hackers mailing li
(I reply to an older message but I did use the newest patch, version 3)
I wanted to have a look at v3 of this patch today, but it seems it won't apply
and compile anymore.
Here are the protestations of patch:
patching file src/include/catalog/pg_proc.h
Hunk #1 FAILED at 868.
Hunk #2 FAILED at
Sandro Santilli writes:
> I'm trying to understand what options I have to test "CREATE EXTENSION"
> w/out installing the extension files in their final destination.
There aren't any. Generally speaking, if you want to be testing an
extension, you should be doing it in a test installation anyway;
On Tue, Feb 21, 2012 at 10:07 AM, Noah Misch wrote:
> Consequently, I find the idea of requiring
> a spinlock acquisition to read or write pd_lsn/pd_tli under BUFFER_LOCK_SHARE
> to be a sensible one.
OK
> Within that umbrella, some details need attention:
>
> - Not all BUFFER_LOCK_SHARE caller
Hello
I had to reply to query about usage VACUUM ANALYZE or ANALYZE. I
expected so ANALYZE should be faster then VACUUM ANALYZE.
But is not true. Why?
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.p
(2012/02/15 20:50), Etsuro Fujita wrote:
> (2012/02/14 23:50), Tom Lane wrote:
>>> (2012/02/14 17:40), Etsuro Fujita wrote:
As discussed at
that thread, it would have to change the PlanForeignScan API to let the
FDW generate multiple paths and dump them all to add_path instead of
>>>
On Sat, Feb 18, 2012 at 12:36 AM, Heikki Linnakangas
wrote:
> Attached is a new version, fixing that, and off-by-one bug you pointed out
> in the slot wraparound handling. I also moved code around a bit, I think
> this new division of labor between the XLogInsert subroutines is more
> readable.
T
Thank you. Everything seems clear.
Please wait for a while.
> PQskipResult:
> - store old callback and param in local vars
> - set do-nothing row callback
> - call PQgetresu
>
> On Tue, Feb 21, 2012 at 12:13 PM, Kyotaro HORIGUCHI
> wrote:
> >> > - PQskipResult(conn, true) makes all consequent PQg
Hello
2012/2/21 aasat :
> I have question. GET STACKED DIAGNOSTICS work only in exception block? is it
> posible to use it in separate function called in exception block?
>
Stacked diagnostick will be in 9.2 and it is allowed only in exception block.
Regards
Pavel Stehule
>
> EXCEPTION
> WHEN
On Tue, Feb 21, 2012 at 12:13 PM, Kyotaro HORIGUCHI
wrote:
>> > - PQskipResult(conn, true) makes all consequent PQgetResult()'s
>> > to skip all the rows.
>
> Well, Is this right?
Yes, call getResult() until it returns NULL.
>> > If this is right, row processor should stay also in PGresult
>> >
I'm trying to understand what options I have to test "CREATE EXTENSION"
w/out installing the extension files in their final destination.
Could not find a way to set SHAREDIR from within psql, nor a way
to specify it in initdb call. Am I missing it something ?
PS: please include my address in repl
Hello,
> Note I dropped the row processor from under PGresult.
> Please don't put it back there.
I overlooked that. I understand it.
> > This seems also can be done by the return value of
> > PQsetRowProcessor() (currently void). Anyway, I provide this
> > function and also change the return val
On Mon, Feb 20, 2012 at 08:57:08AM -0500, Robert Haas wrote:
> On Mon, Feb 20, 2012 at 4:18 AM, Simon Riggs wrote:
> > What straightforward implementation is that?? This *is* the straightforward
> > one.
> >
> > God knows what else we'd break if we drop the lock, reacquire as an
> > exclusive, th
On 21 February 2012 01:48, Tom Lane wrote:
> you're proposing to move the error pointer to the "42", and that does
> not seem like an improvement, especially not if it only happens when the
> cast subject is a simple constant rather than an expression.
I'm not actually proposing that though. What
On Tue, Feb 21, 2012 at 11:42 AM, Kyotaro HORIGUCHI
wrote:
>> Also, as row handler is on connection, then changing it's
>> behavior is connection context, not result.
>
> OK, current implement copying the pointer to the row processor
> from PGconn to PGresult and getAnotherTuple() using it on
> PG
Sorry, I should fix a wrong word selection..
> Let me confirm the effects of this function. Is the below
> description right?
>
> - PQskipResult(conn, false) makes just following PQgetResult() to
> skip current bunch of rows and the consequent PQgetResult()'s
> gathers rows as usual.
- PQski
Hello,
> > I don't have any attachment to PQskipRemainingResults(), but I
> > think that some formal method to skip until Command-Complete('C')
> > without breaking session is necessary because current libpq does
> > so.
>
> We have such function: PQgetResult(). Only question is how
> to flag th
I have question. GET STACKED DIAGNOSTICS work only in exception block? is it
posible to use it in separate function called in exception block?
EXCEPTION
WHEN others THEN
peform log_error();
END;
CREATE OR REPLACE FUNCTION log_error()
RETURNS boolean AS
$BODY$
declare
v_state TEXT;
52 matches
Mail list logo
