(2011/08/09 7:01), Josh Kupershmidt wrote:
I am a bit confused as to why we have both \det and \dE. They seem
redundant. Shouldn't we rip one of those out? IMHO, \det should be
the one to go, as it could be useful to do, e.g. \dtvE, which isn't
going to work with the \det syntax.
Yeah, I
On 09.08.2011 08:27, Tom Lane wrote:
select ... from pg_cast c where c.oid= 16384;
What that really does is eliminate the casts that were installed during
initdb, which are at least a subset of the system ones, and might be
all of them depending on what you feel a system cast is. The main
* David Fetter:
What is it about a GPLed psql client that is a non-starter for the
installer? I'm not a fan of the GPL, but in this case, the effects of
linking it in are quite limited in scope, i.e. they pertain to exactly
one binary.
And the usual showstopper, OpenSSL, might well fall
Currently, if you take a backup with pg_basebackup -x (which means it
will include all the WAL to required restore within the backup dump),
and hit Ctrl-C while the WAL is being streamed, you end up with a data
directory that you can start postmaster from, even though the backup was
not
On 08.08.2011 22:11, Alvaro Herrera wrote:
Perhaps the easiest way to fix it is as you suggest, by declaring the
struct to take a pointer rather than the value directly. Not sure how
to make both cases work sanely; the add_string_reloption path will need
updates.
Agreed, I propose the
(2011/08/09 1:16), Robert Haas wrote:
2011/8/8 Shigeru Hanadashigeru.han...@gmail.com:
Currently table-level options are showin in result of \det+ command
(only verbose mode), in same style as fdw and foreign servers.
But \d is more popular for table describing, so moving table-level
options
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 concerns, and some space alignment issues that hidden in
some of those
On 09.08.2011 13:25, Heikki Linnakangas wrote:
On 08.08.2011 22:11, Alvaro Herrera wrote:
Perhaps the easiest way to fix it is as you suggest, by declaring the
struct to take a pointer rather than the value directly. Not sure how
to make both cases work sanely; the add_string_reloption path
When i try to fetch sources via git, there is an error:
error: Unable to find 676e3c735dec32ba0448fdd0faf9ace37c1fa792 under
http://git.postgresql.org/git/postgresql.git
Cannot obtain needed object 676e3c735dec32ba0448fdd0faf9ace37c1fa792
error: Fetch failed.
How to get current branch ?
On 08/09/2011 09:10 AM, pasman pasmański wrote:
When i try to fetch sources via git, there is an error:
error: Unable to find 676e3c735dec32ba0448fdd0faf9ace37c1fa792 under
http://git.postgresql.org/git/postgresql.git
Cannot obtain needed object 676e3c735dec32ba0448fdd0faf9ace37c1fa792
error:
Florian Pflug f...@phlo.org wrote:
I think it would be helpful if we had a more precise idea about
the intended use-cases. So far, the only use-case that has been
described in detail is the one which made Kevin aware of the
problem. But if I understood Kevin correctly, that fact that they
Florian Pflug f...@phlo.org wrote:
To summarize, here's what I currently believe would be a sensible
approach:
After every BEFORE trigger invocation, if the trigger returned
non-NULL, check if latest row version is still the same as when
the trigger started. If not, complain.
That
On 08/09/2011 01:27 AM, Tom Lane wrote:
Another approach is to check pg_depend. A cast installed by initdb will
match a pin entry in pg_depend (refclassid = pg_cast, refobjid =
cast's OID, deptype = 'p'). You're still out of luck for distinguishing
extension members in existing releases, but
On 08/09/2011 09:22 AM, Andrew Dunstan wrote:
On 08/09/2011 09:10 AM, pasman pasmański wrote:
When i try to fetch sources via git, there is an error:
error: Unable to find 676e3c735dec32ba0448fdd0faf9ace37c1fa792 under
http://git.postgresql.org/git/postgresql.git
Cannot obtain needed
On Aug9, 2011, at 15:41 , Kevin Grittner wrote:
Florian Pflug f...@phlo.org wrote:
To summarize, here's what I currently believe would be a sensible
approach:
After every BEFORE trigger invocation, if the trigger returned
non-NULL, check if latest row version is still the same as when
Florian Pflug f...@phlo.org wrote:
Another option would be to re-issue the DELETE from the BEFORE
DELETE trigger, and then return NULL. It'll cause the BEFORE
DELETE trigger to be invoked recursively, but presumably the
second invocation could easily detect that all required pre-delete
Excerpts from Heikki Linnakangas's message of mar ago 09 08:32:43 -0400 2011:
On 09.08.2011 13:25, Heikki Linnakangas wrote:
On 08.08.2011 22:11, Alvaro Herrera wrote:
Perhaps the easiest way to fix it is as you suggest, by declaring the
struct to take a pointer rather than the value
Excerpts from Heikki Linnakangas's message of mar ago 09 05:00:00 -0400 2011:
I think this is a nice additional safeguard to have, making streamed
backups more robust. I'd like to add this to 9.1, but it required an
extra field to be added to the control file, so it would force an
initdb.
On 09.08.2011 18:20, Alvaro Herrera wrote:
Excerpts from Heikki Linnakangas's message of mar ago 09 05:00:00 -0400 2011:
I think this is a nice additional safeguard to have, making streamed
backups more robust. I'd like to add this to 9.1, but it required an
extra field to be added to the
On 09.08.2011 18:04, Alvaro Herrera wrote:
Excerpts from Heikki Linnakangas's message of mar ago 09 08:32:43 -0400 2011:
On 09.08.2011 13:25, Heikki Linnakangas wrote:
On 08.08.2011 22:11, Alvaro Herrera wrote:
Perhaps the easiest way to fix it is as you suggest, by declaring the
struct to
On 08/08/2011 05:03 AM, Tim Bunce wrote:
After giving it some more thought it seems reasonable to simply force the
SIGALRM handler back to postgres when a plperlu function returns:
pqsignal(SIGALRM, handle_sig_alarm);
Maybe we need to do this in some more centralized spot. It seems
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 in the patch. However, the problem wrt.
requiring initdb is not
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 09.08.2011 18:04, Alvaro Herrera wrote:
I think I vaguely remember that the reason for doing it this way is that
the copy into the relcache worked, i.e. if the originals went away,
there was no dangling pointer. Did you test
Andrew Dunstan and...@dunslane.net writes:
On 08/08/2011 05:03 AM, Tim Bunce wrote:
After giving it some more thought it seems reasonable to simply force the
SIGALRM handler back to postgres when a plperlu function returns:
pqsignal(SIGALRM, handle_sig_alarm);
Maybe we need to do this in
On 08/09/2011 12:22 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
On 08/08/2011 05:03 AM, Tim Bunce wrote:
After giving it some more thought it seems reasonable to simply force the
SIGALRM handler back to postgres when a plperlu function returns:
pqsignal(SIGALRM,
Hi,
Previously, we had some discussion to introduce a new type of tuple lock
to let foreign keys be lighter weight, allowing for more concurrency.
During the course of that discussion, it became evident that the
solution being proposed didn't go all the way to solve the problem. A
proposal by
When a host name is used in pg_hba.conf, then we call
pg_getnameinfo_all() to get the host name for the client's IP address,
either in postmaster.c or in hba.c, whichever happens first. But if the
IP address has no host name, the getnameinfo calls return the IP address
in text form, which is then
On Tue, 2011-08-09 at 13:01 -0400, Alvaro Herrera wrote:
Note that the KEY UPDATE lock would be an internal option, not exposed
to SQL. I think we already have enough extensions in this area. We are
forced to expose KEY SHARE because RI triggers get to it via SPI, but I
would be happy to
Excerpts from Jeff Davis's message of mar ago 09 14:41:14 -0400 2011:
On Tue, 2011-08-09 at 13:01 -0400, Alvaro Herrera wrote:
Note that the KEY UPDATE lock would be an internal option, not exposed
to SQL. I think we already have enough extensions in this area. We are
forced to expose KEY
On Aug9, 2011, at 19:01 , Alvaro Herrera wrote:
This would also help us find a solution to the problem that an aborted
subtransaction that updates or excl-locks a tuple causes an earlier
shared lock to be forgotten. We would deal with this by marking the
Xmax with a new MultiXact that
On Aug9, 2011, at 19:01 , Alvaro Herrera wrote:
Note that this means that UPDATE would always have to check whether key
columns are being modified. (I loosely talk about key columns here
referring to columns involving unique indexes. On tables with no unique
indexes, I think this would have
When an ext2, ext3, or ext4 filesystem is mounted directly on the PGDATA
directory, initdb will refuse to run because it sees the
lost+found directory that mke2fs created and assumes the PGDATA directory is
already in use for something other than PostgreSQL.
Attached is a patch against master
Excerpts from Florian Pflug's message of mar ago 09 15:41:00 -0400 2011:
First, I'd like to see us support FKs which reference non-unqiue columns.
As long as we restrict such FK constraints to ON UPDATE/DELETE RESTRICT
(or NO ACTION), there's no conceptual difficulty in doing that. Yeah, I
On Tue, 2011-08-09 at 14:52 -0400, Brian Pitts wrote:
When an ext2, ext3, or ext4 filesystem is mounted directly on the
PGDATA directory, initdb will refuse to run because it sees the
lost+found directory that mke2fs created and assumes the PGDATA
directory is already in use for something
On Tue, Aug 9, 2011 at 1:52 PM, Brian Pitts b...@uga.edu wrote:
When an ext2, ext3, or ext4 filesystem is mounted directly on the PGDATA
directory, initdb will refuse to run because it sees the
lost+found directory that mke2fs created and assumes the PGDATA directory is
already in use for
On Tue, 2011-08-09 at 14:52 -0400, Brian Pitts wrote:
Attached is a patch against master which will cause a directory that
contains only lost+found to still be treated as empty.
Please add this to the September commitfest at:
https://commitfest.postgresql.org/
Regards,
Jeff Davis
--
Brian Pitts b...@uga.edu writes:
When an ext2, ext3, or ext4 filesystem is mounted directly on the PGDATA
directory, initdb will refuse to run because it sees the
lost+found directory that mke2fs created and assumes the PGDATA directory is
already in use for something other than PostgreSQL.
Andrew Dunstan and...@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 is just locking the barn door after the
Excerpts from Jeff Davis's message of mar ago 09 16:03:26 -0400 2011:
On Tue, 2011-08-09 at 14:52 -0400, Brian Pitts wrote:
When an ext2, ext3, or ext4 filesystem is mounted directly on the
PGDATA directory, initdb will refuse to run because it sees the
lost+found directory that mke2fs
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 internal
mechanisms, and I don't see the
Excerpts from Tom Lane's message of mar ago 09 16:40:15 -0400 2011:
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
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Jeff Davis's message of mar ago 09 16:03:26 -0400 2011:
I think I agree with Peter here that it's not a very good idea, and I
don't see a big upside. With tablespaces it seems to make a little bit
more sense, but I'd still lean
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 9 August 2011 23:07, Tom Lane t...@sss.pgh.pa.us wrote:
Now that I've got the WaitLatch code fully swapped into my head,
I'm thinking of pushing on to review/commit this patch of Peter's.
Thanks for giving this your attention. I had already planned to
produce a new revision this weekend, so
On Aug 9, 2011, at 4:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Like Florian, I'm considerably more concerned about the aspect of
deciding which columns are key columns and whether they changed.
Should we consider trying implement a system that can lock individual columns?
Either way, my main
Peter Geoghegan pe...@2ndquadrant.com writes:
On 9 August 2011 23:07, Tom Lane t...@sss.pgh.pa.us wrote:
Now that I've got the WaitLatch code fully swapped into my head,
I'm thinking of pushing on to review/commit this patch of Peter's.
Thanks for giving this your attention. I had already
On Sat, Jul 23, 2011 at 3:39 AM, Andrew Dunstan and...@dunslane.net wrote:
1. I think the proposed use is of very marginal value at best, and
certainly not worth importing an external library for.
Now that I've seen two people who seem to think that this is not an
important feature I'll wade
47 matches
Mail list logo
