Stephen Frost wrote
> *
> kurt@
> (
> kurt@
> ) 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
>> DELET
Tom Lane-2 wrote
> David Johnston <
> polobo@
> > writes:
>>> Here is a minimal query that demonstrates the problem. In 9.1 it works:
>>>
>>> chris=# select * FROM current_user u join (current_user u cross join
>>> current_user v) x on true;
>>>
>>> On 9.3 it fails:
>>> ERROR: table name "u"
David Johnston writes:
>> Here is a minimal query that demonstrates the problem. In 9.1 it works:
>>
>> chris=# select * FROM current_user u join (current_user u cross join
>> current_user v) x on true;
>>
>> On 9.3 it fails:
>> ERROR: table name "u" specified more than once
This is an intent
A much more simple example courtesy of Chris Travers from the original
-general thread that I suggested be moved to -bugs.
> Here is a minimal query that demonstrates the problem. In 9.1 it works:
>
> chris=# select * FROM current_user u join (current_user u cross join
> current_user v) x on tr
On 2013-08-28 11:50:17 +0200, Valentine Gogichashvili wrote:
> Oh, here is more context about this issue:
> http://www.postgresql.org/message-id/201208171307.16342.and...@2ndquadrant.com
I think that backtrace and explanation pretty much explained what's
going on. Did you try 9.3 to see whether th
The script does not work as expected in the very first case where testdb
does not exist.
Please change the "\set ON_ERROR_STOP" to appear behind the "drop
database $DB;"
WINCOR NIXDORF International GmbH
Sitz der Gesellschaft: Paderborn
Registergericht Paderborn HRB 3507
Geschäftsführer: Eckard He
Hi,
It worked for me: "infocmp -C > /etc/termcap"
Thank you so much!
- Hari
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/BUG-5807-psql-fails-to-launch-with-Cannot-read-termcap-database-using-dumb-terminal-settings-Aborted-tp3321689p5763464.html
Sent from the Postg
Hi Dave,
On Tue, Sep 04, 2012 at 11:45:47PM -0400, Dave Vitek wrote:
> LOG: could not reserve shared memory region (addr=0141) for child
> 0F8C: 487
> LOG: could not fork new process for connection: A blocking operation was
> interrupted by a call to WSACancelBlockingCall
Thank you for the advice. Shortly after submitting this bug I found
Tom Lane's suggestion here
http://www.postgresql.org/message-id/201109082233.p88mxbge026...@wwwmaster.postgresql.org
Once we had the core dump we were quickly able to figure out that the
problem was in one our custom functions.
Is there any status/progress about this bug?
Looks like this bug is not very difficult to fix, but it is really annoying.
--
Вилен Тамбовцев
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www
h...@lemcke.com wrote on 02.05.2013 10:18:
I would like to have the default value replace a given null value if the
column is specified with not null and default.
The SQL specification only requires to set the default value when the column
is omitted on insert or update.
I think this is a flaw
ERR ORR writes:
> My understanding from your replies is that this behavior with *b-tree
> indices* is not considered a bug but rather a case of "works as designed",
> yet still and apart from the solution of my particular problem, the fact
> that in 9.2.4 it is so bad that a simple query sometimes
ERR ORR wrote:
> the fact that in 9.2.4 it is so bad that a simple query sometimes
> does not finish after 10+ minutes with incessant disk activity
> tends to look like a problem to me.
Try running a VACUUM FREEZE ANALYZE; command on the database, under
a database superuser ID. If you upgraded
On 7 April 2013 15:52, Kevin Grittner wrote:
> David Johnston wrote:
>
> > varchar(100)
>
> > The other option to index words via the full-text search capabilities.
>
> Or for columns this short, a similarity search on a trigram index.
>
> http://www.postgresql.org/docs/current/interactive/pgtr
David Johnston wrote:
> varchar(100)
> The other option to index words via the full-text search capabilities.
Or for columns this short, a similarity search on a trigram index.
http://www.postgresql.org/docs/current/interactive/pgtrgm.html
--
Kevin Grittner
EnterpriseDB: http://www.enterpris
r d-3 wrote
> Hi,
>
> this is with 9.2.4_PGDG / FC18 / 64bit upgraded from 9.1.8 via
> dump/restore, settings kept for the most part.
>
> Table has 1.5M records, the varchar(100) field in question has a *
> varchar_ops* and a *varchar_pattern_ops* btree index.
>
> 3 Cases:
>
>- "MYFIELD" li
Heikki Linnakangas writes:
> This bug was introduced by commit
> 8805ff6580621d0daee350826de5211d6bb36ec3, in 9.2.2 (and 9.1.7 and
> 9.0.11), which fixed multiple WAL replay issues with Hot Standby.
Ooops. Thanks for finding that.
regards, tom lane
--
Sent via pgsql
On 27.03.2013 21:04, Heikki Linnakangas wrote:
On 27.03.2013 20:27, Josh Berkus wrote:
Folks,
So I'm a bit surprised that this bug report hasn't gotten a follow-up.
Does this sound like the known 9.2.2 corruption issue, or is it
potentially something else?
It seems like a new issue. At a quic
On 27.03.2013 20:27, Josh Berkus wrote:
Folks,
So I'm a bit surprised that this bug report hasn't gotten a follow-up.
Does this sound like the known 9.2.2 corruption issue, or is it
potentially something else?
It seems like a new issue. At a quick glance, I think there's a bug in
heap_xlog_up
Folks,
So I'm a bit surprised that this bug report hasn't gotten a follow-up.
Does this sound like the known 9.2.2 corruption issue, or is it
potentially something else?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
Ivano Luberti wrote on 06.02.2013 18:17:
Unfortunately the fix doesn't work because it seems the registry key is
protected even form administrator user modifications.
Even if you run regedit from a command prompt started as Administrator?
yes :-(
Probably the security settings for the corre
On Mon, Jan 28, 2013 at 2:37 PM, Alvaro Herrera
wrote:
> Pushed, thanks.
>
> Jeff, Thomas, Jaime: please have a look and let me know what you think.
I've tested it in the 9_2_STABLE branch and found no problems.
Thanks,
Jeff
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To
Pushed, thanks.
Jeff, Thomas, Jaime: please have a look and let me know what you think.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to you
Alvaro Herrera writes:
> I had a look at what it'd take to backpatch. For REASSIGN OWNED, you're
> right that it'd require some refactoring, and it's probably not
> worthwhile (the code is not really all that complicated). However, for
> DROP OWNED the proposed hunks apply fine. Only 8.3 needs
Tom Lane escribió:
> Alvaro Herrera writes:
> > I disagree with this assessment, and propose the attached patch instead.
>
> +1 for this approach in HEAD ...
>
> > This is the patch for the master branch; I have not tried to backpatch
> > it yet. Conflicts are expected due to the refactoring of
Alvaro Herrera writes:
> I disagree with this assessment, and propose the attached patch instead.
+1 for this approach in HEAD ...
> This is the patch for the master branch; I have not tried to backpatch
> it yet. Conflicts are expected due to the refactoring of ALTER commands
> by KaiGai.
...
Alvaro Herrera escribió:
> On the other hand, running REASSIGN OWNED means to reassign ownership of
> objects to some other user. There is no reason this cannot be done to
> shared objects as well as local objects. I note, though, that REASSIGN
> OWNED's documentation mentions "objects in the cu
Jeff Janes escribió:
> Since back-branch releases are coming up, I think fe3b5eb08 and it's
> analogues in all branches should be reverted.
>
> The issue it was intended to solve was not really a bug in the first place,
> and this patch didn't solve it anyway. But it introduced new behavior (into
Jeff Janes escribió:
> Since back-branch releases are coming up, I think fe3b5eb08 and it's
> analogues in all branches should be reverted.
Yes, I have this on my list of things to do before the next minor
release.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Developm
On Sunday, December 9, 2012, Alvaro Herrera wrote:
> Tom Lane wrote:
> >
> > spam_ea...@gmx.net writes:
> > > postgres=# create user testuser with password 'secret';
> > > CREATE ROLE
> > > postgres=# create database testdb owner testuser;
> > > CREATE DATABASE
> > > testdb=> drop owned by testus
smatiz wrote
> The following bug has been logged on the website:
>
> Bug reference: 7784
> Logged by: Santiago Matiz Vasquez
> Email address:
> smatiz@
> PostgreSQL version: 9.2.2
> Operating system: MAC LION 10.7.4
> Description:
>
>
> CREATE OR REPLACE FUNCTION
Hello
2012/12/12 Samrat :
> have a look at it if you find it usefull
> http://ora2pg-samrat.blogspot.in/
it is not a bug
please, use a different mailing list
Regards
Pavel Stehule
>
>
>
>
>
>
> --
> View this message in context:
> http://postgresql.1045698.n5.nabble.com/BUG-7555-fail-to-inst
have a look at it if you find it usefull
http://ora2pg-samrat.blogspot.in/
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/BUG-7555-fail-to-install-ora2pg-through-rhel5-postgresql-repo-depsolv-issues-tp5724474p5736272.html
Sent from the PostgreSQL - bugs mailing list
Tom Lane wrote on 09.12.2012 17:43:
spam_ea...@gmx.net writes:
postgres=# create user testuser with password 'secret';
CREATE ROLE
postgres=# create database testdb owner testuser;
CREATE DATABASE
testdb=> drop owned by testuser;
ERROR: unrecognized object class: 1262
I can reproduce this in
Tom Lane wrote on 09.12.2012 17:43:
spam_ea...@gmx.net writes:
postgres=# create user testuser with password 'secret';
CREATE ROLE
postgres=# create database testdb owner testuser;
CREATE DATABASE
testdb=> drop owned by testuser;
ERROR: unrecognized object class: 1262
I can reproduce this in
On 11/15/2012 02:11 AM, limkimhuot wrote:
> Dear all,
>
> Today is my fourth day I have been trying to install PostgreSQL
> (postgresql-9.2.1-1-windows-x64) in my window 7 x64, yet it fails all the
> time.
>
> I don't know much about VB script or I am very new in VB.
>
> Is it correct if I place co
Dear all,
Today is my fourth day I have been trying to install PostgreSQL
(postgresql-9.2.1-1-windows-x64) in my window 7 x64, yet it fails all the
time.
I don't know much about VB script or I am very new in VB.
Is it correct if I place code of the new environment variable like this:
SYSTEMDRIV
Thanks for the reply, Tom.
On Wed, Nov 7, 2012 at 10:53 AM, Tom Lane wrote:
> t...@cs.ucsd.edu writes:
> > I set the stats_temp_directory='' in my postgresql.conf file, with the
> > expectation that the directory would be under the data directory.
>
> Why would you think that's a good idea? It
OSH, why the format becomes so ugly?!!
Here's the original mail.
Hi, Postgresql,
I set the stats_temp_directory='' in my postgresql.conf file, with the
expectation that the directory would be under the data directory. However,
the server convert the file to “/pgstat.tm
On Wed, Oct 24, 2012 at 10:06 AM, Merlin Moncure wrote:
> I was chasing down a query that ran fine in 8.1 but had an near
> infinite runtime in 9.2. It turned out to be from a bad filter
> estimate that is surprisingly simple to reproduce:
Testing some more it turns out that this isn't really a
On Thu, Sep 13, 2012 at 1:45 PM, Jeff Davis wrote:
> On Thu, 2012-09-13 at 12:39 -0400, Robert Haas wrote:
>> On Wed, Sep 12, 2012 at 7:19 PM, Jeff Davis wrote:
>> > This bug seems particularly troublesome because the right fix would be
>> > to include the relpersistence in the WAL records that n
On Thu, 2012-09-13 at 12:39 -0400, Robert Haas wrote:
> On Wed, Sep 12, 2012 at 7:19 PM, Jeff Davis wrote:
> > This bug seems particularly troublesome because the right fix would be
> > to include the relpersistence in the WAL records that need it. But that
> > can't be backported (right?).
>
> N
On Wed, Sep 12, 2012 at 7:19 PM, Jeff Davis wrote:
> This bug seems particularly troublesome because the right fix would be
> to include the relpersistence in the WAL records that need it. But that
> can't be backported (right?).
No, because if a WAL record was written at all, then by definition
Indeed, this is a nasty bug that leads to data corruption. The following
sequence results in corruption of the visibility map, but I believe it
can be shown to cause problems for a btree or GIN index as well. So it's
recoverable if you do a VACUUM or a reindex.
drop table foo;
create table foo(i i
Excerpts from Noah Misch's message of lun jul 16 11:12:01 -0400 2012:
> As a side question for the list, should we fix this differently in 9.2 to
> avoid forcing an initdb for the next beta? Perhaps have
> ATExecDropConstraint() only respect connoinherit for CONSTRAINT_CHECK?
My answer here was
On Tue, Jul 17, 2012 at 08:59:50AM +, Amit kapila wrote:
> Patch is attached with this mail.
Thanks. This patch is ready for committer.
> +-- Test non-inheritable indices [UNIQUE, EXCLUDE] contraints
> +CREATE TABLE test_constraints (id int, val1 varchar, val2 int, UNIQUE(val1,
> val2));
>
Hello,
The dump file itself is correct. The issue is only with the non-ASCII
object names in pg_dump messages.
The messages text (which is non-ASCII too) displayed consistently with
right encoding (i.e. with OS encoding thanks to libintl/gettext), but
encoding of db object names depends on the
exclus...@gmail.com, 18.07.2012 09:17:
The following bug has been logged on the website:
Bug reference: 6742
Logged by: Alexander LAW
Email address: exclus...@gmail.com
PostgreSQL version: 9.1.4
Operating system: Windows
Description:
When I try to dump database with UTF-8 e
> From: Noah Misch [n...@leadboat.com]
> Sent: Monday, July 16, 2012 8:42 PM
> On Mon, Jul 16, 2012 at 04:49:46PM +0530, Amit Kapila wrote:
>> > Care to prepare a patch with a test case addition?
>> Let me know if above is sufficient or shall I include anything more in
>> patch.
> I can't think
On Tue, Jul 17, 2012 at 12:01 AM, Trey Chadick wrote:
> Excerpts from Dave Page's message of mar jun 05 14:38:54 -0400 2012:
>>
>> On Sun, May 20, 2012 at 7:05 PM, Alvaro Herrera
>> wrote:
>
>> >> I have been installing PostgreSQL 9.1.3.2, and I've noted that 'creating
>> >> database cluster' is
Excerpts from Dave Page's message of mar jun 05 14:38:54 -0400 2012:
>
> On Sun, May 20, 2012 at 7:05 PM, Alvaro Herrera
> wrote:
> >> I have been installing PostgreSQL 9.1.3.2, and I've noted that 'creating
> >> database cluster' is too long. I have been waiting for a half of hour, and
> >> it h
On Mon, Jul 16, 2012 at 12:47:37PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > As a side question for the list, should we fix this differently in 9.2 to
> > avoid forcing an initdb for the next beta?
>
> I'm confused, why would an initdb be involved?
pg_constraint.connoinherit is presently o
Noah Misch writes:
> As a side question for the list, should we fix this differently in 9.2 to
> avoid forcing an initdb for the next beta?
I'm confused, why would an initdb be involved?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
T
On Mon, Jul 16, 2012 at 04:49:46PM +0530, Amit Kapila wrote:
> Code Changes
>
> I will make changes in following functions to ensure that connoinherit
> should be appropriately set(pass the value as true).
> a. index_constraint_create()
> b. ATAddForeignKeyConstraint()
> c. Cre
On Mon, Jul 02, 2012 at 04:16:31PM +0530, Amit Kapila wrote:
> > From: pgsql-bugs-ow...@postgresql.org
> > [mailto:pgsql-bugs-ow...@postgresql.org] On Behalf Of
> > miroslav.s...@fordfrog.com
> > Sent: Saturday, June 30, 2012 4:28 PM
> > test=# create table test_constraints (id int, val1 varchar
[moving to pgsql-novice]
wrote:
This doesn't look like a bug report. When you follow up, please
start a new thread on pgsql-general or pgsql-novice.
> PostgreSQL version: 9.0.0
Please update that to 9.0.8 or 9.1.4.
http://www.postgresql.org/support/versioning/
> I want to run query in
On Wed, May 16, 2012 at 11:53 AM, Tom Lane wrote:
> Alex Hunsaker writes:
>> That being said it seems we failed to take any magic (aka string
>> overloads) that a blessed reference might have. Ill see about
>> submitting a patch for 9.3 (9.2 just entered beta). Anyone have any
>> thoughts on if w
Alex Hunsaker writes:
> That being said it seems we failed to take any magic (aka string
> overloads) that a blessed reference might have. Ill see about
> submitting a patch for 9.3 (9.2 just entered beta). Anyone have any
> thoughts on if we should backpatch a fix?
Right offhand I'd be +1 for ma
On Wed, May 16, 2012 at 10:47 AM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6645
> Logged by: Evna Carroll
> Email address: m...@evancarroll.com
> PostgreSQL version: 9.1.2
> Operating system: Linux
> Description:
>
> This is a cross post f
Upgrade to 9.1.3 and let us know whether that fixes the problem.
Cheers,
David.
On Wed, May 02, 2012 at 09:58:16PM -0700, leo xu wrote:
> pg version is 9.1.2
>
> --
> View this message in context:
> http://postgresql.1045698.n5.nabble.com/select-table-indicate-missing-chunk-number-0-for-toast-va
pg version is 9.1.2
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/select-table-indicate-missing-chunk-number-0-for-toast-value-96635-in-pg-toast-2619-tp5682176p5682273.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.
--
Sent via pgsql-bugs mail
On 06.02.2012 13:24, Heikki Linnakangas wrote:
On 03.02.2012 02:48, Bruce Momjian wrote:
Sorry for the late reply, but Heikki, can you get this Itanium
information into s_lock.h as a comment, particularly the information
about the +Ovolatile=__unordered flag?
Good idea. I came up with the atta
wrote:
> This bug was not in jdbc4 driver: 8.4-701
> But is introduced in jdbc4 driver: 8.4-702
> It is still present in 9.1-901
You might get this in front of a more appropriate group of people if
you post to the pgsql-jdbc list. I'm moving discussion to that list.
> Context:
> * Tomcat 7
On 02/23/2012 12:05 AM, Marti Raudsepp wrote:
> On Wed, Feb 22, 2012 at 23:40, Tom Lane wrote:
>> Marti Raudsepp writes:
>>> According to this model, evaluating SELECT clause fields for *all*
>>> found rows is done in step 5, whereas LIMIT/OFFSET are only applied
>>> later at step 9. So we're alr
On 03.02.2012 02:48, Bruce Momjian wrote:
Sorry for the late reply, but Heikki, can you get this Itanium
information into s_lock.h as a comment, particularly the information
about the +Ovolatile=__unordered flag?
Good idea. I came up with the attached, hope that explains it.
Looking back at th
Sorry for the late reply, but Heikki, can you get this Itanium
information into s_lock.h as a comment, particularly the information
about the +Ovolatile=__unordered flag?
---
On Mon, Dec 19, 2011 at 11:25:06PM +0200, Heikki
On Sat, Jan 14, 2012 at 06:34:25PM +0200, Heikki Linnakangas wrote:
> On 02.01.2012 21:46, Noah Misch wrote:
>> On Fri, Oct 28, 2011 at 11:42:38AM -0400, Noah Misch wrote:
>>> On Fri, Oct 28, 2011 at 09:32:30AM -0400, Robert Haas wrote:
On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane wrote:
> N
On 02.01.2012 21:46, Noah Misch wrote:
On Fri, Oct 28, 2011 at 11:42:38AM -0400, Noah Misch wrote:
On Fri, Oct 28, 2011 at 09:32:30AM -0400, Robert Haas wrote:
On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane wrote:
Noah Misch writes:
Let's look at the behavior of DDL-exposed access constraints fo
2011/12/25 :
> The following bug has been logged on the website:
>
> Bug reference: 6358
> Logged by: Thiago Correia
> Email address: thiagoliveiracorr...@yahoo.com.br
> PostgreSQL version: 9.1.2
> Operating system: Query tool
> Description:
>
> O pgAdmin se conecta ao servido
On Fri, Oct 28, 2011 at 11:42:38AM -0400, Noah Misch wrote:
> On Fri, Oct 28, 2011 at 09:32:30AM -0400, Robert Haas wrote:
> > On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane wrote:
> > > Noah Misch writes:
> > >> Let's look at the behavior of DDL-exposed access constraints for
> > >> precedent. ?We
>
On Mon, Dec 19, 2011 at 11:25:06PM +0200, Heikki Linnakangas wrote:
> I compiled the attached test program on an HP Itanium box, using the
> same flags you get from PostgreSQL's configure on that box. The relevant
> assembler output is:
>
> xchg4 r14 = [r15], r14 //
On 19.12.2011 22:12, Tom Lane wrote:
Noah Misch writes:
On Mon, Dec 19, 2011 at 05:09:11PM +0200, Heikki Linnakangas wrote:
That is not sufficient on platforms with a weak memory model, like Itanium.
Other processors may observe the lock as held after its release, but there's no
correctness
On 19.12.2011 22:03, Noah Misch wrote:
On Mon, Dec 19, 2011 at 05:09:11PM +0200, Heikki Linnakangas wrote:
Actually, I believe our Itanium (and possibly ARM, too) implementation
of S_UNLOCK() is wrong as it is. There is no platform-specific
S_UNLOCK() defined for Itanium, so we're using the gene
Noah Misch writes:
> On Mon, Dec 19, 2011 at 05:09:11PM +0200, Heikki Linnakangas wrote:
>> That is not sufficient on platforms with a weak memory model, like Itanium.
> Other processors may observe the lock as held after its release, but there's
> no
> correctness problem.
How weak is the memo
On Mon, Dec 19, 2011 at 05:09:11PM +0200, Heikki Linnakangas wrote:
> Actually, I believe our Itanium (and possibly ARM, too) implementation
> of S_UNLOCK() is wrong as it is. There is no platform-specific
> S_UNLOCK() defined for Itanium, so we're using the generic
> implementation:
>
> #if !
The following UTF8 character can not be converted to big5, either:
CST ERROR: character 0xe28895 of encoding "UTF8" has no equivalent in
"BIG5"
Again, iconv has no problem with the conversion:
iconv -f utf8 -t big5
Regards
CN
--
http://www.fastmail.fm - Send your email first class
--
Sen
Hello
sorry, this is not bug, it is based on ispell dictionary behave
Regards
Regards
Pavel Stehule
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Fri, Oct 28, 2011 at 09:32:30AM -0400, Robert Haas wrote:
> On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane wrote:
> > Noah Misch writes:
> >> Let's look at the behavior of DDL-exposed access constraints for
> >> precedent. ?We
> >> currently have three paradigms for applying access control to supe
Robert Haas writes:
> On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane wrote:
>> Noah Misch writes:
>>> I think we should merge #3 into #2; nothing about the REPLICATION setting
>>> justifies a distinct paradigm.
>> Yeah, there's much to be said for that. I thought the notion of a
>> privilege that s
On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane wrote:
> Noah Misch writes:
>> Let's look at the behavior of DDL-exposed access constraints for precedent.
>> We
>> currently have three paradigms for applying access control to superusers:
>
>> 1. Settings that affect superusers and regular users ident
Noah Misch writes:
> Let's look at the behavior of DDL-exposed access constraints for precedent.
> We
> currently have three paradigms for applying access control to superusers:
> 1. Settings that affect superusers and regular users identically. These
> include
> ALTER ROLE ... LOGIN | VALID
On Thu, Oct 27, 2011 at 01:45:34PM -0400, Robert Haas wrote:
> On Tue, Oct 25, 2011 at 8:39 AM, Magnus Hagander wrote:
> > On Mon, Oct 24, 2011 at 16:37, Keith Fiske wrote:
> >> On Sat, Oct 22, 2011 at 11:49 AM, Tom Lane wrote:
> >>> "Keith Fiske" writes:
> >>
> If you create a user as a N
I actually figured it out.. forgot to set the encoding type to UNICODE when
I created the db..!
On Mon, Oct 24, 2011 at 11:38 PM, rihad wrote:
> ERROR: unexpected message type 0x58 during COPY from stdin
>>
>
> One possible reason is running out of disk space while making the backup.
> We had t
ERROR: unexpected message type 0x58 during COPY from stdin
One possible reason is running out of disk space while making the backup.
We had the same error while trying to restore 8.3's automated pg_dump into 9.1.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
How about a warning in docs for uncautious DBA's?
2011/10/13 Bruce Momjian
>
> I assume this should _not_ be added as a TODO.
--
Daniel Cristian Cruz
クルズ クリスチアン ダニエル
I assume this should _not_ be added as a TODO.
---
Greg Stark wrote:
> On Tue, Jun 7, 2011 at 3:33 PM, Tom Lane wrote:
> > Greg Stark writes:
> >> On Jun 3, 2011 4:20 PM, "Tom Lane" wrote:
> >>> I'm inclined to write this
You must to do some modifications on User Accounts on your mac:
1. Open User preferences after from Postgres Instalation
2. Rename user PostgresSQL to postgres
3. Enable the administrator permisions.
4. Execute newly the Postgres instaler.
regards,
Alejandro Sánchez
Postgres DBA
--
View this m
Thanks for the help with the adding the user...
When I try to set up a new server with pgAdmin3 I get the message "Postgres
not listening".
What are the next steps to get Postgresql running a database?
We at our firm never expected that postgresql installer would be deprecated
this long
--
I have worked around this by adding the postgres user by hand:
sudo dscl . -create /users/postgres
sudo mkdir -p /usr/local/pgsql/data
sudo chown postgres /usr/local/pgsql/data
sudo dscl . -passwd /users/postgres
su postgres chmod 755 /Library/PostgreSQL/9.0/bin/initdb
su postgres /Library/Postgr
Hi, try with this:
as superuser type: #infocmp -C > /etc/termcap
it worked for my
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/BUG-5807-psql-fails-to-launch-with-Cannot-read-termcap-database-using-dumb-terminal-settings-Aborted-tp3321689p4622693.html
Sent from the Po
Jeff Davis writes:
> On Wed, 2011-07-06 at 13:25 -0400, Tom Lane wrote:
>> Actually, I'd just been working on this myself. I think the cleanest
>> solution will be to get rid of the duplicative logic by making
>> predtest.c use get_op_btree_interpretation(). That will require
>> changing get_op_
On Wed, 2011-07-06 at 13:25 -0400, Tom Lane wrote:
> Actually, I'd just been working on this myself. I think the cleanest
> solution will be to get rid of the duplicative logic by making
> predtest.c use get_op_btree_interpretation(). That will require
> changing get_op_btree_interpretation() so
Jeff Davis writes:
> On Tue, 2011-07-05 at 13:56 -0400, Tom Lane wrote:
>> Yeah, I had been thinking along the same lines. It will require
>> duplicating the search loop, which is a bit annoying, but perhaps that
>> could be factored out as a subroutine.
> Patch attached. The logic in predtest.c
On Tue, 2011-07-05 at 13:56 -0400, Tom Lane wrote:
> Yeah, I had been thinking along the same lines. It will require
> duplicating the search loop, which is a bit annoying, but perhaps that
> could be factored out as a subroutine.
Patch attached. The logic in predtest.c was a little more complex,
Jeff Davis writes:
> I think that ripping out the change to btree_gist is also insufficient;
> we would also have to prevent other extensions from doing the same. That
> means documenting an odd special case, and testing for it when defining
> an opclass. And then we'd probably have to backpatch t
On Sat, 2011-07-02 at 18:38 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > On Sat, 2011-06-18 at 13:20 -0700, Jeff Davis wrote:
> >> Interesting problem... the bug is in get_op_btree_interpretation() which
> >> has code like this:
> >> ...
> >> However, that's a bogus test, because btree_gist put
On Sat, 2011-07-02 at 18:38 -0400, Tom Lane wrote:
> Quite honestly, I think that the bug is that btree_gist took it upon
> itself to invent <> as an indexable operator.
Well, it was following documentation that any extension could
potentially use. I think it's a stretch to call it a bug in anythi
Jeff Davis writes:
> On Sat, 2011-06-18 at 13:20 -0700, Jeff Davis wrote:
>> Interesting problem... the bug is in get_op_btree_interpretation() which
>> has code like this:
>> ...
>> However, that's a bogus test, because btree_gist puts <> into an
>> opfamily. Thus, catlist->n_members == 1 even th
On Fri, Jun 17, 2011 at 08:18:03AM +, Christoph Berg wrote:
> $ diff -c src/backend/po/de.po.orig src/backend/po/de.po
> *** src/backend/po/de.po.orig 2011-06-17 10:06:41.0 +0200
> --- src/backend/po/de.po 2011-06-17 10:06:48.0 +0200
> ***
> *** 12318,12324
On Sat, 2011-06-18 at 13:20 -0700, Jeff Davis wrote:
> Interesting problem... the bug is in get_op_btree_interpretation() which
> has code like this:
>
> /*
>
>* If we can't find any opfamily co
1 - 100 of 469 matches
Mail list logo
