On Mon, Feb 27, 2012 at 00:54, Tim Uckun timuc...@gmail.com wrote:
The main reason I am not using COPY right now is because postgres will
not allow unprivileged users to issue the COPY from FILENAME. The
The reason for that is a good one -- that would allow these users to
read any file from
On Sun, Feb 26, 2012 at 12:11 PM, Stefan Keller sfkel...@gmail.com wrote:
Thanks to all who responded so far. I got some more insights from Mike
Stonebraker himself in the USENIX talk Scott pointed to before.
I'd like to revise the four points a little bit I enumerated in my
initial question
1. COPY from a text field in a table like this COPY from (select
text_field from table where id =2) as text_data ...
The syntax is a bit different:
CREATE TABLE text_data AS select text_field from table where id=2
Really? Wow, I would have never guessed that. That's awesome.
Thanks.
--
Hi,
2012/2/27 Chris Travers chris.trav...@gmail.com wrote:
1. Buffering Pool
To get rid of I/O bounds Mike proposes in-memory database structures.
...
Now I'm still wondering why PG could'nt realize that probably in
combination with unlogged tables? I don't overview the respective code
but
Hello.
Thank you for your answer.
I used the lt;rawgt; and lt;/rawgt; tags, this is probably the reason
why you couldn't see the messages...
Thank you for the two links.
I read this (in the second one): On Windows, however, UTF-8 encoding can be
used with any locale. yet I still have some
On Mon, Feb 27, 2012 at 3:46 AM, Stefan Keller sfkel...@gmail.com wrote:
Hi,
2012/2/27 Chris Travers chris.trav...@gmail.com wrote:
1. Buffering Pool
To get rid of I/O bounds Mike proposes in-memory database structures.
...
Now I'm still wondering why PG could'nt realize that probably
Andreas wrote:
PostgreSQL 9.1.2 on i686-pc-linux-gnu, compiled by gcc-4.4.real
(Debian 4.4.5-8) 4.4.5, 32-bit
id | integer | not null Vorgabewert nextval('a_id_seq'::regclass)
a | integer | not null
b | integer | not null
Indexe:
a_pkey PRIMARY KEY, btree (id)
a_a_key UNIQUE
Hi all,
I am very new to psql wanted to implement streaming replication on Windows
2008 64 bit Servers installed with PSQL 9.1. Unfortunately the standby
server not even showing anything in the log regarding the replication as
below:
standby log:
2012-02-27 19:30:23 MYT LOG: database system was
Hi, I am just trying to build a duplicate of our database server.
Like the main one, I compiled it from source, ran initdb, created a
superuser, and then proceded to creating a database.
However, db creation is denied to the superuser. Likewise,
if I create the db as user postgres and then change
On Sun, Feb 26, 2012 at 6:16 AM, Jayashankar K B
jayashankar...@lnties.com wrote:
Ok. I did a manual patch and it Postgres 9.1.1 compiled for me without using
the --disable-spinlocks option.
Thanks a lot for the patch. :)
By the way, could you please point me to the explanation on the
On Monday, February 27, 2012 6:21:56 am haman...@t-online.de wrote:
Hi, I am just trying to build a duplicate of our database server.
Like the main one, I compiled it from source, ran initdb, created a
superuser, and then proceded to creating a database.
However, db creation is denied to the
On 02/27/2012 06:19 AM, Chris Travers wrote:
For the sorts of applications I write, the costs of going with something like
VoltDB would easily eclipse the benefits in every single deployment, and
moreover this is not due to questions of the maturity of the technology but
rather of
On Monday, February 27, 2012 5:34:12 am chinnaobi wrote:
Hi all,
I am very new to psql wanted to implement streaming replication on Windows
2008 64 bit Servers installed with PSQL 9.1. Unfortunately the standby
server not even showing anything in the log regarding the replication as
below:
On Monday, February 27, 2012 3:55:43 am Léa Massiot wrote:
Hello.
Thank you for your answer.
Thank you for the two links.
I read this (in the second one): On Windows, however, UTF-8 encoding can
be used with any locale. yet I still have some questions...
Question 1
Focusing on the
On Mon, Feb 27, 2012 at 04:19:10AM -0800, Chris Travers wrote:
Strangely, he doesn't consider PostgreSQL to be an elephant.
The last presentation I saw from Volt guys explicitly mentioned
Postgres as one of the elephants.
Also, if you read their literature carefully, you discover that the
Albe Laurenz laurenz.a...@wien.gv.at writes:
Andreas wrote:
Both select where shown as 'Index Scan'. But the second select is not
a real index scan,
A full scan of the index is also an index scan.
Yes. In particular it won't visit the heap for rows that don't satisfy
the index condition.
On: Fri, 24 Feb 2012 07:33:01 -0800, Adrian Klaver
adrian.kla...@gmail.com wrote:
On Friday, February 24, 2012 7:16:47 am James B. Byrne
wrote:
CentOS-5.7
RoR-3.1.1
Pg-9.1
I am trying to run a test suite against Pg-9.1 for a
RoR-3.1.1 based application. When I run the test DB
setup task
Hi,
I'm trying to understand the clean way to determine whether the
current role has UPDATE (or SELECT or DELETE or UPDATE) privileges on
a specific table (or column). If I can do it in a way that is portable
across different DBMSs, even better :)
I went through several iterations, 'CUR_USER'
Hello,
It apperas that I have some entries in pg_class that have relnamespace not appearing in
pg_namespace. So pg_dump fails with pg_dump: schema with OID 52072764 does not exist, I guess.
Like the schema in question was dropped, but not cascading to all its members?
How to get rid of or
On Mon, Feb 27, 2012 at 11:00, Lionel Elie Mamane lio...@mamane.lu wrote:
Hi,
I'm trying to understand the clean way to determine whether the
current role has UPDATE (or SELECT or DELETE or UPDATE) privileges on
a specific table (or column). If I can do it in a way that is portable
across
On 02/27/2012 08:51 AM, James B. Byrne wrote:
The options seem to be run the script as the owner of the
plpgsql EXTENSION or do not include the comment.
How does one instruct pg_dump not to include the COMMENT
for the plpgsql extension?
I am not sure pg_dump is including the COMMENT. From
On 2/27/12 9:51 AM, James B. Byrne wrote:
The options seem to be run the script as the owner of the
plpgsql EXTENSION or do not include the comment.
How does one instruct pg_dump not to include the COMMENT
for the plpgsql extension?
The case in question is the automated creation of an sql
On 02/27/2012 08:51 AM, James B. Byrne wrote:
The options seem to be run the script as the owner of the
plpgsql EXTENSION or do not include the comment.
How does one instruct pg_dump not to include the COMMENT
for the plpgsql extension?
Did some testing. So when you use 9.1 pg_dump to dump
Autovacuum is complaining about an orphaned temp table. I believe this was
created just before a recent PostgreSQL crash. Is there something I should
do to clean it up?
2012-02-27 13:05:35 CST [18400]: [1-1] @ LOG: 0: autovacuum: found
orphan temp table pg_temp_7.tmp_order_ids in database
On Mon, February 27, 2012 13:54, Adrian Klaver wrote:
On 02/27/2012 08:51 AM, James B. Byrne wrote:
The options seem to be run the script as the owner of
the
plpgsql EXTENSION or do not include the comment.
How does one instruct pg_dump not to include the COMMENT
for the plpgsql
On Mon, February 27, 2012 14:30, Adrian Klaver wrote:
On 02/27/2012 08:51 AM, James B. Byrne wrote:
The options seem to be run the script as the owner of
the
plpgsql EXTENSION or do not include the comment.
How does one instruct pg_dump not to include the COMMENT
for the plpgsql
Hi Scott
2012/2/26 Scott Marlowe scott.marl...@gmail.com:
On Sun, Feb 26, 2012 at 1:11 PM, Stefan Keller sfkel...@gmail.com wrote:
So to me the bottom line is, that PG already has reduced overhead at
least for issue #2 and perhaps for #4.
Remain issues of in-memory optimization (#2) and
James B. Byrne byrn...@harte-lyne.ca writes:
1. Can the comments be suppressed?
No.
2. Why is this an error in the first place?
Because you're not running the script as superuser.
regards, tom lane
--
Sent via pgsql-general mailing list
Mike Blackwell mike.blackw...@rrd.com writes:
Autovacuum is complaining about an orphaned temp table. I believe this was
created just before a recent PostgreSQL crash. Is there something I should
do to clean it up?
You could drop that table manually if you're so inclined (probably need
to be
On Monday, February 27, 2012 11:44:09 am James B. Byrne wrote:
3. Why are these dependencies not owned by the database
owner to begin with? Surely this code:
CREATE EXTENSION plpgsql
SCHEMA pg_catalog
VERSION 1.0;
ALTER EXTENSION plpgsql
OWNER TO postgres;
could just as
Ireneusz Pluta ipl...@wp.pl writes:
It apperas that I have some entries in pg_class that have relnamespace not
appearing in
pg_namespace. So pg_dump fails with pg_dump: schema with OID 52072764 does
not exist, I guess.
That's a bit disturbing --- do you have any idea what triggered that?
On Mon, February 27, 2012 15:44, Tom Lane wrote:
James B. Byrne byrn...@harte-lyne.ca writes:
1. Can the comments be suppressed?
No.
2. Why is this an error in the first place?
Because you're not running the script as superuser.
regards, tom lane
Why is it
Here is an interesting situation. In PGAdmin3-1.14.2 when
I display the extension properties then I see this:
CREATE EXTENSION plpgsql
SCHEMA pg_catalog
VERSION 1.0;
ALTER EXTENSION plpgsql
OWNER TO postgres;
However, if I do this exact statement in the SQL pane
while connected as the
Obviously, I am missing something important here. The
database in question is created thusly:
CREATE DATABASE test
WITH OWNER = devl
ENCODING = 'UTF8'
TABLESPACE = pg_default
LC_COLLATE = 'en_US.UTF-8'
LC_CTYPE = 'en_US.UTF-8'
CONNECTION LIMIT = -1;
The
On Monday, February 27, 2012 1:23:22 pm James B. Byrne wrote:
Obviously, I am missing something important here. The
database in question is created thusly:
CREATE DATABASE test
WITH OWNER = devl
ENCODING = 'UTF8'
TABLESPACE = pg_default
LC_COLLATE = 'en_US.UTF-8'
On Mon, February 27, 2012 16:37, Adrian Klaver wrote:
On Monday, February 27, 2012 1:23:22 pm James B. Byrne
wrote:
Obviously, I am missing something important here. The
database in question is created thusly:
CREATE DATABASE test
WITH OWNER = devl
ENCODING = 'UTF8'
W dniu 2012-02-27 21:59, Tom Lane pisze:
Ireneusz Plutai...@wp.pl writes:
It apperas that I have some entries in pg_class that have relnamespace not
appearing in
pg_namespace. So pg_dump fails with pg_dump: schema with OID 52072764 does not
exist, I guess.
That's a bit disturbing --- do you
I have installed 64-bit Postgres 9.1 on Windows 7 Enterprise (64-bit). I
also have 64-bit Python 2.7.2 and 2.6 installed. I am interested in using
PL\Python but am having trouble installing it.
I read the intro documentation on PL/Python with respect to the plpython2
vs 3 issues. My installation
On Monday, February 27, 2012 1:45:13 pm James B. Byrne wrote:
On Mon, February 27, 2012 16:37, Adrian Klaver wrote:
It is likely that I created the database initially in
PGAdmin3 while connected to the server as the postgres
user. Why would creating a database with a specified
owner result
Ireneusz Pluta ipl...@wp.pl writes:
W dniu 2012-02-27 21:59, Tom Lane pisze:
I'd do the latter I think. Keep in mind that there are probably also
entries in pg_depend linking the tables to the schemas. If your goal is
only to get to a clean dumpable state and then dump and reload the
W dniu 2012-02-27 23:57, Tom Lane pisze:
One possible theory for cascaded drops to fail like that is that the indexes on pg_depend are
corrupt, so you might want to consider REINDEXing that catalog, just in case.
so before reindexing it would be worth veryfing the theory and check indexes for
Ireneusz Pluta ipl...@wp.pl writes:
W dniu 2012-02-27 23:57, Tom Lane pisze:
One possible theory for cascaded drops to fail like that is that the indexes
on pg_depend are
corrupt, so you might want to consider REINDEXing that catalog, just in case.
so before reindexing it would be worth
Hi all,
I have a relation where a tuple typically undergoes a lifecycle
something like:
1) Created
2) Updated maybe thousands of times (no updates to indexed columns though)
3) Rarely or never modified again
The following query takes about 100 minutes (3 seconds per tuple):
SELECT count(id)
I'm seeing GMTERROR: canceling autovacuum task lines in my logs.
2012-02-27 23:53:28 GMTLOG: checkpoint starting: time
2012-02-27 23:53:31 GMTERROR: canceling autovacuum task
2012-02-27 23:53:31 GMTCONTEXT: automatic vacuum of table
somedb.pg_toast.pg_toast_33254
2012-02-27 23:53:32
I have observed that a commit on a replication master hangs if there are no
slaves to communicate with if synchronous replication is enabled. I believe I
have seen a posting that this behavior is deliberate.
In my environment I'd prefer to have the master continue processing
transactions if
I'd like to get some clarification around an architectural point about
recovery. I see that it is normal to see unexpected pageaddr errors during
recovery because of the way Postgres overwrites old log files, and thus this is
taken to be a normal termination condition, i.e. the end of the log
On Monday, February 27, 2012 4:36:26 pm Jameison Martin wrote:
I have observed that a commit on a replication master hangs if there are no
slaves to communicate with if synchronous replication is enabled. I
believe I have seen a posting that this behavior is deliberate.
In my environment I'd
On Mon, February 27, 2012 17:16, Adrian Klaver wrote:
From psql do \l and see who actually owns the database.
List of databases
Name|Owner | Encoding |
---+--+--+--
devl
I'm running Postgresql 9.0.3 on a Windows 7 box. There is one large database
that gets inserted to thousands of times a day every day. The problem is the
Handle count on the Windows System process of the server, image name
c:\windows\system32\ntoskrnl.exe, accumulates over time and the handles
On 02/27/12 6:34 PM, Adam Bruss wrote:
I’m running Postgresql 9.0.3 on a Windows 7 box. There is one large
database that gets inserted to thousands of times a day every day. The
problem is the Handle count on the Windows System process of the
server, image name
Hi,
On 28 February 2012 11:53, Jameison Martin jameis...@yahoo.com wrote:
I'm seeing GMTERROR: canceling autovacuum task lines in my logs.
That's *should* be fine. autovacuum daemon is smart enough to cancel
it self when other query needs access to the table. The affected table
will be
Hi Adrian,
Thanks for the reply streaming is working after placing the recovery.conf in
standby data folder.
I add an extra configuration in the recovery.conf :
archive_cleanup_command='pg_archivecleanup 10.1.18.16\\DB_Stream_Share\\
%r'
The standby server log file says error as below :
On 02/27/2012 06:55 PM, Dave Vitek wrote:
Hi all,
I have a relation where a tuple typically undergoes a lifecycle something like:
1) Created
2) Updated maybe thousands of times (no updates to indexed columns though)
3) Rarely or never modified again
The following query takes about 100 minutes
On Mon, Feb 27, 2012 at 12:11:23PM -0600, Mike Blackwell wrote:
On Mon, Feb 27, 2012 at 11:00, Lionel Elie Mamane lio...@mamane.lu wrote:
I'm trying to understand the clean way to determine whether the
current role has UPDATE (or SELECT or DELETE or UPDATE) privileges on
a specific table (or
Streaming replication in the standby has successfully started (windows 2008
server) but, the configuration in the recovery.conf :
archive_cleanup_command='pg_archivecleanup 10.1.18.16\\DB_Stream_Share\\
%r'
standby server log file says error as below :
2012-02-28 10:59:01 MYT FATAL: the
55 matches
Mail list logo
