* k...@roeckx.be (k...@roeckx.be) wrote:
> Allows SELECT from any column, or the specific columns listed, of the
> specified table, view, or sequence. Also allows the use of COPY TO. This
> privilege is also needed to reference existing column values in UPDATE or
> DELETE.
>
>
> I read that a
* Pawel Kozik (pawel.ko...@alcatel-lucent.com) wrote:
> Any idea when it will be available in official PostgreSQL release 9.1.x or
> 9.2.x ?
Yes, the next set of point releases should include Tom's patch to fix
this leak.
Thanks,
Stephen
signature.asc
Description: Digi
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I'm already working on back-patching the attached.
Works for me,
Thanks!
Stephen
signature.asc
Description: Digital signature
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Meh. I'm not impressed with permanently allocating an array large
> enough to hold all the locks GetRunningTransactionLocks
> might return --- that's potentially much larger than the other array,
> and in fact I don't think we have a hard limit on its size
* Andres Freund (and...@2ndquadrant.com) wrote:
> Seems more consistent with the rest of the code too. But anyway, I am
> fine with fixing it either way.
Patch attached which mirrors what GetRunningTransactionData() (the other
function called from LogStandbySnapshot) does, more-or-less- uses a
sta
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2013-06-04 16:23:00 +0300, Heikki Linnakangas wrote:
> > I can't get too excited about the overhead of a single palloc here. It's a
> > fairly heavy operation anyway, and only runs once per checkpoint. And we
> > haven't heard any actual complain
* Naoya Anzai (anzai-na...@mxu.nes.nec.co.jp) wrote:
> I've found a memory-leak bug in PostgreSQL 9.1.9's background
> writer process.
This looks legit, but probably not the right approach to fixing it.
Looks like it'd be better to work out a way to use a static variable to
reuse the same memory,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> Please attach patches directly with the mails you send.
+1.
> For the patch, yes OK there are some spell mistakes. However this patch
> should only apply on master branch, and not 9.2 as referenced above.
Agreed.
> Also,
> changing the stru
Maxim,
* maxim.bo...@gmail.com (maxim.bo...@gmail.com) wrote:
> It seems that documentation wrong or [ CASCADE | RESTRICT ] feature of ALTER
> TYPE ... RENAME TO isn't implemented.
I've updated the documentation to reflect that [ CASCADE | RESTRICT ] is
supported for ALTER TYPE .. RENAME ATTRIBUT
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Are we sure the documentation's not wrong? A quick test says this
> syntax isn't accepted in *any* existing release, and I can't say I
> understand what it should do anyway.
Was just composing an email to that effect, actually. I agree that it's
a documen
Maxim,
* Stephen Frost (sfr...@snowman.net) wrote:
> * maxim.bo...@gmail.com (maxim.bo...@gmail.com) wrote:
> > It seems that documentation wrong or [ CASCADE | RESTRICT ] feature of ALTER
> > TYPE ... RENAME TO isn't implemented.
>
> Actually, I'm pretty sure i
Maxim,
* maxim.bo...@gmail.com (maxim.bo...@gmail.com) wrote:
> It seems that documentation wrong or [ CASCADE | RESTRICT ] feature of ALTER
> TYPE ... RENAME TO isn't implemented.
Actually, I'm pretty sure it's implemented but the grammar for it was
broken during refactoring to have all the ALTE
* j...@tanga.com (j...@tanga.com) wrote:
> My goal is to remove nulls from an array. The array could be an array of a
> composite type.
A much simpler case is:
=> create type xt as (a integer);
CREATE TYPE
=> select * from unnest(array[null::xt]);
ERROR: function returning set of rows cannot ret
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Let me be clear here: I don't think we can or should ever make this
> into an error by default. Doing that would break spec-compliant
> applications, whether or not they are using names that actually have
> any conflicts.
If we increase the length to the s
* Phil Sorber (p...@omniti.com) wrote:
> In addition it actually works!
Only until the ORM tries to create two tables that are identical except
for the last few characters..
> So I am sharing this with the list to see what people think. Is this a
> configuration bug? An ORM bug? A postgres bug? A
* Henk Enting (h.d.ent...@mgrid.net) wrote:
> But still, I think the to_timestamp should throw an error if I put in
> something like '21-21-2011'.
I agree completely, this is a pretty big bug in my opinion. We don't
accept invalid or garbage timestamps in the input function, I don't see
any reaso
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
> > Could you please provide us some support regarding this issue?
[...]
> Please read this and post to the pgsql-performance list:
>
> http://wiki.postgresql.org/wiki/SlowQueryQuestions
If that looks like a lot of complication/effort, let's
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Mph ... removing the public schema from the restore list is problematic,
> because you've got a lot of stuff *in* the public schema, and of course
> all that stuff depends on the public schema entry. Normally this
> doesn't bother pg_restore because it just
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I suggest that we document hostaddr as being an auxiliary field that is
> not intended to be the primary source of the host name, but merely saves
> libpq from having to do a forward DNS lookup. In some cases it will
> work to supply hostaddr without host,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Perhaps I was being a bit overzealous in my last response, sorry about
> > that. If the point here is that people who are using hostaddr are in an
> > environment where DNS is non-functional or actively broke
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Hm. That might happen to work for Kerberos, but it won't work for
> GSSAPI or SSPI --- in both those code paths we just push the host name
> literally into a constructed principal string. Not sure if we really
> want Kerberos to work differently from the m
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Uh, no, because hostaddr is (required to be) a numeric IP. The odds of
> it being useful in this context seem negligible.
Perhaps I was being a bit overzealous in my last response, sorry about
that. If the point here is that people who are using hostaddr
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > krb5_sname_to_principal() will use the passed hostname for the second
> > component. If type is KRB5_NT_SRV_HST this name will be looked up with
> > gethostbyname(). If hostname is NULL, the l
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I've never found a reason to use hostaddr, so I don't particularly care,
> > but it doesn't seem right to break Kerberos auth if you were only given
> > an IP address unless hostaddr'
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Yeah, but the code in fe-auth.c throws an error before the Kerberos
> libraries get a chance to do any such thing. I suppose that the
> documentation text was accurate when written, but that was a long time
> ago.
e, yeah, there are some issues with th
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> ... btw, the libpq documentation claims that
>
> If hostaddr is specified without host, the value for hostaddr
> gives the remote address. When Kerberos is used, a reverse name
> query occurs to obtain the host name for Kerberos.
>
> but
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Actually, I was thinking that the three-file approach is just
> unnecessary complication. What about two files, schema and data,
> with the schema file including a \i for the data at the right place?
> This could be enabled by a single additional switch
> "
* Stefan Kaltenbrunner (ste...@kaltenbrunner.cc) wrote:
> well that is an argument for providing not only --schema-only and
> --data-only but rather three options one for the table definitions, one
> for the data and one for all the constraints and indexes. So basically
> what pg_dump is curr
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Heikki Linnakangas writes:
> > Much easier to do a schema-only dump, edit that, and dump data separately.
>
> That gets you out of the huge-file-to-edit problem, but the performance
> costs of restoring a separate-data dump are a pretty serious
> disadvant
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Erm, I don't know that we deal with function-body problems today, even
> > when using the newer version of pg_dump, do we?
>
> Right, any forward-compatibility problems arising inside functions
> ar
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stefan Kaltenbrunner writes:
> > That is exactly what I think is "to big a promise" - I don't think we
> > can actually guarantee that this will fix the dump/restore issue (well
> > the dump might load but say the 3 lines of plpgsql using dynamic SQL
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> > Well, if you dump in custom format, it could be useful to be able to
> > do this on pg_restore time. Not having followed this thread in detail,
> > but would that work? That would be a much more useful option...
>
> I don't think so because muc
* Bruce Momjian (br...@momjian.us) wrote:
> >From a code perspective, the difficulting in adding such a flag is that
> much of the quoting happens inside the backend, not by pg_dump, and
> therefore there is significant code change required to add this flag.
So, that strikes me as the main argumen
* Magnus Hagander (mag...@hagander.net) wrote:
> On Thu, Jun 10, 2010 at 15:35, Stefan Kaltenbrunner
> wrote:
> > that will pretty much defeat the purpose for most use cases i guess because
> > people will dump with the defaults and only discover the problem after the
> > fact.
>
> Well, if you d
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> Robert Haas wrote:
> > > In a way, the fact that the restore fails can be seen as a feature ---
> > > they get the error before the go live on 8.4. ?(Yeah, I am serious.)
> >
> > Eeh, I've had this happen to me on earlier releases, and it didn't
* Hartmut Goebel (h.goe...@goebel-consult.de) wrote:
> Am 04.06.2010 13:56, schrieb Stephen Frost:
> > Quoting all column names makes the dump script much more difficult for
> > human consumption, which is important.
>
> I don't agree with you here. But this may be
* Hartmut Goebel (h.goe...@goebel-consult.de) wrote:
> Am 03.06.2010 16:15, schrieb Tom Lane:
> > That was considered and rejected long ago. Readability of the dump
> > script is something that we put a nonzero value on.
>
> I assume you mean readability for humans?!
Yes, readability for humans
* Thom Brown (thombr...@gmail.com) wrote:
> psql -U postgres -d test -c "select tablename,
> pg_size_pretty(pg_table_size(tablename::regclass)) from pg_tables
> where schemaname = 'public' order by tablename;"
>
> And this, for some reason, works... which is how I did it the other
> day (hence why
All,
Sorry, I havn't really been following this thread.
* Craig Ringer (cr...@postnewspapers.com.au) wrote:
> #5245 is about *CLIENT* *VALIDATION* *OF* *THE* *SERVER*, where the
> *CLIENT* VALIDATES THE *SERVER* after the server sends a
> CertificateRequest.
>
> For #5468 to be addressed
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> What I meant to question is *which* file the intermediate CA certs
> go into. It doesn't seem tremendously sensible to me to put them into
> the server.crt file, since that's intended to define exactly one cert,
> namely the one identifying the server. On
Greetings,
-1 appears to be ignored when '-f -' is set.
test_file contains:
set client_min_messages=error;
create schema tiger_us;
These produce different results:
BEGIN, but no COMMIT:
beren:/data3/tiger> psql -o /dev/null -e \
--no-psqlrc \
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Peter Koczan writes:
> > This is trust authentication with one rather inconsequential bit of
> > verification, that's a fundamental breakage. One of the major points
> > of Kerberos is that, for anything that talks Kerberos, you are the
> > principal in tha
* Martin Pitt (mp...@debian.org) wrote:
> Magnus Hagander [2009-04-11 11:50 +0200]:
> > That has just been brought up from previous versions. Perhaps we need to
> > have a system wide root store as well - then you could point that to
> > whatever snakeoil store you have, and it would find the cert
* Martin Pitt (mp...@debian.org) wrote:
> For the record, I don't agree. SSL certificate validation is good, and
> should be done as long as you have a cert installed. Encryption
> without authentication is not worth a lot, after all.
I disagree, and you *can* do authentication without SSL! The b
* Peter Eisentraut (pete...@gmx.net) wrote:
> The new firefox just says "invalid certificate" and nothing else, and then
> somewhere below there is a small link to "Add an exception" and you need a
> total of four clicks to proceed. So that looks a lot like that they are
> moving away from easi
* Peter Eisentraut (pete...@gmx.net) wrote:
> On Friday 10 April 2009 21:32:29 Stephen Frost wrote:
> > A properly configured server could cause a failure too unless the client
> > is *also* properly configured. Sure, it's good for people to do. No, I
> > don't
* Peter Eisentraut (pete...@gmx.net) wrote:
> This is not a question of new client with old server. The new version of the
> client has a more secure default that will possibly prevent it from
> connecting
> to *any* server that is not adequately configured.
A properly configured server could
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I think I agree with Martin on this. The server doesn't fail if you
> don't provide it a root cert; it just doesn't try to trace client certs
> to the root. It is not apparent why the client should be stricter than
> that, and definitely not apparent why s
Greetings,
psql seems to accept syntax which would be rejected by the server,
which seems a bit odd:
sfrost*=# \copy billing_data from ../BillingSamplePricerFile.csv
with csv header quote as '"' null as 'abc' null as '123'
ERROR: invalid input syntax for integer: ""
vs.
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
> Tom Lane wrote:
> > 2007-06-28 22:02:14.418 EDT 2870 LOG: statement: begin;
> > 2007-06-28 22:02:26.044 EDT 2870 LOG: statement: SAVEPOINT
> > pg_psql_temporary_savepoint
> > 2007-06-28 22:02:26.045 EDT 2870 LOG: statement: set local role tgl;
> > 2
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Ah. log_statement = all tells the tale:
[...]
> 2007-06-28 22:02:14.418 EDT 2870 LOG: statement: begin;
> 2007-06-28 22:02:26.044 EDT 2870 LOG: statement: SAVEPOINT
> pg_psql_temporary_savepoint
> 2007-06-28 22:02:26.045 EDT 2870 LOG: statement: set loca
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > At http://www.postgresql.org/docs/8.2/static/sql-set-role.html, we
> > claim that 'SESSION and LOCAL modifiers act the same as for the
> > regular SET command', bu
Greetings,
At http://www.postgresql.org/docs/8.2/static/sql-set-role.html, we
claim that 'SESSION and LOCAL modifiers act the same as for the
regular SET command', but I don't think that's actually right...
networx=> set role postgres;
SET
networx*=# show role;
role
--
postgr
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > If you're saying we don't currently warn if a revoke leaves the
> > priviledges in-tact for the right and target, I'm not sure you can
> > currently get in a sta
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Hmm. I'm not sure, but that may have been a case where it was generally
> > decided that the spec was somewhat braindead in this fashion (it seems
> > so in my personal view of
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
> Ah, here it is, 12.7 . It says that if role revokes
> another role from a third role, it will only remove the privileges that
> were granted by him, not someone else.
Hmm. I'm not sure, but that may have been a case where it was generally
decided tha
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
> I took a look, and concluded that the only bit of code that uses the
> grantor at all is pg_dumpall.
>
> Does this means we can remove it altogether? In back branches, we would
> take out the pg_dumpall code.
I don't have time right at the moment (le
* Tom Lane ([EMAIL PROTECTED]) wrote:
> dblink connections to your own database are very seldom a good idea;
> there is always a better, more efficient, less deadlock-prone way
> to do it. In this case I'd venture that you want to use a SECURITY
> DEFINER function, and not dblink at all.
The one
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Another approach would be to have PQsetdbLogin build up a conninfo
> > string and pass that into connectOptions1 instead of calling
> > connectOptions1 with an empty string a
* Andrew Klosterman ([EMAIL PROTECTED]) wrote:
> On Tue, 14 Feb 2006, Stephen Frost wrote:
>
> > It's kind of a chicken-and-egg here because the backend decides what
> > authentication mechanism to ask for based off the username (at least in
> > part) through pg_hb
* Andrew Klosterman ([EMAIL PROTECTED]) wrote:
> Alright, I have built a system with the symbols left into the binaries.
[...]
> Again, it is showing a bad malloc in what appears to be some code using
> kerberos. But there's nothing in my setup that I can think of right now
> that should induce a
* Andrew Klosterman ([EMAIL PROTECTED]) wrote:
> > Seems kind of unlikely... What exact (.deb) versions of libpq and
> > Postgres are you using? You originally posted w/ 8.1.0 but perhaps on
> > the client you had something more recent?
>
> Running "aptitude show X" where "X" is the package name
* Andrew Klosterman ([EMAIL PROTECTED]) wrote:
> (gdb) bt
> #0 0x401c3851 in kill () from /lib/libc.so.6
> #1 0x40139dd5 in EF_Abort () from /usr/lib/libefence.so.0
> #2 0x40139823 in memalign () from /usr/lib/libefence.so.0
> #3 0x401399ad in malloc () from /usr/lib/libefence.so.0
> #4 0x4013
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Andrew Klosterman <[EMAIL PROTECTED]> writes:
> > (gdb) bt
> > #0 0x401c3851 in kill () from /lib/libc.so.6
> > #1 0x40139dd5 in EF_Abort () from /usr/lib/libefence.so.0
> > #2 0x40139823 in memalign () from /usr/lib/libefence.so.0
> > #3 0x401399ad in ma
Greetings,
pg_restore doesn't handle errors very well. While attempting to
upgraded a database from 8.0 to 8.1 there were some errors creating
some tables because 8.0 had PostGIS installed (along with some tables)
and 8.1 did not. This also meant that attempts to load the tables
which
* Tom Lane ([EMAIL PROTECTED]) wrote:
> (I'm not sure about Debian's policy, but the RPMs do --disable-rpath for
> unrelated policy reasons, so there shouldn't be any problem with
> relocating an RPM-based installation...)
Debian's policy is to do --disable-rpath also, which I hope Martin is
doing
* Ferindo Middleton ([EMAIL PROTECTED]) wrote:
> CVE-2005-0245 Buffer overflow in gram.y for PostgreSQL 8.0.0 and earlier
> may allow attackers to execute arbitrary code via a large number of
> arguments to a refcursor function (gram.y), which leads to a
> heap-based buffer overflow, a different v
Stephen
> ---
>
> Tom Lane wrote:
> > Stephen Frost <[EMAIL PROTECTED]> writes:
> > > * Tom Lane ([EMAIL PROTECTED]) wrote:
> > >> Arguably we should forbid ALTER INDEX RENAME on an index that belongs to
> > >
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > test=> create table a (
> > test(> b int primary key
> > test(> );
> > NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "a_pkey" for=
>
Greetings,
Not entirely sure if this would be considered a 'bug' but it's
certainly annoying and creates some confusion. Basically, it's like
this:
test=> create table a (
test(> b int primary key
test(> );
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "a_pkey"
* Stephan Szabo ([EMAIL PROTECTED]) wrote:
>
> On Fri, 19 Aug 2005, Bernard wrote:
>
> > My suggestions for improving the COPY command so it can be used by
> > non-superuser users would be as follows:
>
> If you want to do this without switching to a different UNIX user, can't
> you already writ
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > According to the letter of the SQL standard, this behavior is not conforming.
> > But PostgreSQL enforces that you need SELECT privilege for columns that you
> > read for the purpose of performing an UPDATE.
>
Greetings,
Based on some experimentation and reading through the code in:
src/backend/utils/adl/timestamp.c ; it would appear that there's no
error-checking when receiving a binary timestamp. I wouldn't care if
I had figured out the binary timestamp format on the first shot but
apparent
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Reece Hart <[EMAIL PROTECTED]> writes:
> > I have a hunch about why this happens and is rare. The pftype_id_lookup
> > function was created AFTER some of the tables using 'alter table set
> > default ...'. Thus, the function's OID is greater than the OID of t
Greetings,
It appears that if you do the following:
Start the server with pg_hba.conf saying to use 'ident'
Change pg_hba.conf to use 'md5'
Send HUP signal to server
Log in to server (with password), create a database
It seems to revert to using 'ident' again, at least for that databas
75 matches
Mail list logo
