I'm just wondering why postgres_fdw explicitly sets search_path to
pg_catalog. If it does not do that, is there any security risk?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-general mailing list (pgsql-gen
Hi
This is my first question, so, forgive me if it's a newby issue but I
couldn't find an answer googling.
I have a simple composite type
CREATE TYPE info_base AS
(by text,
at timestamp without time zone);
I want to use it as the data type of created, modified and deleted fields.
I alread
Xiaobo Gu wrote:
> We have very large files in size will be created as external tables in
> PostgreSQL via file_fdw, we
> have the following considerations:
> 1. Can file_fdw handle files with size large than the size of RAM in the
> server.
That shouldn't be a problem.
> 2. Will file_fdw scan
Michael Angeletti wrote:
> I'm Michael, and this is my first post here.
>
> I asked this question last night:
>
>
> http://dba.stackexchange.com/questions/45077
>
>
> which details the problem (or not?) I'm having. The gist of it is that
> Postgres is not archiving the
> first WAL segments fo
> My problem is inside triggers: How can I set or get type field values for
> NEW or OLD? (I need it to check users permissions at row level, etc.)
>
> I tried NEW.((created).by), NEW.(created.by), NEW.created.by and nothing
> works...
>
> Could you help me please?
>
> Thanks in advance.
> Martin
I'm moving this discussion to -general.
Dmitriy Igrishin wrote:
>>> While developing a C++ client library for Postgres I felt lack of extra
>>> information in command tags in the CommandComplete (B) message [...]
>>> for the following commands:
>> It seems like bad design to me to keep a list of
Hi All,
Getting an error in version 9.2 "ERROR: missing FROM-clause entry for table"
for some queries. Server parameter "add_missing_from" is removed from version
9 as per release notes, so is there any workaround for fixing this issue? or is
the better way is modifying all these queries ?
T
Dear community
Last week we upgraded our database from 8.4 to 9.1. The upgrade seemed to
go fine and the database seems to have been working fine ever since
(around a week now).
However, today I noticed the output from the pg_upgrade command contained
the following:
| Your installation contains
Arun P.L wrote:
> Getting an error in version 9.2 "ERROR: missing FROM-clause entry for table"
> for some queries. Server
> parameter "add_missing_from" is removed from version 9 as per release notes,
> so is there any
> workaround for fixing this issue? or is the better way is modifying all the
This seems to be fixed in 9.2.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Index-scan-and-bitmap-index-scan-hard-to-understand-how-planner-chooses-tp5760304p5760637.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
--
Sent via pgsql-gene
On Mon, Jun 24, 2013 at 11:13:08AM +, Stuart Ford wrote:
> Dear community
>
> Last week we upgraded our database from 8.4 to 9.1. The upgrade seemed to
> go fine and the database seems to have been working fine ever since
> (around a week now).
>
> However, today I noticed the output from the
On Mon, Jun 24, 2013 at 08:51:46AM -0400, Bruce Momjian wrote:
> On Mon, Jun 24, 2013 at 11:13:08AM +, Stuart Ford wrote:
> > Dear community
> >
> > Last week we upgraded our database from 8.4 to 9.1. The upgrade seemed to
> > go fine and the database seems to have been working fine ever since
Tatsuo Ishii writes:
> I'm just wondering why postgres_fdw explicitly sets search_path to
> pg_catalog. If it does not do that, is there any security risk?
There was a long discussion of that back in February or so, when the
patch was (about to be) committed. In general, if this is causing you
p
We have backed up $PGDATA, but had to re-initialize the slave.
We also have the WALs from the day this happened.
Thanks,
Dan
-Original Message-
From: Lonni J Friedman [mailto:netll...@gmail.com]
Sent: Saturday, June 22, 2013 10:09 PM
To: Dan Kogan
Cc: pgsql-general@postgresql.org
Subject
2013/6/24 Albe Laurenz
> I'm moving this discussion to -general.
>
Okay, lets continue here.
>
> Dmitriy Igrishin wrote:
> >>> While developing a C++ client library for Postgres I felt lack of extra
> >>> information in command tags in the CommandComplete (B) message [...]
> >>> for the followin
Albe Laurenz writes:
> Why do you need to track prepared statements on the client side?
The proposed change would fail to allow that anyway; consider the
possibility of a server-side function doing one or more PREPAREs or
DEALLOCATEs. The command tag would be completely inadequate for
reporting
I could be wrong, but shouldn't the owner of .pgpass be postgres?
On Mon, Jun 24, 2013 at 3:17 PM, Ziggy Skalski wrote:
> On 13-06-21 06:19 PM, Stephen Rasku wrote:
>
>> I am trying to write a script that will create and populate a
>> database. I don't want to enter a password every time so I w
On 13-06-21 06:19 PM, Stephen Rasku wrote:
I am trying to write a script that will create and populate a
database. I don't want to enter a password every time so I want to
use a .pgpass file. It has the correct permissions:
$ ls -l $PGPASSFILE
-rw--- 1 Stephen staff 43 21 Jun
Jashaswee wrote
> i have tried in that way but its showing that the debit column doesn't
> exist
So show us what exactly it is that you tried and maybe someone can tell you
what is wrong.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/postgresql-query-tp575
On 06/24/13 10:24, Rebecca Clarke wrote:
> I could be wrong, but shouldn't the owner of .pgpass be postgres?
The owner of ~/.pgpass is whoever owns ~ (the home directory of that user).
And ~/.pgpass must have permissions 0600 in order for libpq to actually
use it.
Jan
>
>
> On Mon, Jun 24,
On Mon, Jun 24, 2013 at 5:42 AM, boraldomaster wrote:
> This seems to be fixed in 9.2.
>
Which version were you originally seeing it in? I still see that behavior
(or something close to it) in 9.4dev.
It stabilizes after doing a "vacuum analyze" (not just "analyze"), but that
is because it the
On 24/06/2013 14:00, "Bruce Momjian" wrote:
>
>Looking further, here is the command that is executed:
>
> SELECT pg_catalog.lo_create(t.loid)
> FROM (SELECT DISTINCT loid FROM pg_catalog.pg_largeobject) AS t;
>
>If you have created _new_ large objects since the upgrde, the script
>mi
I firstly used 9.1.
After switching to 9.2. - the problem was fixed even without index only
scan.
I added another column to my table so this wasn't index only, but still had
better index behaviour.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Index-scan-and-bitmap-i
On 06/23/2013 10:33 PM, Andreas Kretschmer wrote:
Arun P.L wrote:
Hi,
Is there any settings in postgresql version 9.2 similar to mysql strict mode? I
need to get rid of some type casting errors in the upgrading process from
version 7.4 to 9.2, if this mode is not available I have to modify
i am using postgresql 8.4 version..but this doesn't support the function
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/postgresql-query-tp5759846p5760589.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
--
Sent via pgsql-general mailing l
i have tried in that way but its showing that the debit column doesn't exist
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/postgresql-query-tp5759846p5760593.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
--
Sent via pgsql-general maili
On Mon, Jun 24, 2013 at 03:25:44PM +, Stuart Ford wrote:
> On 24/06/2013 14:00, "Bruce Momjian" wrote:
>
>
> >
> >Looking further, here is the command that is executed:
> >
> > SELECT pg_catalog.lo_create(t.loid)
> > FROM (SELECT DISTINCT loid FROM pg_catalog.pg_largeobject) AS t;
>
2013/6/24 Tom Lane
> Albe Laurenz writes:
> > Why do you need to track prepared statements on the client side?
>
> The proposed change would fail to allow that anyway; consider the
> possibility of a server-side function doing one or more PREPAREs or
> DEALLOCATEs. The command tag would be comp
On 24/06/2013 17:18, "Bruce Momjian" wrote:
>On Mon, Jun 24, 2013 at 03:25:44PM +, Stuart Ford wrote:
>> On 24/06/2013 14:00, "Bruce Momjian" wrote:
>>
>>
>> >
>> >Looking further, here is the command that is executed:
>> >
>> >SELECT pg_catalog.lo_create(t.loid)
>> >FROM (SELECT
On Mon, Jun 24, 2013 at 06:03:40PM +, Stuart Ford wrote:
> On 24/06/2013 17:18, "Bruce Momjian" wrote:
>
>
> >On Mon, Jun 24, 2013 at 03:25:44PM +, Stuart Ford wrote:
> >> On 24/06/2013 14:00, "Bruce Momjian" wrote:
> >>
> >>
> >> >
> >> >Looking further, here is the command that is e
Hello:
Sorry for disturbing again.
I traced source code of PG, and found that:
When the 「create index concurrently 」statement is called,The following
calling relationship is there:
PortalRunMulti--> PortalRunUtility-->Standard_ProcessUtility-->DefineIndex
Here I omit some code of DefineIndex f
However, when I call createdb, it fails:
$ createdb -h 192.168.1.4 -U postgres --no-password JobSearch
createdb: could not connect to database postgres:
fe_sendauth: no
password supplied
Hi,
isn't your --no-password switch preventing this
32 matches
Mail list logo