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
---
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
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 wrote:
> >
> > >> All in all, I think this is in pretty much final shape. ??Only pg_upgrade
> > >> bits are stil
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 16, 2012 at 1:29 PM, Robert Haas 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 to your subscription
On Tue, Feb 21, 2012 at 1:34 PM, Dimitri Fontaine
wrote:
> Sandro Santilli 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.
Can you tell us why alternative
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, ou
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 (pgsql-hackers@p
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 together
Peter van Hardenberg 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 readlin
Peter Eisentraut 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 to be a g
On Thu, Feb 23, 2012 at 3:44 PM, Greg Smith 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 it's scanned the
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 2
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 preferr
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
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 Expert
On Thu, Feb 23, 2012 at 8:44 PM, Greg Smith 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 cool.
>
>
> It
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 par
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
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 dirt
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
b
On Mon, Feb 20, 2012 at 12:09 AM, Jan Urbański 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 there: I'll send t
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 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'
Alvaro Herrera 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 converting from other
On Thu, Feb 23, 2012 at 4:01 PM, Alvaro Herrera
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?
There's not really a logical r
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
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 volunte
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 th
Excerpts from Kevin Grittner's message of jue feb 23 13:31:36 -0300 2012:
>
> Alvaro Herrera 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
Alvaro Herrera 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.
Since the limitation on
Excerpts from Tom Lane's message of jue feb 23 12:28:20 -0300 2012:
>
> Alvaro Herrera 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
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
> 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 extended
> > Xmax info
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 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 knuc
Alvaro Herrera 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 -- they may now have locks
Peter Eisentraut 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 handle. Ther
On Wed, Feb 22, 2012 at 6:17 PM, Timothy Garnett 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 records for a not-h
On Thu, Feb 23, 2012 at 3:04 PM, Alvaro Herrera
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 wrote:
>>
>> > Making pg_multixact persistent across clean shutdowns is no bridge to cross
>> > lightly, since it means
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 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.
On Thu, Feb 23, 2012 at 3:34 AM, Simon Riggs wrote:
> On Wed, Feb 22, 2012 at 10:02 PM, Robert Haas wrote:
>> 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
Peter Eisentraut 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 useful to tweak
On Thu, Feb 23, 2012 at 1:08 PM, Jeroen Vermeulen 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 chance
> you
On Sun, Dec 4, 2011 at 12:20 PM, Noah Misch 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 haven't
> identifie
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 th
On 23 February 2012 11:09, Peter Geoghegan wrote:
> On 23 February 2012 09:58, Daniel Farina 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 difficult to demonstrate at
> all
On Thu, Feb 23, 2012 at 11:17 AM, Greg Smith 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
> the graphs. I
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 PGrowVa
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 Mon, Feb 13, 2012 at 3:18 AM, Dimitri Fontaine
wrote:
> Hi,
>
> Sorry for the delays, I'm back on PostgreSQL related work again.
>
> Hitoshi Harada writes:
I just tried DROP EXTENSION now, and found it broken :(
>
> Please find v2 of the patch. I did change the dependency management in
>
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 summ
2012/2/20 Yeb Havinga :
> 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 stuck gettin
On 23 February 2012 09:58, Daniel Farina 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 first:
>
> * The sm
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 might
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 mind
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
http://archives.postgresql.org/message-id/CAEYLb_W
On Wed, Feb 22, 2012 at 5:00 PM, Noah Misch 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 of pg_u
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, n
On Thu, Feb 23, 2012 at 08:26:47AM +, Thom Brown wrote:
> On 23 February 2012 07:15, Gianni Ciolli 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 table (such as "replace th
(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 Wed, Feb 22, 2012 at 10:02 PM, Robert Haas wrote:
> 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 mere
On 23 February 2012 07:15, Gianni Ciolli 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 up the
>> >>trigger
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'
> utils/misc/guc.o:(.
* 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 f
63 matches
Mail list logo
