Alex, please send across the install-postgresql.log. It must be present in
your system TEMP.
On Fri, Jan 11, 2013 at 12:02 PM, Sandeep Thakkar <
sandeep.thak...@enterprisedb.com> wrote:
> I remember last time we fixed a bug in initcluster.vbs. There was a typo
> which caused icacls to run on syst
I remember last time we fixed a bug in initcluster.vbs. There was a typo
which caused icacls to run on system drive. Let me nail down this issue
completely. I'm on it.
On Fri, Jan 11, 2013 at 9:28 AM, Craig Ringer wrote:
> On 01/09/2013 05:10 PM, emergency.sho...@gmail.com wrote:
> > One click i
pgbuildf...@jdrake.com writes:
> On Thu, 10 Jan 2013, Andrew Dunstan wrote:
>> Without access to the machine it's pretty hard to know, so I was just
>> speculating fairly wildly. If Jeremy can find out what the problem is that
>> would be good, or if he can give us access to the machine it shouldn'
Hi,dear tom lane && pgsql-hackers
In your last e-mail, you want me to think anbout the only spgist-indexed
column and give you some more further information.
This time I will give you the contents of the table route_raw, the download
link is https://www.box.com/s/yxa4yxo6rcb3dzeaefmz or
htt
On Thu, Jan 10, 2013 at 10:25:25PM -0500, Tom Lane wrote:
> "Aaron W. Swenson" writes:
> > On Thu, Jan 10, 2013 at 08:12:56PM -0500, Tom Lane wrote:
> >> Sorry about going off on a theological tangent. The important question
> >> at this point is, can anybody fix the test so it works on Gentoo?
>
On 01/09/2013 05:10 PM, emergency.sho...@gmail.com wrote:
> One click installer postgresql-9.2.2-1-windows-x64.exe from
> http://www.postgresql.org/download/windows/.
>
> Start the installer from "D:\downloads", choose "C:\Program
> Files\PostgreSQL\9.2" as binary directory, and
> "D:\db\postgresql
"Aaron W. Swenson" writes:
> On Thu, Jan 10, 2013 at 08:12:56PM -0500, Tom Lane wrote:
>> Sorry about going off on a theological tangent. The important question
>> at this point is, can anybody fix the test so it works on Gentoo?
>> If not we'll have to pull it out, whether or not it would be a g
On Thu, Jan 10, 2013 at 08:12:56PM -0500, Tom Lane wrote:
> Josh Berkus writes:
> > OK, now I'm sorry I brought this up.
>
> Sorry about going off on a theological tangent. The important question
> at this point is, can anybody fix the test so it works on Gentoo?
> If not we'll have to pull it o
While looking at the lock code the other day, I noticed this comment in
PostPrepare_Locks():
/*
* We cannot simply modify proclock->tag.myProc to reassign
* ownership of the lock, because that's part of the hash key and
* the proclock would then b
Josh Berkus writes:
> OK, now I'm sorry I brought this up.
Sorry about going off on a theological tangent. The important question
at this point is, can anybody fix the test so it works on Gentoo?
If not we'll have to pull it out, whether or not it would be a good
thing to have on Debian.
I wrote:
> I'm fairly happy with the general shape of this formula: it has a
> principled explanation and the resulting numbers appear to be sane.
> The specific cost multipliers obviously are open to improvement based
> on future evidence. (In particular, I intend to code it in a way that
> doesn
All,
OK, now I'm sorry I brought this up.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 10 January 2013 20:13, Tom Lane wrote:
> Bruce Momjian writes:
>> On Wed, Jan 9, 2013 at 05:06:49PM -0500, Tom Lane wrote:
>>> Let's wait till we see where the logical rep stuff ends up before we
>>> worry about saving 4 bytes per WAL record.
>
>> Well, we have wal_level to control the amount
Peter Eisentraut writes:
> On 1/10/13 4:48 PM, Tom Lane wrote:
>> Well, I'm not the package maintainer for perl, so this is not an
>> authoritative answer ... but I don't believe that there's any
>> expectation that you could replace the installation with a different
>> major perl version and stil
On Jan 10, 2013, at 2:16 PM, Tom Lane wrote:
>> Is there some way to only get the relevant index expression from indexprs,
>> rather than the whole expression?
>
> pg_get_indexdef() is your friend. You really, really don't want to
> write any client-side code that inspects indexprs directly.
"David E. Wheeler" writes:
> Is there some way to only get the relevant index expression from indexprs,
> rather than the whole expression?
pg_get_indexdef() is your friend. You really, really don't want to
write any client-side code that inspects indexprs directly. It'll
break.
On 1/10/13 4:38 PM, Tom Lane wrote:
> The first of these inferences seems valid enough to me,
> as the presence of MakeMaker suggests that you have facilities for
> building Perl extensions.
MakeMaker is perfectly useful without any C headers or C compiler nearby.
--
Sent via pgsql-hackers mail
On 1/10/13 4:38 PM, Tom Lane wrote:
> It's complete folly to imagine that configure checks all and exactly the
> things that we require to build. In fact, I'd argue that a majority of
> what it does is inference or approximation of some sort.
I'm not saying they have to be exact. But you have to
On 1/10/13 4:48 PM, Tom Lane wrote:
> Well, I'm not the package maintainer for perl, so this is not an
> authoritative answer ... but I don't believe that there's any
> expectation that you could replace the installation with a different
> major perl version and still have C-level dependencies work
Hackers,
I'm trying to write a query to give me a list of the columns and/or expressions
in an index. For example, given this table:
david=# \d foo
Table "public.foo"
Column | Type| Modifiers
-+---+---
id | integer |
bar_ids | integer[] |
Indexe
Peter Eisentraut writes:
> On 1/9/13 7:56 PM, Tom Lane wrote:
>> That is, the standard perl executable depends on libperl.so --- not
>> libperl.so.M.N, which isn't even there. Take the .so away, and you
>> don't get past configure's initial perl-related checks, because
>> /usr/bin/perl is broken.
Peter Eisentraut writes:
> ... The core issue here is that header files and link-time
> library files are in different packages that can be installed
> separately. Any other library were this choice was made would create
> the same issue. The fault is that configure checks only one thing and
> a
On 2013-01-10 18:00:40 -0300, Alvaro Herrera wrote:
> Here's version 28 of this patch. The only substantive change here from
> v26 is that I've made GetTupleForTrigger() use either LockTupleExclusive
> or LockTupleNoKeyExclusive, depending on whether the key columns are
> being modified by the upd
On 1/9/13 7:56 PM, Tom Lane wrote:
> That is, the standard perl executable depends on libperl.so --- not
> libperl.so.M.N, which isn't even there. Take the .so away, and you
> don't get past configure's initial perl-related checks, because
> /usr/bin/perl is broken. This isn't a Red-Hat-ism, eith
On 1/9/13 4:06 PM, Andrew Dunstan wrote:
> Here's a patch which does that and produces configure traces like this
> on Mingw:
>
>checking for Perl archlibexp... C:/Perl/lib
>checking for Perl privlibexp... C:/Perl/lib
>checking for Perl useshrplib... true
>checking for flags to lin
On 1/9/13 12:50 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 1/9/13 11:00 AM, Tom Lane wrote:
>>> The libperl-dev package, as constituted, doesn't make any sense: it's
>>> got the symlink which people need, and a very large static (.a) library
>>> that most people don't need. Even worse,
Bruce Momjian writes:
> On Wed, Jan 9, 2013 at 05:06:49PM -0500, Tom Lane wrote:
>> Let's wait till we see where the logical rep stuff ends up before we
>> worry about saving 4 bytes per WAL record.
> Well, we have wal_level to control the amount of WAL traffic.
That's entirely irrelevant. The
On Mon, Jan 7, 2013 at 4:15 PM, Andrew Dunstan wrote:
> You (Merlin) have kindly volunteered to work on documentation, so before we
> go too far with that any bikeshedding on names, or on the functionality
> being provided, should now take place.
Barring comment/complaint, I'm just going to roll
On Wed, Jan 9, 2013 at 05:06:49PM -0500, Tom Lane wrote:
> Simon Riggs writes:
> > Overall, the WAL record is MAXALIGN'd, so with 8 byte alignment we
> > waste 4 bytes per record. Or put another way, if we could reduce
> > record header by 4 bytes, we would actually reduce it by 8 bytes per
> > r
> > The checksums patch also introduces another behavior into
> > SetBufferCommitInfoNeedsSave, which is to write an XLOG_HINT WAL record
> > if checksums are enabled (to avoid torn page hazards). That's only
> > necessary for changes where the caller does not write WAL itself and
> > doesn't bump
On Wed, Jan 9, 2013 at 12:38 AM, Benedikt Grundmann
wrote:
> For what it is worth even if it is a dedicated database box 75% might be way
> too high. I remember investigating bad performance on our biggest database
> server, that in the end turned out to be a too high setting of
> effective_cache
On 10 January 2013 17:54, Josh Berkus wrote:
> The 4th Cluster-Hackers Summit will be Tuesday, May 21st, on or near the
> campus of the University of Ottawa. Anyone working on clustering,
> replication, pooling or federated database tools and features is urged
> to attend.
> This includes propr
Hackers, Replication aficionados:
The 4th Cluster-Hackers Summit will be Tuesday, May 21st, on or near the
campus of the University of Ottawa. Anyone working on clustering,
replication, pooling or federated database tools and features is urged
to attend. This includes proprietary clustering syst
On 01/10/2013 12:35 PM, Tom Lane wrote:
Andrew Dunstan writes:
I think there's a very good case for breaking the nexus between
PRETTYFLAG_PAREN and PRETTYFLAG_INDENT+line wrapping for views. Only
PRETTYFLAG_PAREN affects the safety issue. The others are just about
white space in safe places.
Andrew Dunstan writes:
> I think there's a very good case for breaking the nexus between
> PRETTYFLAG_PAREN and PRETTYFLAG_INDENT+line wrapping for views. Only
> PRETTYFLAG_PAREN affects the safety issue. The others are just about
> white space in safe places.
What I was actually thinking abou
On 01/10/2013 12:09 PM, Tom Lane wrote:
Now, we could consider changing the "safe" mode so that it tries to
provide nice whitespace/line breaks while not risking removal of
parentheses. But that would be a totally different patch, and I'm
not sure how much it would address Marko's desires any
Josh Berkus wrote:
> The, shared_buffers, wal_buffers, and effective_cache_size (and possible
> other future settings) can be set to -1. If they are set to -1, then we
> use the figure:
>
> shared_buffers = available_ram * 0.25
> (with a ceiling of 8GB)
> wal_buffers = available_ram * 0.05
> (wit
David Fetter writes:
> On Thu, Jan 10, 2013 at 11:21:13AM -0500, Tom Lane wrote:
>> -1. The reason that pg_dump does not pretty-print things is that
>> it's unsafe; there is no real guarantee that the view will reload as
>> intended, because it's under-parenthesized. (Even if we were sure
>> it
On Thu, Jan 10, 2013 at 11:21:13AM -0500, Tom Lane wrote:
> Marko Tiikkaja writes:
> > While we can do the actual splitting of objects from a -Fc dump
> > relatively easily, we can't fix the view definitions after they've
> > been dumped. So I'm proposing a --pretty-print-views setting to
> > pg_
On 01/10/2013 11:32 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 01/09/2013 10:48 PM, Tom Lane wrote:
Well, okapi (Gentoo) doesn't like it:
...
The best guess I can come up with is that this box is only able to link
libperl.so into a shared library, ie the "-fpic -shared" part of the
recipe
Andrew Dunstan writes:
> On 01/09/2013 10:48 PM, Tom Lane wrote:
>> Well, okapi (Gentoo) doesn't like it:
>> ...
>> The best guess I can come up with is that this box is only able to link
>> libperl.so into a shared library, ie the "-fpic -shared" part of the
>> recipe is critical.
> This seems f
Marko Tiikkaja writes:
> While we can do the actual splitting of objects from a -Fc dump
> relatively easily, we can't fix the view definitions after they've been
> dumped. So I'm proposing a --pretty-print-views setting to pg_dump
> (patch attached).
-1. The reason that pg_dump does not pre
Dimitri Fontaine writes:
> Please find attached a preliminary patch following the TEMPLATE ideas,
FYI, I've added it to the commitfest:
https://commitfest.postgresql.org/action/patch_view?id=1032
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Supp
On 01/09/2013 10:48 PM, Tom Lane wrote:
I wrote:
Done, we'll soon see how much the buildfarm likes it.
Well, okapi (Gentoo) doesn't like it:
configure:29191: checking for libperl
configure:29217: icc -o conftest -O3 -xSSSE3 -parallel -ip -mp1 -fno-strict-aliasing
-g -I/usr/lib64/perl5/5.12.4
On 1/10/13 3:22 PM, Andrew Dunstan wrote:
For versions >= 9.2 it would be better to allow passing in a
pretty-print value, like 80 or 0, instead of just passing 'true'. The
new line-wrapping that the integer argument triggers is much more
readable than the supposedly pretty value that 'true' prov
On 01/10/2013 07:23 AM, Marko Tiikkaja wrote:
Hi,
At the company I work for, we've been splitting dumps into separate
files and diffing them for a while now. By far the biggest problem we
had was with views: pg_dump by default dumps views on one line, in a
format which maximizes compatibili
* David Fetter (da...@fetter.org) wrote:
> On Thu, Jan 10, 2013 at 01:23:10PM +0100, Marko Tiikkaja wrote:
> > Any feedback is welcome.
>
> Why not make this the new default? That way, new users will have the
> benefit, and people with tools or processes that depend on the old
> behavior can stil
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> The real question is how necessary is it for unprivileged code to set
> temp_tablespaces *for itself*. I doubt that that's all that critical.
> I suspect the variable is hardly used in the field at all, given that
> it's been there since 8.3 and nobody noti
On Thu, Jan 10, 2013 at 01:23:10PM +0100, Marko Tiikkaja wrote:
> Hi,
>
> At the company I work for, we've been splitting dumps into separate
> files and diffing them for a while now. By far the biggest problem
> we had was with views: pg_dump by default dumps views on one line,
> in a format whi
On Wednesday, January 09, 2013 7:15 PM Amit Kapila wrote:
On Wednesday, January 09, 2013 5:49 PM Andres Freund wrote:
> On 2013-01-09 15:06:04 +0530, Amit Kapila wrote:
> > On Wednesday, January 09, 2013 2:28 PM Andres Freund wrote:
> > > On 2013-01-09 14:04:32 +0530, Amit Kapila wrote:
> > > > >
Hi,
At the company I work for, we've been splitting dumps into separate
files and diffing them for a while now. By far the biggest problem we
had was with views: pg_dump by default dumps views on one line, in a
format which maximizes compatibility. Now this has several problems for
our use
On 2013-01-10 10:31:04 +0100, Andres Freund wrote:
> On 2013-01-10 00:05:07 +0100, Andres Freund wrote:
> > On 2013-01-09 17:28:35 -0500, Tom Lane wrote:
> > > (We know this doesn't
> > > matter, but gcc doesn't; this version of gcc apparently isn't doing much
> > > with the knowledge that elog won
On 10 January 2013 04:02, Tom Lane wrote:
> Simon Riggs writes:
>> Having it USERSET allows different settings for different roles, which
>> is useful.
>
> That would still be possible if it were SUSET; you'd just need a
> superuser to set it for you (via ALTER ROLE SET, or perhaps a
> security-d
On 2013-01-10 00:05:07 +0100, Andres Freund wrote:
> On 2013-01-09 17:28:35 -0500, Tom Lane wrote:
> > (We know this doesn't
> > matter, but gcc doesn't; this version of gcc apparently isn't doing much
> > with the knowledge that elog won't return.)
>
> Afaics one reason for that is that we don't h
On Wednesday, January 09, 2013 5:45 PM Simon Riggs wrote:
> On 9 January 2013 12:06, Amit Kapila wrote:
> > On Wednesday, January 09, 2013 4:52 PM Simon Riggs wrote:
> >> On 24 December 2012 16:57, Amit Kapila
> wrote:
> >>
> >> > Performance: Average of 3 runs of pgbench in tps
> >> > 9.3devel
On Thursday, January 10, 2013 12:01 PM Pavan Deolasee wrote:
> On Thu, Jan 10, 2013 at 11:45 AM, Amit Kapila
> wrote:
> > On Thursday, January 10, 2013 6:09 AM Josh Berkus wrote:
>
> >>
> >> Surely VACUUM FULL should rebuild the visibility map, and make
> tuples
> >> in
> >> the new relation all-
On 10 January 2013 06:06, Jeff Davis wrote:
> The checksums patch also introduces another behavior into
> SetBufferCommitInfoNeedsSave, which is to write an XLOG_HINT WAL record
> if checksums are enabled (to avoid torn page hazards). That's only
> necessary for changes where the caller does not
57 matches
Mail list logo
