(2012/02/22 9:30), Tom Lane wrote:
> 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
Greg Smith writes:
> 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 s
On Tue, Feb 21, 2012 at 10:34:42PM +0100, Dimitri Fontaine wrote:
> 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 extensi
Attached is a feature extracted from the Ants Aasma "add timing of
buffer I/O requests" submission. That included a tool to measure timing
overhead, from gettimeofday or whatever else INSTR_TIME_SET_CURRENT
happens to call. That's what I've broken out here; it's a broader topic
than just buff
On Wed, Feb 22, 2012 at 7:06 AM, Noah Misch wrote:
> 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
On 21/02/12 18:28, Jan Urbański wrote:
> On 21/02/12 18:05, Peter Eisentraut wrote:
>>> it might be better to use ereport, to expose the message
>>> for translation.
>>>
> After giving it some thought some of these elogs could be changed into
> PLy_elogs (which is meant to propagate a Python error
Hello,
I am new here,
it is a question about "how to colaborate" and/or "where to find", in the
scope of temporal database...
-
I see the Temporal Postgres,
"a project for making tools and documentation that people can use to better
manage, query, and maintain time data in Postgres",
http://
On Tue, Feb 21, 2012 at 11:54 AM, Jeff Janes wrote:
> I don't think that "pure" is sufficient to be leakproof. For example,
> if I have a function which is pure but which takes an unusually long
> time to evaluate for some unique pathological combination of
> arguments, I don't think that it woul
On Tue, Feb 21, 2012 at 9:00 AM, Pavel Stehule wrote:
> 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?
I'm pretty sure that VACUUM ANALYZE *will* be faster than ANALYZE in
general, because VACU
2012/2/22 Robert Haas :
> On Tue, Feb 21, 2012 at 9:00 AM, Pavel Stehule
> wrote:
>
>> 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?
>
> I'm pretty sure that VACUUM ANALYZE *will* be faste
On 22-02-2012 09:50, Peter Padua Krauss wrote:
> 1) There are another project, similar or better than my!? There are "pure SQL
> standard libraries" for this?
>
Range Types [1]. It is 9.2 material but it is already in the repository.
[1] http://www.postgresql.org/docs/devel/static/rangetypes.ht
On Tue, Feb 21, 2012 at 5:07 AM, Noah Misch wrote:
> We do, in numerous places, drop a shared buffer content lock and reacquire it
> in exclusive mode. However, the existing users of that pattern tend to trade
> the lock, complete subsequent work, and unlock the buffer all within the same
> funct
On Wed, Feb 22, 2012 at 8:13 AM, Nicolas Barbier
wrote:
> 2012/2/22 Robert Haas :
>
>> On Tue, Feb 21, 2012 at 9:00 AM, Pavel Stehule
>> wrote:
>>
>>> 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
On Tue, Feb 21, 2012 at 2:00 PM, Pavel Stehule wrote:
> I had to reply to query about usage VACUUM ANALYZE or ANALYZE. I
> expected so ANALYZE should be faster then VACUUM ANALYZE.
VACUUM ANALYZE scans the whole table sequentially.
ANALYZE accesses a random sample of data blocks. Random access
Typo in a comment...
--strk;
>From cfca9507df8612a48cad341653f8e9193c6b7e08 Mon Sep 17 00:00:00 2001
From: Sandro Santilli
Date: Wed, 22 Feb 2012 11:32:48 +0100
Subject: [PATCH] typo fix
---
src/backend/commands/extension.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --gi
Attached patch fixes GiST behaviour without altering operators behaviour.
--
With best regards,
Alexander Korotkov.
*** a/src/backend/access/gist/gistproc.c
--- b/src/backend/access/gist/gistproc.c
***
*** 836,842 gist_box_picksplit(PG_FUNCTION_ARGS)
}
/*
! * Equality
Robert Haas writes:
> Anyway, to your point, I suppose I might hesitate to mark factorial
> leak-proof even if it didn't throw an error on overflow, because the
> time it takes to return an answer for larger inputs does grow rather
> rapidly. But it's kind of a moot point because the error makes
Simon Riggs writes:
> On Tue, Feb 21, 2012 at 2:00 PM, Pavel Stehule
> wrote:
>> I had to reply to query about usage VACUUM ANALYZE or ANALYZE. I
>> expected so ANALYZE should be faster then VACUUM ANALYZE.
> VACUUM ANALYZE scans the whole table sequentially.
> ANALYZE accesses a random sample
On Wed, Feb 22, 2012 at 10:29:56AM -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Tue, Feb 21, 2012 at 2:00 PM, Pavel Stehule
> > wrote:
> >> I had to reply to query about usage VACUUM ANALYZE or ANALYZE. I
> >> expected so ANALYZE should be faster then VACUUM ANALYZE.
>
> > VACUUM ANALYZE
On 02/22/2012 10:21 AM, Tom Lane wrote:
Robert Haas writes:
Anyway, to your point, I suppose I might hesitate to mark factorial
leak-proof even if it didn't throw an error on overflow, because the
time it takes to return an answer for larger inputs does grow rather
rapidly. But it's kind of
On Tue, Feb 7, 2012 at 12:30, Fujii Masao wrote:
> Hi,
>
> http://www.depesz.com/2012/02/03/waiting-for-9-2-pg_basebackup-from-slave/
>> =$ time pg_basebackup -D /home/pgdba/slave2/ -F p -x stream -c fast -P -v -h
>> 127.0.0.1 -p 5921 -U replication
>> xlog start point: 2/AC4E2600
>> pg_basebacku
Greg Smith wrote:
Anyway, the patch does now includes several examples and a short primer on
PC clock hardware, to help guide what good results look like and why they've
been impossible to obtain in the past. That's a bit Linux-centric, but the
hardware described covers almost all systems using
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)
> w
Attached is as far as I've gotten with fixing depesz's complaint about
backrefs embedded within larger quantified expressions (the complaint
being that only the last match of the backref is checked properly).
This is per the analysis I posted at
https://sourceforge.net/tracker/index.php?func=detail
On 02/22/2012 11:14 AM, Kevin Grittner wrote:
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 mem
On Wed, Feb 22, 2012 at 4:43 PM, Greg Smith wrote:
> Attached are updated versions of this feature without the pg_test_timing
> tool part, since I broke that out into another discussion thread. I've
> split the part that updates pg_stat_statistics out from the main feature
> too, separate patch a
On 02/22/2012 11:10 AM, Jay Levitt wrote:
N.B.: Windows has at least two clock APIs, timeGetTime and
QueryPerformanceCounters (and probably more, these days). They rely on
different hardware clocks, and can get out of sync with each other;
meanwhile, QueryPerformanceCounters can get out of sync w
On Mon, Feb 13, 2012 at 07:16:58PM -0300, Alvaro Herrera wrote:
> Okay, so this patch fixes the truncation and wraparound issues through a
> mechanism much like pg_clog's: it keeps track of the oldest possibly
> existing multis on each and every table, and then during tuple freezing
> those are rem
On Wed, Feb 22, 2012 at 18:44, Greg Smith wrote:
> As far as I've been able to tell, there aren't any issues unique to Windows
> there. Multiple cores can have their TSC results get out of sync on Windows
> for the same reason they do on Linux systems, and there's also the same
> frequency/temper
This submission has turned into a bit of a mess. I did the closest
thing to a review the day after it was submitted; follow-up review
attempts had issues applying the patch. And it's been stuck there. The
patch is still fine, I just tested it out to pick this back up myself
again. I think t
On 02/22/2012 12:25 PM, Marti Raudsepp wrote:
On Wed, Feb 22, 2012 at 18:44, Greg Smith wrote:
As far as I've been able to tell, there aren't any issues unique to Windows
there. Multiple cores can have their TSC results get out of sync on Windows
for the same reason they do on Linux systems, a
On 2012-02-22 16:29, Tom Lane wrote:
(Snip context)
VACUUM ANALYZE
consists of two separate passes, VACUUM and then ANALYZE, and the second
pass is going to be "random" I/O by your definition no matter what.
I don't suppose there's a cas
Say I'm writing an extension X, and I want to process data values from
another extension that creates type Y (e.g. an hstore), what's the best
way to determine the Oid of type Y in my module X code? SPI code that
runs "select 'something'::Y" and then examines the oid in SPI_tuptable?
Or do we h
On 22 February 2012 18:00, Andrew Dunstan wrote:
> Say I'm writing an extension X, and I want to process data values from
> another extension that creates type Y (e.g. an hstore), what's the best way
> to determine the Oid of type Y in my module X code? SPI code that runs
> "select 'something'::Y"
Thom Brown wrote:
> Does this help?
>
> test=# SELECT pg_typeof('4834.34'::numeric)::oid;
> pg_typeof
> ---
> 1700
> (1 row)
Wouldn't it be easier to do this instead?
test=# SELECT 'numeric'::regtype::oid;
oid
--
1700
(1 row)
-Kevin
--
Sent via pgsql-hackers mailing
On 22 February 2012 18:34, Kevin Grittner wrote:
> Thom Brown wrote:
>> Does this help?
>>
>> test=# SELECT pg_typeof('4834.34'::numeric)::oid;
>> pg_typeof
>> ---
>> 1700
>> (1 row)
>
> Wouldn't it be easier to do this instead?
>
> test=# SELECT 'numeric'::regtype::oid;
> oid
> -
2012/2/22 Robert Haas :
> On Wed, Feb 22, 2012 at 8:13 AM, Nicolas Barbier
> wrote:
>> 2012/2/22 Robert Haas :
>>
>>> On Tue, Feb 21, 2012 at 9:00 AM, Pavel Stehule
>>> wrote:
>>>
I had to reply to query about usage VACUUM ANALYZE or ANALYZE. I
expected so ANALYZE should be faster then
On Wed, Feb 22, 2012 at 19:36, Greg Smith wrote:
> From the patch:
>
> Newer operating systems may check for the known TSC problems and
> switch to a slower, more stable clock source when they are seen.
> If your system supports TSC time but doesn't default to that, it
> may be disabled for a good
Pavel Stehule wrote:
> usual pattern in our application is
>
> create table xx1 as select
> analyze xx1
> create table xx2 as select from xx1,
> analyze xx2
> create table xx3 as select ... from xx3,
> analyze xx3
> create table xx4 as select ... from xx1, ...
>
> tables xx
On 16 January 2012 06:28, Greg Smith wrote:
> One of the most useful bits of feedback on how well checkpoint I/O is going
> is the amount of time taken to sync files to disk. Right now the only way
> to get that is to parse the logs. The attached patch publishes the most
> useful three bits of d
2012/2/22 Kevin Grittner :
> Pavel Stehule wrote:
>
>> usual pattern in our application is
>>
>> create table xx1 as select
>> analyze xx1
>> create table xx2 as select from xx1,
>> analyze xx2
>> create table xx3 as select ... from xx3,
>> analyze xx3
>> create table xx4 as se
On 02/22/2012 01:36 PM, Thom Brown wrote:
On 22 February 2012 18:34, Kevin Grittner wrote:
Thom Brown wrote:
Does this help?
test=# SELECT pg_typeof('4834.34'::numeric)::oid;
pg_typeof
---
1700
(1 row)
Wouldn't it be easier to do this instead?
test=# SELECT 'numeric'::re
On Wed, Feb 22, 2012 at 3:29 PM, Tom Lane wrote:
> Simon Riggs writes:
>> On Tue, Feb 21, 2012 at 2:00 PM, Pavel Stehule
>> wrote:
>>> I had to reply to query about usage VACUUM ANALYZE or ANALYZE. I
>>> expected so ANALYZE should be faster then VACUUM ANALYZE.
>
>> VACUUM ANALYZE scans the who
On Sun, Feb 19, 2012 at 01:13:10PM +0200, Peter Eisentraut wrote:
> The documentation of the pg_upgrade -l/--logfile option never made much
> sense to me:
>
> -l, --logfile=FILENAMElog session activity to file
>
> I don't know what "session" means for pg_upgrade, so I never used it.
>
On Sun, Feb 19, 2012 at 01:24:34PM -0500, Robert Haas wrote:
> As a more general comment, I think that the way pg_upgrade does
> logging right now is absolutely terrible. IME, it is utterly
> impossible to understand what has gone wrong with pg_upgrade without
> looking at the log file. And by de
Andrew Dunstan writes:
> Maybe I need to be more clear. The C code I'm writing will process
> composites. I want to cache the Oids of certain non-builtin types in the
> function info's fn_extra, and then be able to test whether or not the
> fields in the composites are of those types.
What's y
Excerpts from Bruce Momjian's message of mié feb 22 17:01:10 -0300 2012:
> On Sun, Feb 19, 2012 at 01:24:34PM -0500, Robert Haas wrote:
> > One pretty obvious improvement would be: if pg_upgrade fails after
> > renaming the control file for the old cluster out of the way - say,
> > while loading
Excerpts from Etsuro Fujita's message of mié feb 22 05:37:36 -0300 2012:
> I did some tests. The results look good to me. Please find attached a
> logfile.
Thanks.
> My only concern on the patch is
>
> +static void
> +AlterForeignServerOwner_internal(Relation rel, HeapTuple tup, Oid
> newOwn
On 02/22/2012 03:20 PM, Tom Lane wrote:
Andrew Dunstan writes:
Maybe I need to be more clear. The C code I'm writing will process
composites. I want to cache the Oids of certain non-builtin types in the
function info's fn_extra, and then be able to test whether or not the
fields in the compos
On Wed, Feb 22, 2012 at 05:22:29PM -0300, Alvaro Herrera wrote:
>
> Excerpts from Bruce Momjian's message of mié feb 22 17:01:10 -0300 2012:
> > On Sun, Feb 19, 2012 at 01:24:34PM -0500, Robert Haas wrote:
>
> > > One pretty obvious improvement would be: if pg_upgrade fails after
> > > renaming t
On ons, 2012-02-22 at 14:38 -0500, Bruce Momjian wrote:
> How about?
>
> -l, --logfile=FILENAMElog internal activity to file
That sounds better.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/m
On sön, 2012-02-19 at 13:24 -0500, Robert Haas wrote:
> But I also think the
> logging needs improvement. Right now, we studiously redirect both
> stdout and stderr to /dev/null; maybe it would be better to redirect
> stdout to /dev/null and NOT redirect stderr. If that generates too
> much chatt
Excerpts from Tom Lane's message of mar feb 21 21:30:39 -0300 2012:
>
> 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-
Hello
I am sending a proposal for PSM language support. It is early maybe. I
would to have a patch for first 9.3 commitfest.
Proposal PL/pgPSM
I propose to integrate a PSM language into the core. This language is
defined as part of ANSI SQL - SQL/PSM and is used in some well known
databases like
On Wed, 2012-02-22 at 12:44 -0400, 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,
On 02/22/2012 04:29 PM, Marc Munro wrote:
On Wed, 2012-02-22 at 12:44 -0400, 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
Andrew Dunstan writes:
> I fully agree it's not bulletproof, but I'm not sure what alternative there
> is.
If you know the type has been installed as an extension you can look at
the extension's content in pg_depend, much like \dx+ does, limiting to
only types whose name matches.
Regards,
--
Di
On Wed, Feb 22, 2012 at 10:21 AM, Tom Lane wrote:
> Robert Haas writes:
>> Anyway, to your point, I suppose I might hesitate to mark factorial
>> leak-proof even if it didn't throw an error on overflow, because the
>> time it takes to return an answer for larger inputs does grow rather
>> rapidly
On Wed, Feb 22, 2012 at 2:23 PM, Simon Riggs wrote:
> The industry accepted description for non-sequential access is "random
> access" whether or not the function that describes the movement is
> entirely random. To argue otherwise is merely hairsplitting.
I don't think so. For example, a bitmap
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 dirtied, with async write that hopefull
On Wed, Feb 22, 2012 at 3:51 PM, Peter Eisentraut wrote:
> On sön, 2012-02-19 at 13:24 -0500, Robert Haas wrote:
>> But I also think the
>> logging needs improvement. Right now, we studiously redirect both
>> stdout and stderr to /dev/null; maybe it would be better to redirect
>> stdout to /dev/n
On Wed, Feb 22, 2012 at 11:19 AM, Tom Lane wrote:
> Attached is as far as I've gotten with fixing depesz's complaint about
> backrefs embedded within larger quantified expressions (the complaint
> being that only the last match of the backref is checked properly).
> This is per the analysis I post
I decided that it would be worth benchmarking this patch.
Specifically, I tested:
master, as a basis of comparison
checksum16_with_wallogged_hint_bits.v10.patch, page_checksums = 'on'
checksum16_with_wallogged_hint_bits.v10.patch, page_checksums = 'off'
This test was performed using pgbench-too
Andrew Dunstan writes:
> On 02/22/2012 04:29 PM, Marc Munro wrote:
>> As the developer of veil I feel marginally qualified to bikeshed here:
>> how about "silent"? A silent function being one that will not blab.
> I also made this suggestion later in the day.
SILENT isn't a bad idea. It seems
On Tue, 2012-02-14 at 19:32 -0500, Dan Ports wrote:
> On Tue, Feb 14, 2012 at 09:27:58AM -0600, Kevin Grittner wrote:
> > Heikki Linnakangas wrote:
> > > On 14.02.2012 04:57, Dan Ports wrote:
> > >> The easiest answer would be to just treat every prepared
> > >> transaction found during recovery a
On Wed, Feb 22, 2012 at 05:49:26PM -0500, Robert Haas wrote:
> On Wed, Feb 22, 2012 at 3:51 PM, Peter Eisentraut wrote:
> > On sön, 2012-02-19 at 13:24 -0500, Robert Haas wrote:
> >> But I also think the
> >> logging needs improvement. Right now, we studiously redirect both
> >> stdout and stderr
On Wed, Feb 22, 2012 at 10:50:07PM +0200, Peter Eisentraut wrote:
> On ons, 2012-02-22 at 14:38 -0500, Bruce Momjian wrote:
> > How about?
> >
> > -l, --logfile=FILENAMElog internal activity to file
>
> That sounds better.
Done.
--
Bruce Momjian http://momjian.us
Enter
On Wed, Feb 22, 2012 at 11:17:53PM +, Peter Geoghegan wrote:
> I decided that it would be worth benchmarking this patch.
> Specifically, I tested:
>
> master, as a basis of comparison
>
> checksum16_with_wallogged_hint_bits.v10.patch, page_checksums = 'on'
>
> checksum16_with_wallogged_hint_
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'
utils/misc/guc.o:(.data+0x4ddc): undefined reference to `ssl_key_file'
utils/misc/guc.o:
On Wed, Feb 22, 2012 at 6:30 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 02/22/2012 04:29 PM, Marc Munro wrote:
>>> As the developer of veil I feel marginally qualified to bikeshed here:
>>> how about "silent"? A silent function being one that will not blab.
>
>> I also made this suggesti
On Wed, Feb 22, 2012 at 8:47 AM, Sandro Santilli wrote:
> Typo in a comment...
Committed, thanks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
On Tue, Feb 21, 2012 at 11:55 PM, Greg Smith wrote:
> 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.
On Wed, Feb 22, 2012 at 6:17 PM, Peter Geoghegan wrote:
> I decided that it would be worth benchmarking this patch.
> Specifically, I tested:
>
> master, as a basis of comparison
>
> checksum16_with_wallogged_hint_bits.v10.patch, page_checksums = 'on'
>
> checksum16_with_wallogged_hint_bits.v10.pa
On Thu, Feb 16, 2012 at 6:09 AM, Robert Haas wrote:
> On Fri, Feb 3, 2012 at 7:33 PM, Daniel Farina wrote:
>> Ah, yes, I think my optimizations were off when building, or
>> something. I didn't get such verbosity at first, and then I remember
>> doing something slightly different and then gettin
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 up the
> >>trigger rather than setting up a separate trigger function whic
75 matches
Mail list logo
