On Tue, Aug 09, 2011 at 09:41:00PM +0200, Florian Pflug wrote:
Couldn't we simply give the user a way to specify, per column, whether or
not that column is a KEY column? Creating a foreign key constraint could
still implicitly mark all referenced columns as KEY columns, but columns
would no
Success !
I can't use git protocol, but
github via http works fine.
Thank you Andrew :)
pasman
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Aug 09, 2011 at 01:01:04PM -0400, Alvaro Herrera wrote:
KEY UPDATEFOR UPDATE FOR SHARE KEY SHARE
KEY UPDATE X XX X
FOR UPDATE X XX
FOR SHAREX X
KEY SHAREX
DELETE
On Aug9, 2011, at 22:40 , Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Jeff Davis's message of mar ago 09 14:41:14 -0400 2011:
Right now, FKs aren't really very special, they are mostly just
syntactic sugar (right?). This proposal would make FKs special
On Aug10, 2011, at 08:45 , Noah Misch wrote:
On Tue, Aug 09, 2011 at 09:41:00PM +0200, Florian Pflug wrote:
Couldn't we simply give the user a way to specify, per column, whether or
not that column is a KEY column? Creating a foreign key constraint could
still implicitly mark all referenced
On 10 August 2011 01:35, Tom Lane t...@sss.pgh.pa.us wrote:
Actually, I'm nearly done with it already. Perhaps you could start
thinking about the other polling loops.
Fair enough. I'm slightly surprised that there doesn't need to be some
bikeshedding about my idea to treat the PGPROC latch as
On 09.08.2011 19:07, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
On 09.08.2011 18:20, Alvaro Herrera wrote:
How about making the new backup_label field optional? If absent, assume
current behavior.
That's how I actually did it in the patch. However, the
On Tue, Aug 9, 2011 at 18:07, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 09.08.2011 18:20, Alvaro Herrera wrote:
How about making the new backup_label field optional? If absent, assume
current behavior.
That's how I actually did it
On Tue, Aug 9, 2011 at 13:38, Peter Eisentraut pete...@gmx.net wrote:
I noticed that the progress reporting code in pg_basebackup does not
allow for translation. This would normally be easy to fix, but this
code has a number of tricky issues, including the INT64_FORMAT, possibly
some plural
Hi!
Here is last verion of the patch.
List of changes:
1) Neighbor relocation and prefetch were removed. They will be supplied as
separate patches.
2) Final emptying now using standart lists of all buffers by levels.
3) Automatic switching again use simple comparison of index size and
On 10.08.2011 12:29, Magnus Hagander wrote:
On Tue, Aug 9, 2011 at 18:07, Tom Lanet...@sss.pgh.pa.us wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
On 09.08.2011 18:20, Alvaro Herrera wrote:
How about making the new backup_label field optional? If absent, assume
On Wed, Aug 10, 2011 at 12:44, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 10.08.2011 12:29, Magnus Hagander wrote:
On Tue, Aug 9, 2011 at 18:07, Tom Lanet...@sss.pgh.pa.us wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
On 09.08.2011 18:20,
On Sun, Jul 24, 2011 at 20:48, Tom Lane t...@sss.pgh.pa.us wrote:
In testing the fix for the SSL problem that Martin Pihlak reported, I
realized that libpq doesn't really cope very well with errors reported
by OpenSSL. In the case at hand, SSL_write returns an SSL_ERROR_SSL
code, which
On Tue, Jul 26, 2011 at 15:20, Andrew Dunstan and...@dunslane.net wrote:
Why do we get this warning on Mingw?:
x86_64-w64-mingw32-gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wformat-security
-fno-strict-aliasing -fwrapv -g
On Wed, Aug 10, 2011 at 6:53 AM, Magnus Hagander mag...@hagander.net wrote:
On Wed, Aug 10, 2011 at 12:44, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 10.08.2011 12:29, Magnus Hagander wrote:
On Tue, Aug 9, 2011 at 18:07, Tom Lanet...@sss.pgh.pa.us wrote:
Heikki
On Mon, Aug 8, 2011 at 1:38 PM, Andrew Hammond
andrew.george.hamm...@gmail.com wrote:
For a large table, should there be a difference in index sizes between a
single table representation and representation based on multiple partitions
with identical indexes?
This isn't really the right mailing
On Wed, Aug 10, 2011 at 1:19 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Aug 10, 2011 at 6:53 AM, Magnus Hagander mag...@hagander.net wrote:
On Wed, Aug 10, 2011 at 12:44, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 10.08.2011 12:29, Magnus Hagander wrote:
On
On Sun, Jul 31, 2011 at 03:25, Andrew Dunstan and...@dunslane.net wrote:
On 07/06/2011 08:26 PM, Brar Piening wrote:
Original Message
Subject: Re: [HACKERS] Review of VS 2010 support patches
From: Andrew Dunstan and...@dunslane.net
To: Brar Piening b...@gmx.de
Date:
On Wed, Aug 10, 2011 at 9:03 AM, Magnus Hagander mag...@hagander.net wrote:
I am no perl expert, but I see we are using this already today - in
code written by you in one case ;) I'd assume it was just following
the same standard... If the other way is the way to do it today, I see
no reason
On 08/10/2011 09:03 AM, Magnus Hagander wrote:
On Sun, Jul 31, 2011 at 03:25, Andrew Dunstanand...@dunslane.net wrote:
On 07/06/2011 08:26 PM, Brar Piening wrote:
Original Message
Subject: Re: [HACKERS] Review of VS 2010 support patches
From: Andrew
On 08/10/2011 09:21 AM, Robert Haas wrote:
On Wed, Aug 10, 2011 at 9:03 AM, Magnus Hagandermag...@hagander.net wrote:
I am no perl expert, but I see we are using this already today - in
code written by you in one case ;) I'd assume it was just following
the same standard... If the other way
On Wed, Aug 10, 2011 at 15:25, Andrew Dunstan and...@dunslane.net wrote:
On 08/10/2011 09:03 AM, Magnus Hagander wrote:
On Sun, Jul 31, 2011 at 03:25, Andrew Dunstanand...@dunslane.net wrote:
On 07/06/2011 08:26 PM, Brar Piening wrote:
Original Message
Subject: Re:
Peter Geoghegan pe...@2ndquadrant.com writes:
On 10 August 2011 01:35, Tom Lane t...@sss.pgh.pa.us wrote:
Actually, I'm nearly done with it already. Perhaps you could start
thinking about the other polling loops.
Fair enough. I'm slightly surprised that there doesn't need to be some
On 08/10/2011 08:08 AM, Magnus Hagander wrote:
On Tue, Jul 26, 2011 at 15:20, Andrew Dunstanand...@dunslane.net wrote:
Why do we get this warning on Mingw?:
x86_64-w64-mingw32-gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels
On 10.08.2011 15:34, Simon Riggs wrote:
On Wed, Aug 10, 2011 at 1:19 PM, Robert Haasrobertmh...@gmail.com wrote:
On Wed, Aug 10, 2011 at 6:53 AM, Magnus Hagandermag...@hagander.net wrote:
On Wed, Aug 10, 2011 at 12:44, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On
Hi,
I'm seeing a bunch of warnings I don't remember seeing before in the
master branch:
/pgsql/source/HEAD/src/backend/executor/execQual.c: In function
'GetAttributeByNum':
/pgsql/source/HEAD/src/backend/executor/execQual.c:1104:11: warning: the
comparison will always evaluate as 'true' for
Peter Geoghegan pe...@2ndquadrant.com writes:
Attached is revision of this patch that now treats the latch in
PGPROC, waitLatch, as the generic process latch, rather than just
using it for sync rep; It is initialised appropriately as a shared
latch generically, within InitProcGlobal(), and
On 08/09/2011 04:32 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
On 08/09/2011 12:22 PM, Tom Lane wrote:
No. As I pointed out upthread, the instant somebody changes the SIGALRM
handler to a non-Postgres-aware one, you are already at risk of failure.
Setting it back later
On Aug 9, 2011, at 6:00 PM, Peter van Hardenberg wrote:
In conclusion, this is a serious operational concern for me and my team and I
will be personally dealing with fires caused by this for years to come
regardless of the outcome of this thread.
Do you have an interest in funding
On Aug 10, 2011, at 9:44 AM, Andrew Dunstan wrote:
After some experimentation, I found that, at least on my system, if LWP uses
Crypt::SSLeay for https requests then it sets an alarm handler, but if
instead it uses IO::Socket::SSL an alarm handler is not set. So the answer to
the OP's
Andrew Dunstan and...@dunslane.net writes:
On 08/09/2011 04:32 PM, Tom Lane wrote:
[ shrug... ] Installing a perl module that mucks with the signal
handlers is in the don't do that category. A kluge such as you
suggest will not get it out of that category; all it will do is add
useless
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Hmm, that's not possible for the 'tar' output, but would work for 'dir'
output. Another similar idea would be to withhold the control file in
memory until the end of backup, and append it to the output as last. The
backup can't
On Wed, Aug 10, 2011 at 1:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Hmm, that's not possible for the 'tar' output, but would work for 'dir'
output. Another similar idea would be to withhold the control file in
memory until the end
On ons, 2011-08-10 at 12:37 -0400, Alvaro Herrera wrote:
I'm seeing a bunch of warnings I don't remember seeing before in the
master branch:
/pgsql/source/HEAD/src/backend/executor/execQual.c: In function
'GetAttributeByNum':
/pgsql/source/HEAD/src/backend/executor/execQual.c:1104:11:
I was slightly surprised the other day that the SHOW command always
returns a field of type text even if the underlying parameter has one of
the other types (int, real, etc.). Is this intentional? Would it be
worth refining?
--
Sent via pgsql-hackers mailing list
On Wed, Aug 10, 2011 at 3:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Geoghegan pe...@2ndquadrant.com writes:
On 10 August 2011 01:35, Tom Lane t...@sss.pgh.pa.us wrote:
Actually, I'm nearly done with it already. Perhaps you could start
thinking about the other polling loops.
Fair
I would like to see whether there is support for adding sha1 and sha2
functions into the core. These are obviously well-known and widely used
functions, but currently the only way to get them is either through
pgcrypto or one of the PLs. We could say that's OK, but then we do
support md5 in
Peter Eisentraut pete...@gmx.net writes:
I was slightly surprised the other day that the SHOW command always
returns a field of type text even if the underlying parameter has one of
the other types (int, real, etc.). Is this intentional? Would it be
worth refining?
I'm disinclined to mess
On Wed, Aug 10, 2011 at 19:45, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Hmm, that's not possible for the 'tar' output, but would work for 'dir'
output. Another similar idea would be to withhold the control file in
memory until the end of
Peter Eisentraut pete...@gmx.net writes:
I would like to see whether there is support for adding sha1 and sha2
functions into the core.
I can't get excited about that, but could put up with it as long as
there wasn't scope creep ...
One thing that might be reasonable would be to move the
On Wed, Aug 10, 2011 at 17:25, Andrew Dunstan and...@dunslane.net wrote:
On 08/10/2011 08:08 AM, Magnus Hagander wrote:
On Tue, Jul 26, 2011 at 15:20, Andrew Dunstanand...@dunslane.net wrote:
Why do we get this warning on Mingw?:
x86_64-w64-mingw32-gcc -O2 -Wall -Wmissing-prototypes
On 08/10/2011 02:06 PM, Peter Eisentraut wrote:
I would like to see whether there is support for adding sha1 and sha2
functions into the core. These are obviously well-known and widely used
functions, but currently the only way to get them is either through
pgcrypto or one of the PLs. We
On Wed, Aug 10, 2011 at 2:24 PM, Andrew Dunstan and...@dunslane.net wrote:
It's come up before:
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01293.php
I was about to wonder out loud if we might be trying to hit a moving target
--
Robert Haas
EnterpriseDB:
Excerpts from Tom Lane's message of mié ago 10 14:12:49 -0400 2011:
Peter Eisentraut pete...@gmx.net writes:
I was slightly surprised the other day that the SHOW command always
returns a field of type text even if the underlying parameter has one of
the other types (int, real, etc.). Is
On Wed, Aug 10, 2011 at 7:06 PM, Peter Eisentraut pete...@gmx.net wrote:
I would like to see whether there is support for adding sha1 and sha2
functions into the core. These are obviously well-known and widely used
functions, but currently the only way to get them is either through
pgcrypto
On ons, 2011-08-10 at 19:29 +0100, Dave Page wrote:
On Wed, Aug 10, 2011 at 7:06 PM, Peter Eisentraut pete...@gmx.net wrote:
I would like to see whether there is support for adding sha1 and sha2
functions into the core. These are obviously well-known and widely used
functions, but
We occasionally see $SUBJECT in the buildfarm, and I've also recently
had reports of them from Red Hat customers. The obvious theory is that
these reflect high load preventing the stats collector from responding,
but it would really take pretty crushing load to make that happen if
there were not
On ons, 2011-08-10 at 14:26 -0400, Robert Haas wrote:
On Wed, Aug 10, 2011 at 2:24 PM, Andrew Dunstan and...@dunslane.net wrote:
It's come up before:
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01293.php
I was about to wonder out loud if we might be trying to hit a moving
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of mié ago 10 14:12:49 -0400 2011:
Peter Eisentraut pete...@gmx.net writes:
I was slightly surprised the other day that the SHOW command always
returns a field of type text even if the underlying parameter has
On 10.08.2011 21:45, Tom Lane wrote:
We occasionally see $SUBJECT in the buildfarm, and I've also recently
had reports of them from Red Hat customers. The obvious theory is that
these reflect high load preventing the stats collector from responding,
but it would really take pretty crushing load
Beginning with commit 002c105a0706bd1c1e939fe0f47ecdceeae6c52d
pg_upgrade will fail if there are orphaned temp tables in the current
database with the message 'old and new databases postgres have a
different number of relations'
On line 41 of pg_upgrade/info.c pg_upgrade checks that the number
On 10.08.2011 21:45, Peter Eisentraut wrote:
On ons, 2011-08-10 at 14:26 -0400, Robert Haas wrote:
On Wed, Aug 10, 2011 at 2:24 PM, Andrew Dunstanand...@dunslane.net wrote:
It's come up before:
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01293.php
I was about to wonder out loud
On Wed, Aug 10, 2011 at 21:02, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 10.08.2011 21:45, Peter Eisentraut wrote:
On ons, 2011-08-10 at 14:26 -0400, Robert Haas wrote:
On Wed, Aug 10, 2011 at 2:24 PM, Andrew Dunstanand...@dunslane.net
wrote:
It's come up before:
Dave Byrne dby...@mdb.com writes:
Beginning with commit 002c105a0706bd1c1e939fe0f47ecdceeae6c52d
pg_upgrade will fail if there are orphaned temp tables in the current
database with the message 'old and new databases postgres have a
different number of relations'
On line 41 of
Manual and readme updates.
--
With best regards,
Alexander Korotkov.
gist_fast_build-0.12.0.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 10.08.2011 13:19, Alexander Korotkov wrote:
Hi!
Here is last verion of the patch.
List of changes:
1) Neighbor relocation and prefetch were removed. They will be supplied as
separate patches.
unloadNodeBuffers() is now dead code.
2) Final emptying now using standart lists of all buffers
AFAICS we could get rid of WalSndDelay: there is no longer any reason
for the walsender loop to wake up unless it's received a latch event.
(Its WaitLatch call is missing WL_POSTMASTER_DEATH right now, but that
is easily fixed.) Is anyone sufficiently attached to that GUC to not
want to see it go
On Wed, Aug 10, 2011 at 10:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
AFAICS we could get rid of WalSndDelay: there is no longer any reason
for the walsender loop to wake up unless it's received a latch event.
(Its WaitLatch call is missing WL_POSTMASTER_DEATH right now, but that
is easily
Robert Haas robertmh...@gmail.com writes:
However, it doesn't really do anything to solve this problem. The
problem here is not that the size of the relation is changing too
frequently - indeed, it's not changing at all in this test case. The
problem is rather that testing whether or not the
Attached is a patch that skips orphaned temporary relations in pg_upgrade if
they are lingering around. It works for 9.0 - 9.1 upgrades, however I wasn't
able to tell when pg_class.relistemp was added so if it was unavailable in
versions prior to 9.0 an additional check will have to be added.
Dave Byrne dby...@mdb.com writes:
Attached is a patch that skips orphaned temporary relations in pg_upgrade if
they are lingering around. It works for 9.0 - 9.1 upgrades, however I wasn't
able to tell when pg_class.relistemp was added so if it was unavailable in
versions prior to 9.0 an
On Wed, Aug 10, 2011 at 5:29 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, Aug 10, 2011 at 10:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
AFAICS we could get rid of WalSndDelay: there is no longer any reason
for the walsender loop to wake up unless it's received a latch event.
(Its
2011/8/10 Dimitri Fontaine dfonta...@hi-media.com:
Robert Haas robertmh...@gmail.com writes:
However, it doesn't really do anything to solve this problem. The
problem here is not that the size of the relation is changing too
frequently - indeed, it's not changing at all in this test case.
Excerpts from Robert Haas's message of mié ago 10 21:27:08 -0400 2011:
2011/8/10 Dimitri Fontaine dfonta...@hi-media.com:
Robert Haas robertmh...@gmail.com writes:
However, it doesn't really do anything to solve this problem. The
problem here is not that the size of the relation is
On Wed, Aug 10, 2011 at 9:46 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mié ago 10 21:27:08 -0400 2011:
2011/8/10 Dimitri Fontaine dfonta...@hi-media.com:
Robert Haas robertmh...@gmail.com writes:
However, it doesn't really do anything to
65 matches
Mail list logo
