* Andrew Dunstan wrote:
Returning to the original point, I've come to the conclusion that
pure isn't the right way to go. The trouble with leakproof is that
it doesn't point to what it is that's not leaking, which is
information rather than memory, as many might imagine (and I did)
without
On tor, 2012-02-23 at 00:26 +, Affan Salman wrote:
Hey folks
It appears that the commit a445cb92ef5b3a31313ebce30e18cc1d6e0bdecb
causes ld to bail when building *without* OpenSSL support:
utils/misc/guc.o:(.data+0x4d80): undefined reference to `ssl_cert_file'
On 23 February 2012 07:15, Gianni Ciolli gianni.cio...@2ndquadrant.it wrote:
On Fri, Feb 17, 2012 at 11:43:53AM -0500, Andrew Dunstan wrote:
On 02/17/2012 11:29 AM, David E. Wheeler wrote:
On Feb 17, 2012, at 5:22 AM, Thom Brown wrote:
The purpose being to only have a single statement to set
On Wed, Feb 22, 2012 at 10:02 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 22, 2012 at 2:23 PM, Simon Riggs si...@2ndquadrant.com wrote:
The industry accepted description for non-sequential access is random
access whether or not the function that describes the movement is
entirely
(2012/02/23 5:32), Alvaro Herrera wrote:
My only concern on the patch is
+static void
+AlterForeignServerOwner_internal(Relation rel, HeapTuple tup, Oid
newOwnerId)
+{
+Form_pg_foreign_server form;
-srvId = HeapTupleGetOid(tup);
form = (Form_pg_foreign_server) GETSTRUCT(tup);
On Thu, Feb 23, 2012 at 08:26:47AM +, Thom Brown wrote:
On 23 February 2012 07:15, Gianni Ciolli gianni.cio...@2ndquadrant.it wrote:
Another complication: anonymous triggers would either have to be
alone, or provide a mechanism to manage a sequence of anonymous
triggers on the same
According to me update logs, somewhere between zlib versions 1.2.3.4 and
1.2.6, the definition of the gzFile type was changed from void * to
struct gzFile_s *, an opaque struct. Note that gzFile is already the
pointer in either case. Our code has assumed, however, that you use
gzFile like FILE,
On Wed, Feb 22, 2012 at 5:00 PM, Noah Misch n...@leadboat.com wrote:
All in all, I think this is in pretty much final shape. Only pg_upgrade
bits are still missing. If sharp eyes could give this a critical look
and knuckle-cracking testers could give it a spin, that would be
helpful.
Lack
Hello again,
I'm reviewing the revised version of pg_stat_statements again. In
particular, this new version has done away with the mechanical but
invasive change to the lexing that preserved *both* the position and
length of constant values. (See
Hello, this is new version of the patch.
# This patch is based on the commit
# 2bbd88f8f841b01efb073972b60d4dc1ff1f6fd0 @ Feb 13 to avoid the
# compile error caused by undeclared LEAKPROOF in kwlist.h.
It must free the PGresults that PQgetResult() returns.
I'm sorry. It slipped out of my
For (unit) testing, I have often had the need to override the current
timestamp in the database system. For example, a column default,
function, or views would make use of the current timestamp in some way,
and to test the behavior, it's sometimes useful to tweak the current
timestamp.
What
On 23 February 2012 09:58, Daniel Farina dan...@heroku.com wrote:
What I'm going to do here is focus on the back-end source changes that
are not part of the contrib. The size of the changes are much
reduced, but their semantics are also somewhat more complex...so, here
goes. Conclusion
2012/2/20 Yeb Havinga yebhavi...@gmail.com:
On 2012-02-05 10:09, Kohei KaiGai wrote:
The attached part-1 patch moves related routines from hooks.c to label.c
because of references to static variables. The part-2 patch implements above
mechanism.
I took a short look at this patch but am
I've updated http://highperfpostgres.com/results-write-9.2-cf4/index.htm
with more data including two alternate background writer configurations.
Since the sensitive part of the original results was scales of 500 and
1000, I've also gone back and added scale=750 runs to all results.
Quick
On Mon, Feb 13, 2012 at 3:18 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Hi,
Sorry for the delays, I'm back on PostgreSQL related work again.
Hitoshi Harada umi.tan...@gmail.com writes:
I just tried DROP EXTENSION now, and found it broken :(
Please find v2 of the patch. I did
Hi All,
Having pg_dump dump tables in clustered index order is something we've
found we've needed a fair number of times (for ex. when copying a large
logging tables or sets of tables out of one database where the order is not
maintained into another for running a bunch of backend analysis) as it
On Thu, Feb 23, 2012 at 07:14:03PM +0900, Kyotaro HORIGUCHI wrote:
Hello, this is new version of the patch.
Looks good.
By the way, I would like to ask you one question. What is the
reason why void* should be head or tail of the parameter list?
Aesthetical reasons:
1) PGresult and
On Thu, Feb 23, 2012 at 11:17 AM, Greg Smith g...@2ndquadrant.com wrote:
A second fact that's visible from the TPS graphs over the test run, and
obvious if you think about it, is that BGW writes force data to physical
disk earlier than they otherwise might go there. That's a subtle pattern in
On 23 February 2012 11:09, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 23 February 2012 09:58, Daniel Farina dan...@heroku.com wrote:
* The small changes to hashing are probably not strictly required,
unless collisions are known to get terrible.
I imagine that collisions would be rather
On 2012-02-23 10:18, Simon Riggs wrote:
However, review of such a large patch should not be simply pass or
fail. We should be looking back at the original problem and ask
ourselves whether some subset of the patch could solve a useful subset
of the problem. For me, that seems quite likely and
On Sun, Dec 4, 2011 at 12:20 PM, Noah Misch n...@leadboat.com wrote:
Making pg_multixact persistent across clean shutdowns is no bridge to cross
lightly, since it means committing to an on-disk format for an indefinite
period. We should do it; the benefits of this patch justify it, and I
On Thu, Feb 23, 2012 at 1:08 PM, Jeroen Vermeulen j...@xs4all.nl wrote:
Simon, I think you had a reason why it couldn't work, but I didn't quite get
your meaning and didn't want to distract things further at that stage. You
wrote that it doesn't do what KEY LOCKS are designed to do... any
Peter Eisentraut pete...@gmx.net writes:
For (unit) testing, I have often had the need to override the current
timestamp in the database system. For example, a column default,
function, or views would make use of the current timestamp in some way,
and to test the behavior, it's sometimes
On Thu, Feb 23, 2012 at 3:34 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, Feb 22, 2012 at 10:02 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 22, 2012 at 2:23 PM, Simon Riggs si...@2ndquadrant.com wrote:
The industry accepted description for non-sequential access is random
Excerpts from Simon Riggs's message of jue feb 23 11:15:45 -0300 2012:
On Sun, Dec 4, 2011 at 12:20 PM, Noah Misch n...@leadboat.com wrote:
Making pg_multixact persistent across clean shutdowns is no bridge to cross
lightly, since it means committing to an on-disk format for an indefinite
On Thu, Feb 23, 2012 at 3:04 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Simon Riggs's message of jue feb 23 11:15:45 -0300 2012:
On Sun, Dec 4, 2011 at 12:20 PM, Noah Misch n...@leadboat.com wrote:
Making pg_multixact persistent across clean shutdowns is no bridge to
On Wed, Feb 22, 2012 at 6:17 PM, Timothy Garnett tgarn...@panjiva.com wrote:
I wanted to gauge the interest in adding an option for this to pg_dump.
I was thinking about an application for much the same feature.
Consider the case where you have a relatively small database such as
the accounting
Peter Eisentraut pete...@gmx.net writes:
Fixing most of this is not difficult, see attached patch. The only
ugliness is in pg_backup_archiver.h
FILE *FH; /* General purpose file handle */
which is used throughout pg_dump as sometimes a real FILE* and sometimes
a gzFile
Alvaro Herrera alvhe...@commandprompt.com writes:
Sure. The problem is that we are allowing updated rows to be locked (and
locked rows to be updated). This means that we need to store extended
Xmax information in tuples that goes beyond mere locks, which is what we
were doing previously --
Excerpts from Simon Riggs's message of jue feb 23 06:18:57 -0300 2012:
On Wed, Feb 22, 2012 at 5:00 PM, Noah Misch n...@leadboat.com wrote:
All in all, I think this is in pretty much final shape. Only pg_upgrade
bits are still missing. If sharp eyes could give this a critical look
Excerpts from Simon Riggs's message of jue feb 23 12:12:13 -0300 2012:
On Thu, Feb 23, 2012 at 3:04 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Sure. The problem is that we are allowing updated rows to be locked (and
locked rows to be updated). This means that we need to store
Excerpts from Tom Lane's message of jue feb 23 12:28:20 -0300 2012:
Alvaro Herrera alvhe...@commandprompt.com writes:
Sure. The problem is that we are allowing updated rows to be locked (and
locked rows to be updated). This means that we need to store extended
Xmax information in
Alvaro Herrera alvhe...@commandprompt.com wrote:
As for sanity -- I regard multixacts as a way to store extended
Xmax information. The original idea was obviously much more
limited in that the extended info was just locking info. We've
extended it but I don't think it's such a stretch.
Excerpts from Kevin Grittner's message of jue feb 23 13:31:36 -0300 2012:
Alvaro Herrera alvhe...@commandprompt.com wrote:
As for sanity -- I regard multixacts as a way to store extended
Xmax information. The original idea was obviously much more
limited in that the extended info was
On 02/23/2012 10:43 AM, Alvaro Herrera wrote:
I completely understand that you don't want to review this latest
version of the patch; it's a lot of effort and I wouldn't inflict it on
anybody who hasn't not volunteered. However, it doesn't seem to me that
this is reason to boot the patch from
Excerpts from Greg Smith's message of jue feb 23 14:48:13 -0300 2012:
On 02/23/2012 10:43 AM, Alvaro Herrera wrote:
I completely understand that you don't want to review this latest
version of the patch; it's a lot of effort and I wouldn't inflict it on
anybody who hasn't not volunteered.
On 02/23/2012 01:04 PM, Alvaro Herrera wrote:
manual vacuum is teh sux0r
I think you've just named my next conference talk submission.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Thu, Feb 23, 2012 at 4:01 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
As far as complexity, yeah, it's a lot more complex now -- no question
about that.
As far as complexity goes, would it be easier if we treated the UPDATE
of a primary key column as a DELETE plus an INSERT?
Alvaro Herrera alvhe...@commandprompt.com wrote:
Excerpts from Kevin Grittner's message:
Since the limitation on what can be stored in xmax was the killer
for Florian's attempt to support SELECT FOR UPDATE in a form
which was arguably more useful (and certainly more convenient for
those
On Feb 23, 2012, at 3:08 AM, Peter Eisentraut wrote:
For (unit) testing, I have often had the need to override the current
timestamp in the database system. For example, a column default,
function, or views would make use of the current timestamp in some way,
and to test the behavior, it's
On Feb 23, 2012, at 10:54 AM, David E. Wheeler wrote:
I create a mock schema, add the function to it, and then put it in the
search_path ahead of pg_catalog. See the example starting at slide 48 on
http://www.slideshare.net/justatheory/pgtap-best-practices.
Sorry, starting at slide 480.
On Mon, Feb 20, 2012 at 12:09 AM, Jan Urbański wulc...@wulczer.org wrote:
BTW, that tool is quite handy, I'll have to try running it over psycopg2.
Indeed. I'm having a play with it. It is reporting several issues to
clean up (mostly on failure at module import). It's also tracebacking
here and
On 02/23/2012 07:36 AM, Simon Riggs wrote:
Since scan_whole_pool_milliseconds is set to 2 minutes we scan the
whole bufferpool every 2 minutes, no matter how big the bufferpool,
even when nothing else is happening. Not cool.
It's not quite that bad. Once the BGW has circled around the whole
On 02/22/2012 05:31 PM, james wrote:
Has anyone considered managing a system like the DragonFLY swapcache for
a DBMS like PostgreSQL?
ie where the admin can assign drives with good random read behaviour
(but perhaps also-ran random write) such as SSDs to provide a cache for
blocks that were
On Thu, Feb 23, 2012 at 02:08:28PM +0100, Jeroen Vermeulen wrote:
On 2012-02-23 10:18, Simon Riggs wrote:
However, review of such a large patch should not be simply pass or
fail. We should be looking back at the original problem and ask
ourselves whether some subset of the patch could solve a
Excerpts from Noah Misch's message of mié feb 22 14:00:07 -0300 2012:
On Mon, Feb 13, 2012 at 07:16:58PM -0300, Alvaro Herrera wrote:
On Mon, Jan 30, 2012 at 06:48:47PM -0500, Noah Misch wrote:
On Tue, Jan 24, 2012 at 03:47:16PM -0300, Alvaro Herrera wrote:
* Columns that are part of
On Thu, Feb 23, 2012 at 8:44 PM, Greg Smith g...@2ndquadrant.com wrote:
On 02/23/2012 07:36 AM, Simon Riggs wrote:
Since scan_whole_pool_milliseconds is set to 2 minutes we scan the
whole bufferpool every 2 minutes, no matter how big the bufferpool,
even when nothing else is happening. Not
All,
If you are one of the developers who has used the Coverity Scan tool
(static analysis) on PostgreSQL in the past, or if you would like to use
it in the future, they've updated Scan and are looking to get people set
up with access.
Please contact me offlist.
--
Josh Berkus
PostgreSQL
On fre, 2012-02-17 at 10:19 -0500, Tom Lane wrote:
What if you did this ONCE and wrote the results to a file someplace?
That's still a cache, you've just defaulted on your obligation to think
about what conditions require the cache to be flushed. (In the case at
hand, the trigger for a
While testing Noah's filename quoting patch on my local development
machine, I noticed some strange behaviour around tab completion with
\i; it doesn't appear to be present in 9.1, but it is present on 9.2
HEAD and appears to be present with and without readline.
It manifests as the client
On Thu, Feb 23, 2012 at 06:36:42PM -0300, Alvaro Herrera wrote:
Excerpts from Noah Misch's message of mi?? feb 22 14:00:07 -0300 2012:
On Mon, Feb 13, 2012 at 07:16:58PM -0300, Alvaro Herrera wrote:
On Mon, Jan 30, 2012 at 06:48:47PM -0500, Noah Misch wrote:
On Tue, Jan 24, 2012 at
On Thu, Feb 23, 2012 at 3:44 PM, Greg Smith g...@2ndquadrant.com wrote:
It's not quite that bad. Once the BGW has circled around the whole buffer
pool, such that it's swept so far ahead it's reached the clock sweep
strategy point, it stops. So when the system is idle, it creeps forward
until
Peter Eisentraut pete...@gmx.net writes:
On fre, 2012-02-17 at 10:19 -0500, Tom Lane wrote:
That's still a cache, you've just defaulted on your obligation to think
about what conditions require the cache to be flushed. (In the case at
hand, the trigger for a cache rebuild would probably need
Peter van Hardenberg p...@pvh.ca writes:
While testing Noah's filename quoting patch on my local development
machine, I noticed some strange behaviour around tab completion with
\i; it doesn't appear to be present in 9.1, but it is present on 9.2
HEAD and appears to be present with and without
Hello hackers,
I've been a reader of this list for some time, but have never posted.
I have interest in the URI connection string support patch[1], so I'm in
the process of reviewing it. I have a couple of comments and questions:
1. I see no tests in the patch. I'd like to start getting
Looks like row_to_json() thinks 0s are nulls:
postgres=# select row(0);
row
-
(0)
(1 row)
postgres=# SELECT row_to_json(row(0));
row_to_json
-
{f1:null}
(1 row)
Best,
David
--
Sent via pgsql-hackers mailing list
On 02/23/2012 08:35 PM, David E. Wheeler wrote:
Looks like row_to_json() thinks 0s are nulls:
postgres=# select row(0);
row
-
(0)
(1 row)
postgres=# SELECT row_to_json(row(0));
row_to_json
-
{f1:null}
(1 row)
Yeah,
On Tue, Feb 21, 2012 at 1:34 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Sandro Santilli s...@keybit.net writes:
Please see the inline extension thread where answers to your problem
have been discussed.
I'm pretty sure Sandro is hacking PostGIS, so inline extensions are of
no help here.
On Thu, Feb 16, 2012 at 1:29 PM, Robert Haas robertmh...@gmail.com wrote:
Can you provide an updated patch?
Robert, updated patch is attached.
parallel_pg_dump_2.diff.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On 02/23/2012 09:09 PM, Andrew Dunstan wrote:
On 02/23/2012 08:35 PM, David E. Wheeler wrote:
Looks like row_to_json() thinks 0s are nulls:
postgres=# select row(0);
row
-
(0)
(1 row)
postgres=# SELECT row_to_json(row(0));
row_to_json
On Thu, Feb 23, 2012 at 12:43:11PM -0300, Alvaro Herrera wrote:
Excerpts from Simon Riggs's message of jue feb 23 06:18:57 -0300 2012:
On Wed, Feb 22, 2012 at 5:00 PM, Noah Misch n...@leadboat.com wrote:
All in all, I think this is in pretty much final shape. ??Only pg_upgrade
bits are
On Feb 23, 2012, at 8:49 PM, Andrew Dunstan wrote:
Fixed, Thanks for the report. (Also fixed in my 9.1 backport).
Awesome, thanks, will try it tomorrow.
David
smime.p7s
Description: S/MIME cryptographic signature
As it turns out, evidence would suggests that the ISO output in
Postgres isn't, unless there's an ISO standard for date and time that
is referring to other than 8601. It does not permit use of a space
between the date and the time, as seen in:
SELECT now();
now
63 matches
Mail list logo
