2012/3/10 Tom Lane :
> Peter Eisentraut writes:
>> But then I would have to map all language-specific error reports to some
>> SQL error scheme, which is not only cumbersome but pretty useless. For
>> example, a Python programmer will be familiar with the typical output
>> that pylint produces an
On Fri, Mar 9, 2012 at 8:15 PM, Tom Lane wrote:
> Antonin Houska writes:
>> For example:
>
>> SELECT *
>> FROM a, b, func(a.i, b.j) as c, d
>> WHERE a.i=b.j and b.j = d.k and c>1
>
>> may become
>
>> SELECT *
>> FROM a, b, as c, d
>> WHERE a.i=b.j and b.j = d.k and c>1
>
>> where is
>
>> SELE
(2012/03/06 23:47), Albe Laurenz wrote:
> Shigeru Hanada wrote:
>> Connection should be closed only when the trigger is a
>> top level transaction and it's aborting, but isTopLevel flag was not
>> checked. I fixed the bug and added regression tests for such cases.
>
> I wondered ab
(2012/03/09 1:18), Tom Lane wrote:
> I've been looking at this patch a little bit over the past day or so.
> I'm pretty unhappy with deparse.c --- it seems like a real kluge,
> inefficient and full of corner-case bugs. After some thought I believe
> that you're ultimately going to have to abandon
I've not read whole of the patch yet, but I have basic questions.
1) IIUC, GetForeignRelSize should set baserel->rows to the number of
rows the ForeignScan node returns to upper node, but not the number
of rows FDW returns to core executor, right?
BTW, once Fujita-san's ANALYZE support patch is m
> --text-search-config option is missing in document too. Also pg_ctl's
> long name options, such as --silent, are missing in document.
Thanks for the info. I will add them as well unless someone beats me.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:
libpq has functions for escaping values in SQL commands
(PQescapeStringConn, PQescapeByteaConn, and the new PQescapeLiteral),
and it supports parameterizing queries with PQexecParams. But it does
not (to my knowledge) have functions for escaping values for COPY
FROM.
COPY FROM is useful for inser
2012/3/10 Tatsuo Ishii :
> --no-locale option of initdb command is missing in the manual. The
> option is in the code and even showed in the help message:
--text-search-config option is missing in document too. Also pg_ctl's
long name options, such as --silent, are missing in document.
--
Shige
Antonin Houska writes:
> For example:
> SELECT *
> FROM a, b, func(a.i, b.j) as c, d
> WHERE a.i=b.j and b.j = d.k and c>1
> may become
> SELECT *
> FROM a, b, as c, d
> WHERE a.i=b.j and b.j = d.k and c>1
> where is
> SELECT func(a.i, b.j)
> FROM a,b
> WHERE a.i=b.j
Um ... how do you ge
Peter Eisentraut writes:
> But then I would have to map all language-specific error reports to some
> SQL error scheme, which is not only cumbersome but pretty useless. For
> example, a Python programmer will be familiar with the typical output
> that pylint produces and how to fix it. If we hid
Andrew Dunstan writes:
> Buildfarm member mussel (OS X 10.7.3, llvm-gcc 4.2.1, x86_64)seems to be
> getting consistent warnings when running the pgcrypto regression tests,
> that look like this:
> WARNING: detected write past chunk end in ExprContext 0x7fec2b11eb58
> Does anyone have an id
Hackers,
The documentation for pg_locks says that, for BIGINT advisory locks:
> A bigint key is displayed with its high-order half in the classid column, its
> low-order half in the objid column
I was in need of knowing what the bigint is that is waiting on a lock, and
Andrew Dunstan was kind
Hello,
in the related discussions mentioned on TODO list
http://archives.postgresql.org/pgsql-hackers/2009-09/msg00292.php
http://archives.postgresql.org/pgsql-hackers/2009-10/msg00991.php
(The 1st is rather on SQL, I didn't focuss on it yet.)
the implementation is discussed from optimizer/execu
Marti Raudsepp writes:
> [ cacheexpr-v8.patch ]
A few comments:
* I believe the unconditional datumCopy call in ExecEvalCacheExpr will
dump core if the value is null and the type is pass-by-reference.
Beyond just skipping it, it seems like you could skip the type
properties lookup as well if the
Hi,
--no-locale option of initdb command is missing in the manual. The
option is in the code and even showed in the help message:
$ initdb --help
initdb initializes a PostgreSQL database cluster.
Usage:
initdb [OPTION]... [DATADIR]
Options:
-A, --auth=METHOD default authentication m
On fre, 2012-03-09 at 15:33 -0500, Tom Lane wrote:
> What I've wanted from this patch from the beginning was a
> common framework. That is, I want to be able to write something like
>
> SELECT check_function(oid) FROM pg_proc WHERE proowner = 'tgl'
>
> and have it "just work" for all languages
On fre, 2012-03-09 at 21:54 +0100, Pavel Stehule wrote:
> no, you can check any PL language - and output result is based on SQL
> Errors, so it should be enough for all PL too.
But then I would have to map all language-specific error reports to some
SQL error scheme, which is not only cumbersome b
Oleg Bartunov writes:
> attached patch introduces NULLs indexing for SP-GiST. With this patch
> Sp-GiST supports IS NULL, IS NOT NULL clauses, as well as full index scan.
I've looked at this patch a bit. I share Jaime's extreme discomfort
with re-using GIN code to handle some pages of an SPGist
On 9 March 2012 21:38, Dimitri Fontaine wrote:
> Hi,
>
> Please find attached v15 of the patch, addressing all known issues apart
> from the trigger function argument passing style. Expect a new patch
> with that taken care of early next week.
>
> (The github branch too, should you be using that)
On Fri, Mar 09, 2012 at 05:28:20PM -0500, Andrew Dunstan wrote:
> Buildfarm member mussel (OS X 10.7.3, llvm-gcc 4.2.1, x86_64)seems
> to be getting consistent warnings when running the pgcrypto
> regression tests, that look like this:
>
>WARNING: detected write past chunk end in ExprContext 0
On Fri, Mar 9, 2012 at 5:31 PM, Pavel Stehule wrote:
> ok - it has sense, but it has sense only with some "smart" statements
> (like CHECK). Without these statements I have to directly call checker
> function and then concept of generalised checkers has not sense.
I agree.
--
Robert Haas
Enter
On Wed, Feb 22, 2012 at 2:11 PM, Peter Geoghegan wrote:
> One beef that I have with the variable name m_write_ms is that "ms"
> could equally well refer to microseconds or milliseconds, and these
> mistakes are very common.
I would expect ms to mean milliseconds and us to mean microseconds.
> De
2012/3/9 Robert Haas :
> On Fri, Mar 9, 2012 at 5:09 PM, Pavel Stehule wrote:
>>> Well, that just means that it'd be a good idea for that function to be
>>> supplied by the same shared library that supplies the plpgsql execution
>>> functions. There wouldn't need to be any connection that the cor
Buildfarm member mussel (OS X 10.7.3, llvm-gcc 4.2.1, x86_64)seems to be
getting consistent warnings when running the pgcrypto regression tests,
that look like this:
WARNING: detected write past chunk end in ExprContext 0x7fec2b11eb58
Does anyone have an idea why that might be?
cheers
and
On Fri, Mar 9, 2012 at 5:09 PM, Pavel Stehule wrote:
>> Well, that just means that it'd be a good idea for that function to be
>> supplied by the same shared library that supplies the plpgsql execution
>> functions. There wouldn't need to be any connection that the core
>> system particularly und
2012/3/9 Tom Lane :
> Pavel Stehule writes:
>> 2012/3/9 Peter Eisentraut :
>>> What would be the qualifications for being an internal or an external
>>> checker? Why couldn't your plpgsql checker be an external checker?
>
>> plpgsql checker cannot be external checker, because it reuse 70% of
>> p
On Friday, March 09, 2012 10:13:15 PM Robert Haas wrote:
> If people are
> tired of working on the CommitFest, they're not going to get
> reinvigorated just because we let it go on for another month.
On that line: From Sundway onwards I do have time again to do reviewing. I am
not anybody is doing
On Fri, Mar 9, 2012 at 3:33 PM, Tom Lane wrote:
> If we're going to go the ad-hoc route, there seems little reason to be
> considering a core patch at all. Freestanding checkers could just as
> well be independent projects.
I completely agree. I think there is little reason to be considering
a
On Fri, Mar 9, 2012 at 3:40 PM, Dimitri Fontaine wrote:
> I share your view here, and in fact the code for the patch has been
> updated in only two ways since 1/15: adding support for new commands and
> reacting to review (refactoring, cleaning, features removal, fix the
> glitch). That's the reas
Pavel Stehule writes:
> 2012/3/9 Peter Eisentraut :
>> What would be the qualifications for being an internal or an external
>> checker? Why couldn't your plpgsql checker be an external checker?
> plpgsql checker cannot be external checker, because it reuse 70% of
> plpgsql environment, - parser
2012/3/9 Peter Eisentraut :
> On tor, 2012-03-08 at 23:15 +0100, Pavel Stehule wrote:
>> But you propose some little bit different than is current plpgsql
>> checker and current design.
>
> Is it? Why? It looks like exactly the same thing, except that the
> interfaces you propose are tightly gear
On Tue, Mar 6, 2012 at 9:14 AM, Kohei KaiGai wrote:
> [ new patch ]
Are we absolutely certain that we want the semantics of
sepgsql_setcon() to be transactional? Because if we made them
non-transactional, this would be a whole lot simpler, and it would
still meet the originally proposed use case
Robert Haas writes:
> Just to be clear, it wasn't my intention to hold command triggers
> specifically to a different standard - but I do differentiate between
> small patches and big patches. Small patches that someone can get
> committed with an hour's worth of review can be treated a little mo
Robert Haas writes:
> On Fri, Mar 9, 2012 at 3:15 PM, Peter Eisentraut wrote:
>> Well, the more I think about it and look at this patch, the more I think
>> that this would be complete overkill and possibly quite useless for my
>> purposes. I can implement the entire essence of this framework (e
Robert Haas writes:
> There's been very little patch review going on, with a couple
> of notable exceptions like Thom and Noah, and not a lot of new patch
> versions from patch authors either, again with a few exceptions, like
> Dimitri. So it's not terribly surprising that progress is very slow.
On Fri, Mar 9, 2012 at 3:15 PM, Peter Eisentraut wrote:
> On tor, 2012-03-08 at 19:19 -0500, Robert Haas wrote:
>> On Thu, Mar 8, 2012 at 4:54 PM, Peter Eisentraut wrote:
>> > * It's not terribly important to me to be able to run checkers
>> > separately. If I wanted to do that, I wo
On Fri, Mar 9, 2012 at 2:41 PM, Robert Haas wrote:
> On Sat, Feb 4, 2012 at 10:54 AM, Kohei KaiGai wrote:
>> OK, I modified the patch according to your suggestions.
>>
>> object_access_hook was extended to take an argument of void * pointer,
>> and InvokeObjectAccessHook was also allows to delive
On tor, 2012-03-08 at 19:19 -0500, Robert Haas wrote:
> On Thu, Mar 8, 2012 at 4:54 PM, Peter Eisentraut wrote:
> > * It's not terribly important to me to be able to run checkers
> >separately. If I wanted to do that, I would just disable or
> >remove the checker.
>
> Does t
On Fri, Mar 9, 2012 at 3:00 PM, Simon Riggs wrote:
> On Thu, Mar 8, 2012 at 1:20 PM, Robert Haas wrote:
>
>> Are we still considering trying to do this for 9.2? Seems it's been
>> over a month without a new patch, and it's not entirely clear that we
>> know what the design should be.
>
> It's im
On Fri, Mar 9, 2012 at 3:04 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 9, 2012 at 2:34 PM, Robert Haas wrote:
>>> On Fri, Mar 9, 2012 at 2:26 PM, Tom Lane wrote:
Hm. I think "thousands" is an overestimate, but yeah the logic could be
greatly simplified. However, I'm no
On Fri, Mar 9, 2012 at 2:59 PM, Simon Riggs wrote:
> On Fri, Mar 9, 2012 at 3:46 AM, Robert Haas wrote:
>> On Wed, Mar 7, 2012 at 5:41 PM, Simon Riggs wrote:
Case #2 is certainly a problem for FrozenXID as well, because anything
that's marked with FrozenXID is going to look visible to
On tor, 2012-03-08 at 23:15 +0100, Pavel Stehule wrote:
> But you propose some little bit different than is current plpgsql
> checker and current design.
Is it? Why? It looks like exactly the same thing, except that the
interfaces you propose are tightly geared toward checking SQL-like
languages
On 2012-03-06 15:14, Kohei KaiGai wrote:
In case of sepgsql_setcon() being invoked with null argument
to reset security label of the client, but not committed yet,
the last item of the client_label_pending has null label.
(It performs as a mark of a security label being reset.)
Yes, I see that no
On Fri, Mar 9, 2012 at 2:47 PM, Tom Lane wrote:
> This is a fair position, but I think it's a bit unfair to be applying
> such pressure to just the command-triggers patch and not all the other
> open issues. Hence, $SUBJECT: is it time to start forcing this
> commitfest to a conclusion, and if so
Robert Haas writes:
> On Fri, Mar 9, 2012 at 2:34 PM, Robert Haas wrote:
>> On Fri, Mar 9, 2012 at 2:26 PM, Tom Lane wrote:
>>> Hm. I think "thousands" is an overestimate, but yeah the logic could be
>>> greatly simplified. However, I'm not sure we could avoid breaking the
>>> existing naming
On Thu, Mar 8, 2012 at 1:20 PM, Robert Haas wrote:
> Are we still considering trying to do this for 9.2? Seems it's been
> over a month without a new patch, and it's not entirely clear that we
> know what the design should be.
It's important, but not ready.
--
Simon Riggs h
On Fri, Mar 9, 2012 at 3:46 AM, Robert Haas wrote:
> On Wed, Mar 7, 2012 at 5:41 PM, Simon Riggs wrote:
>>> Case #2 is certainly a problem for FrozenXID as well, because anything
>>> that's marked with FrozenXID is going to look visible to everybody,
>>> including our older snapshots. And I gath
Robert Haas writes:
> Well, if you get to the point where you're done churning the code in
> the next week or so, I'm willing to do one or two more rounds of
> serious review, but if that doesn't get us there then I think we need
> to give up. The energy you've put into this is commendable, but w
On Sat, Feb 4, 2012 at 10:54 AM, Kohei KaiGai wrote:
> OK, I modified the patch according to your suggestions.
>
> object_access_hook was extended to take an argument of void * pointer,
> and InvokeObjectAccessHook was also allows to deliver it.
Sorry for the long radio silence on this patch. Th
On Fri, Mar 9, 2012 at 2:34 PM, Robert Haas wrote:
> On Fri, Mar 9, 2012 at 2:26 PM, Tom Lane wrote:
>> Peter Eisentraut writes:
Yeah, the use of XLogFile to mean something other than, well a file in
the xlog, is greatly annoying.. I guess we could change it, but it
goes pretty de
Tom Lane wrote:
> Peter Eisentraut writes:
>> The whole thing was built around the lack of 64 bit integers. If
>> we bit the bullet and changed the whole thing to be just a single
>> 64-bit counter, we could probably delete thousands of lines of
>> code.
>
> Hm. I think "thousands" is an ove
On Fri, Mar 9, 2012 at 2:14 PM, Tom Lane wrote:
> I'm inclined to only fix this in HEAD.
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
On Fri, Mar 9, 2012 at 2:26 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>>> Yeah, the use of XLogFile to mean something other than, well a file in
>>> the xlog, is greatly annoying.. I guess we could change it, but it
>>> goes pretty deep in the system so it's not a small change...
>
>> The wh
Peter Eisentraut writes:
>> Yeah, the use of XLogFile to mean something other than, well a file in
>> the xlog, is greatly annoying.. I guess we could change it, but it
>> goes pretty deep in the system so it's not a small change...
> The whole thing was built around the lack of 64 bit integers.
On fre, 2012-03-09 at 18:13 +0100, Magnus Hagander wrote:
> > and confusing XLogFileSize with XLogSegSize. Not the best choice of
> > names.
>
> Yeah, the use of XLogFile to mean something other than, well a file in
> the xlog, is greatly annoying.. I guess we could change it, but it
> goes prett
On Fri, Mar 9, 2012 at 12:51 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> I think we had better look seriously at postponing this patch to 9.3.
>
> I understand why you're drawing that conclusion, but I don't think
> that's the best we can do here, by a long shot.
Well, if you get to the
I looked into the misbehavior reported here:
http://archives.postgresql.org/pgsql-bugs/2012-03/msg00068.php
The reason the ALTER TABLE fails to fail is $SUBJECT: it goes looking
for pg_depend entries showing that rewrite rules depend on the column to
be altered, but there isn't one. This is basic
On 03/09/2012 01:40 PM, Robert Haas wrote:
On Fri, Mar 9, 2012 at 12:02 PM, David E. Wheeler wrote:
On Mar 9, 2012, at 7:55 AM, Merlin Moncure wrote:
100% agree (having re-read the thread and Alvaro's idea having sunk
in). Being able to set up daemon processes side by side with the
postmas
On Fri, Mar 9, 2012 at 12:02 PM, David E. Wheeler wrote:
> On Mar 9, 2012, at 7:55 AM, Merlin Moncure wrote:
>> 100% agree (having re-read the thread and Alvaro's idea having sunk
>> in). Being able to set up daemon processes side by side with the
>> postmaster would fit the bill nicely. It's p
On Fri, Mar 9, 2012 at 12:38 PM, Magnus Hagander wrote:
> On Fri, Mar 9, 2012 at 18:18, Tom Lane wrote:
>> Magnus Hagander writes:
>>> On Fri, Mar 9, 2012 at 15:37, Tom Lane wrote:
Why would it be useful to use pg_size_pretty on xlog locations?
-1 because of the large expense of bigin
Hello Alvaro
here is new version - merged Peter's doc changes. I created a new
header "functioncmds.h". This file contains lines related to checker
only. I didn't want to unclean this patch by header files
reorganization.
Regards
Pavel
2012/3/8 Pavel Stehule :
> Hello
>
> there are other vers
Robert Haas writes:
> I think we had better look seriously at postponing this patch to 9.3.
I understand why you're drawing that conclusion, but I don't think
that's the best we can do here, by a long shot.
> Your reviewing is obviously moving things forward rapidly, but I think
> it's unrealist
On Fri, Mar 9, 2012 at 18:18, Tom Lane wrote:
> Magnus Hagander writes:
>> On Fri, Mar 9, 2012 at 15:37, Tom Lane wrote:
>>> Why would it be useful to use pg_size_pretty on xlog locations?
>>> -1 because of the large expense of bigint->numeric->whatever conversion
>>> that would be added to exis
Robert Haas writes:
> I'm not convinced. Right now, it's fairly useless - all the triggers
> could possibly do is throw an error, and an error is going to get
> thrown anyway, so it's only a question of which error message the user
> will see. But we discussed before the idea of adding a capabil
Magnus Hagander writes:
> On Fri, Mar 9, 2012 at 15:37, Tom Lane wrote:
>> Why would it be useful to use pg_size_pretty on xlog locations?
>> -1 because of the large expense of bigint->numeric->whatever conversion
>> that would be added to existing uses.
> Given the expense, perhaps we need to d
On Fri, Mar 9, 2012 at 15:37, Tom Lane wrote:
> Fujii Masao writes:
>> Euler proposed one more patch upthread, which replaces pg_size_pretty(bigint)
>> with pg_size_pretty(numeric) so that pg_size_pretty(pg_xlog_location_diff())
>> succeeds. It's also worth committing this patch?
>
> Why would it
On Fri, Mar 9, 2012 at 16:37, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 9, 2012 at 9:55 AM, Tom Lane wrote:
>>> Actually ... now that I look at it, isn't it completely bogus to be
>>> using numeric for the result of pg_xlog_location_diff?
>
>> rhaas=# select pg_xlog_location_diff('fff
On Mar 9, 2012, at 7:55 AM, Merlin Moncure wrote:
> 100% agree (having re-read the thread and Alvaro's idea having sunk
> in). Being able to set up daemon processes side by side with the
> postmaster would fit the bill nicely. It's pretty interesting to
> think of all the places you could go wi
On Fri, Mar 9, 2012 at 10:53 AM, Jeff Janes wrote:
> On Fri, Mar 9, 2012 at 5:21 AM, Robert Haas wrote:
>> On Fri, Mar 9, 2012 at 5:24 AM, Fujii Masao wrote:
>>> When a relation is loaded into cache, are corresponding indexes also loaded
>>> at the same time?
>>
>> No, although if you wanted to
On Fri, Mar 09, 2012 at 10:41:53AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > The problem is that these files are being created often by shell
> > redirects, e.g. pg_dump -f out 2> log_file. There is no clean way to
> > control the file creation permissions in this case --- only umask giv
On Fri, Mar 9, 2012 at 9:36 AM, Kohei KaiGai wrote:
> 2012/3/6 Alvaro Herrera :
>> It seems to me that the only thing that needs core support is the
>> ability to start up the daemon when postmaster is ready to accept
>> queries, and shut the daemon down when postmaster kills backends (either
>> b
On Fri, Mar 9, 2012 at 5:21 AM, Robert Haas wrote:
> On Fri, Mar 9, 2012 at 5:24 AM, Fujii Masao wrote:
>> When a relation is loaded into cache, are corresponding indexes also loaded
>> at the same time?
>
> No, although if you wanted to do that you could easily do so, using a
> query like this:
On Fri, Mar 9, 2012 at 10:33 AM, Dimitri Fontaine
wrote:
> So that's complementary with pgfincore, ok. I still wish we could
> maintain the RAM content HOT on the standby in the same way we are able
> to maintain its data set on disk, though.
That's an interesting idea. It seems tricky, though.
Bruce Momjian writes:
> The problem is that these files are being created often by shell
> redirects, e.g. pg_dump -f out 2> log_file. There is no clean way to
> control the file creation permissions in this case --- only umask gives
> us a process-level setting. Actually, one crafty idea would
Robert Haas writes:
> On Fri, Mar 9, 2012 at 9:55 AM, Tom Lane wrote:
>> Actually ... now that I look at it, isn't it completely bogus to be
>> using numeric for the result of pg_xlog_location_diff?
> rhaas=# select pg_xlog_location_diff('/0', '0/0')::int8;
> ERROR: bigint out of range
2012/3/6 Alvaro Herrera :
> It seems to me that the only thing that needs core support is the
> ability to start up the daemon when postmaster is ready to accept
> queries, and shut the daemon down when postmaster kills backends (either
> because one crashed, or because it's shutting down).
>
+10
Robert Haas writes:
>> https://github.com/klando/pgfincore
>
> Oh, huh. I had no idea that pgfincore could do that. I thought that
> was just for introspection; I didn't realize it could actually move
> data around for you.
Well, I though Cédric already had included shared buffers related
faci
On Fri, Mar 9, 2012 at 9:55 AM, Tom Lane wrote:
> I wrote:
>> Fujii Masao writes:
>>> Euler proposed one more patch upthread, which replaces
>>> pg_size_pretty(bigint)
>>> with pg_size_pretty(numeric) so that pg_size_pretty(pg_xlog_location_diff())
>>> succeeds. It's also worth committing this p
On Fri, Mar 9, 2012 at 10:05 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 9, 2012 at 9:22 AM, Thom Brown wrote:
>>> Sorry, I meant any command trigger. It's because none of the commands
>>> can be run on a standby, so the triggers don't seem appropriate.
>
>> I'm not convinced. Rig
On Fri, Mar 09, 2012 at 10:18:31AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > What do people think of pg_upgrade setting its umask to 0077 so the log
> > and SQL files are only readable by the postgres user?
>
> +1 for restricting the log files, but I'm dubious that you should alter
> the
On fre, 2012-03-09 at 10:10 -0500, Bruce Momjian wrote:
> What do people think of pg_upgrade setting its umask to 0077 so the
> log and SQL files are only readable by the postgres user?
That would be good to have.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
Bruce Momjian writes:
> What do people think of pg_upgrade setting its umask to 0077 so the log
> and SQL files are only readable by the postgres user?
+1 for restricting the log files, but I'm dubious that you should alter
the existing permissions on copied files in any way.
IOW, umask seems li
What do people think of pg_upgrade setting its umask to 0077 so the log
and SQL files are only readable by the postgres user?
-rwx-- 1 postgres postgres 41 Mar 9 09:59 delete_old_cluster.sh*
-rw--- 1 postgres postgres 6411 Mar 8 21:56 pg_upgrade_dump_all.sql
-rw--- 1 postgres
On 9 March 2012 15:05, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 9, 2012 at 9:22 AM, Thom Brown wrote:
>>> Sorry, I meant any command trigger. It's because none of the commands
>>> can be run on a standby, so the triggers don't seem appropriate.
>
>> I'm not convinced. Right now, it
Robert Haas writes:
> On Fri, Mar 9, 2012 at 9:22 AM, Thom Brown wrote:
>> Sorry, I meant any command trigger. It's because none of the commands
>> can be run on a standby, so the triggers don't seem appropriate.
> I'm not convinced. Right now, it's fairly useless - all the triggers
> could po
On 9 March 2012 14:47, Robert Haas wrote:
> On Fri, Mar 9, 2012 at 9:35 AM, Thom Brown wrote:
>> I see your point. My suggestion to Dimitri in another email was
>> either enable triggers for all commands or none. At the moment it's
>> only available on utility commands.
>
> Yeah, that's clearly
Robert Haas writes:
> On Fri, Mar 9, 2012 at 9:37 AM, Tom Lane wrote:
>> Why would it be useful to use pg_size_pretty on xlog locations?
> The point is that it would be useful to use it on the difference
> between two xlog locations,
Um, that is exactly the claim I was questioning. Why is that
I wrote:
> Fujii Masao writes:
>> Euler proposed one more patch upthread, which replaces pg_size_pretty(bigint)
>> with pg_size_pretty(numeric) so that pg_size_pretty(pg_xlog_location_diff())
>> succeeds. It's also worth committing this patch?
> Why would it be useful to use pg_size_pretty on xlo
On Wed, Nov 23, 2011 at 9:28 PM, Theo Schlossnagle wrote:
> We have a need for logging in systems where it isn't feasible to log
> to disk as it negatively impacts performance.
>
> I'd like to be able to creatively solve this problem without modifying
> the core, but today I cannot.
>
> So... here
Etsuro Fujita writes:
> (2012/03/09 14:00), Tom Lane wrote:
>> Attached is a draft patch for that.
> 1. FilefdwPlanState.pages and FileFdwPlanState.ntuples seems redundant.
> Why not use RelOptInfo.pages and RelOptInfo.tuples?
I intentionally avoided setting RelOptInfo.pages because that woul
On Fri, Mar 9, 2012 at 9:35 AM, Thom Brown wrote:
> I see your point. My suggestion to Dimitri in another email was
> either enable triggers for all commands or none. At the moment it's
> only available on utility commands.
Yeah, that's clearly not the best of all possible worlds. :-)
I think
On Fri, Mar 9, 2012 at 9:37 AM, Tom Lane wrote:
> Fujii Masao writes:
>> Euler proposed one more patch upthread, which replaces pg_size_pretty(bigint)
>> with pg_size_pretty(numeric) so that pg_size_pretty(pg_xlog_location_diff())
>> succeeds. It's also worth committing this patch?
>
> Why would
Fujii Masao writes:
> Euler proposed one more patch upthread, which replaces pg_size_pretty(bigint)
> with pg_size_pretty(numeric) so that pg_size_pretty(pg_xlog_location_diff())
> succeeds. It's also worth committing this patch?
Why would it be useful to use pg_size_pretty on xlog locations?
-1
On 9 March 2012 14:30, Robert Haas wrote:
> On Fri, Mar 9, 2012 at 9:22 AM, Thom Brown wrote:
>> On 9 March 2012 14:09, Robert Haas wrote:
>>> On Wed, Mar 7, 2012 at 4:53 PM, Thom Brown wrote:
I've also since found that if I issue a VACUUM, CLUSTER or REINDEX on
a read-only standby, t
On Fri, Mar 9, 2012 at 9:22 AM, Thom Brown wrote:
> On 9 March 2012 14:09, Robert Haas wrote:
>> On Wed, Mar 7, 2012 at 4:53 PM, Thom Brown wrote:
>>> I've also since found that if I issue a VACUUM, CLUSTER or REINDEX on
>>> a read-only standby, the BEFORE ANY COMMAND trigger fires. I don't
>>>
On 9 March 2012 14:09, Robert Haas wrote:
> On Wed, Mar 7, 2012 at 4:53 PM, Thom Brown wrote:
>> I've also since found that if I issue a VACUUM, CLUSTER or REINDEX on
>> a read-only standby, the BEFORE ANY COMMAND trigger fires. I don't
>> think any trigger should fire on a read-only standby.
>
On Wed, Mar 7, 2012 at 4:53 PM, Thom Brown wrote:
> I've also since found that if I issue a VACUUM, CLUSTER or REINDEX on
> a read-only standby, the BEFORE ANY COMMAND trigger fires. I don't
> think any trigger should fire on a read-only standby.
Why ever not?
--
Robert Haas
EnterpriseDB: http
On Fri, Mar 9, 2012 at 12:47 AM, Jaime Casanova wrote:
>> Sorry, here's the patch rebased and with the suggestion from Alex.
>> Which reminds me, I never thank him for the review (shame on me) :D
>
> with the patch this time
This may be a stupid idea, but it seems to me that it might be better
to
On Fri, Mar 9, 2012 at 8:25 AM, Dimitri Fontaine wrote:
> Robert Haas writes:
>> It's been bugging me for a while now that we don't have a prewarming
>> utility, for a couple of reasons, including:
>>
>> 1. Our customers look at me funny when I suggest that they use
>> pg_relation_filepath() and
On Fri, Mar 9, 2012 at 5:42 AM, Hans-Jürgen Schönig
wrote:
> we had some different idea here in the past: what if we had a procedure /
> method to allow people to save the list of current buffers / cached blocks to
> be written to disk (sorted). we could then reload this "cache profile" on
> st
1 - 100 of 115 matches
Mail list logo
