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 compl
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 attached
(2011/08/09 1:16), Robert Haas wrote:
> 2011/8/8 Shigeru Hanada:
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 fro
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 hardc
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 will
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 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
> use BEFORE
Florian Pflug 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 certain
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
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 object
On Aug9, 2011, at 15:41 , Kevin Grittner wrote:
> Florian Pflug 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 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
> actions have
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 valu
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
> initd
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 contr
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 tak
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 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 the new field in backup_label,
Heikki Linnakangas 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 this?
> These strings are neve
Andrew Dunstan 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 some more cent
On 08/09/2011 12:22 PM, Tom Lane wrote:
Andrew Dunstan 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 n
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 Noa
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 expo
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 incl
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
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 whi
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 o
On Tue, Aug 9, 2011 at 1:52 PM, 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 o
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 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.
> Attache
Andrew Dunstan 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 horses
>> left.
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 mke2f
Alvaro Herrera 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 benefit in doing so.
> We
Excerpts from Tom Lane's message of mar ago 09 16:40:15 -0400 2011:
> Alvaro Herrera 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 sp
Alvaro Herrera 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 away from that idea.
Peter Geoghegan 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 ownership is
> subs
On 9 August 2011 23:07, Tom Lane 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 I'd appreciate it
On Aug 9, 2011, at 4:40 PM, Tom Lane 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 concern is that
Peter Geoghegan writes:
> On 9 August 2011 23:07, Tom Lane 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 t
On Sat, Jul 23, 2011 at 3:39 AM, Andrew Dunstan 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 in and respond
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
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
48 matches
Mail list logo
