2012/12/4 Asif Rehman asifr.reh...@gmail.com:
Hi,
Here is the updated patch. I overlooked the loop, checking to free the
conversions map. Here are the results now.
postgres=# select sum(a) from generate_series(1,3000) g(i), lateral foo(i)
as (a numeric, b numeric);
sum
--
On Wed, Dec 5, 2012 at 1:56 AM, Tomas Vondra t...@fuzzy.cz wrote:
On 4.12.2012 20:12, Alexander Korotkov wrote:
Hi!
On Sun, Dec 2, 2012 at 5:02 AM, Tomas Vondra t...@fuzzy.cz
mailto:t...@fuzzy.cz wrote:
I've tried to apply the patch with the current HEAD, but I'm getting
On 30.11.2012 12:05, Vik Reykja wrote:
On Tue, Nov 27, 2012 at 3:15 PM, Heikki Linnakangashlinnakan...@vmware.com
wrote:
I fail to see the point of DEALLOCATE IF EXISTS. Do you have real use case
for this, or was this just a case of adding IF EXISTS to all commands for
the sake of
On 28.11.2012 04:11, Kyotaro HORIGUCHI wrote:
3. pgstatginidex shows only version, pending_pages, and
pendingtuples. Why don't you show the other properties such as
entry pages, data pages, entries, and total pages as
pgstatindex does?
I didn't expose those because they are accurate
On 30.11.2012 12:18, Vik Reykja wrote:
I am trying to review this patch and on my work computer everything
compiles and tests perfectly. However, on my laptop, the regression tests
don't pass with cache lookup failed for type XYZ where XYZ is some number
that does not appear to be any type oid.
2012/12/5 Heikki Linnakangas hlinnakan...@vmware.com:
On 30.11.2012 12:18, Vik Reykja wrote:
I am trying to review this patch and on my work computer everything
compiles and tests perfectly. However, on my laptop, the regression tests
don't pass with cache lookup failed for type XYZ where XYZ
On 20.11.2012 21:25, Simon Riggs wrote:
On 19 November 2012 16:25, Robert Haasrobertmh...@gmail.com wrote:
Beyond that, I think much of the appeal of the extension feature is
that it dumps as CREATE EXTENSION hstore; and nothing more. That
allows you to migrate a dump between systems with
On 05.12.2012 10:38, Pavel Stehule wrote:
2012/12/5 Heikki Linnakangashlinnakan...@vmware.com:
I get the same error. I'll mark this as waiting on author in the
commitfest.
it was with new patch?
2012/12/5 Heikki Linnakangas hlinnakan...@vmware.com:
On 05.12.2012 10:38, Pavel Stehule wrote:
2012/12/5 Heikki Linnakangashlinnakan...@vmware.com:
I get the same error. I'll mark this as waiting on author in the
commitfest.
it was with new patch?
On Fri, 2012-11-30 at 13:16 -0800, Jeff Davis wrote:
I tried for quite a while to show any kind of performance difference
between checking the VM and checking PD_ALL_VISIBLE on a 12-core box (24
if you count HT).
Three patches in question:
1. Current unpatched master
2. patch that
On 5 December 2012 00:16, Josh Berkus j...@agliodbs.com wrote:
Sure, and the DevOps staff would be using the EXPLAIN feature (if we had
it). After which they could do little anyway except complain to the ORM
authors, who might or might not give a damn. I don't see that there's
enough
On 12/5/2012 1:42 AM, Simon Riggs wrote:
I think we need a parameter called
schema_change_reporting = off (default) | on [USERSET]
which displays relevant statistics/reports about the actions taken by
DDL statements. That will also highlight locks and the need to reduce
their lock levels.
On 5 December 2012 00:35, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
So apparently this is something we broke since Nov 18. Don't know what
yet --- any thoughts?
Further experimentation shows that reverting commit
ffc3172e4e3caee0327a7e4126b5e7a3c8a1c8cf makes it work. So there's
Heikki Linnakangas hlinnakan...@vmware.com writes:
No doubt about that. I'm sure extensions written in pure SQL or PL/pgSQL are
very common. But what does that have to do with this patch?
This patch is all about enabling users to create extension without
having to ship them as root on the file
Thanks for your reviewing in spite of large number of lines.
My comments are below.
2012/12/4 Simon Riggs si...@2ndquadrant.com:
Patch looks good and also like it will/can be ready for 9.3. I'm happy
to put time into this as committer and/or reviewer and take further
responsibility for it,
Robert, thank you for the answer.
1. need exclusive lock anyway to add triggers.
Why adding a trigger needs exclusive lock?
Someone would say blocking reads is not needed (since possible trigger
events are: Insert/Update/Delete/Truncate).
2. will create a risk of deadlock.
From user perspective
On Tuesday, December 04, 2012 10:01 PM Heikki Linnakangas wrote:
After some diversions to fix bugs and refactor existing code, I've
committed a couple of small parts of this patch, which just add some
sanity checks to notice incorrect PITR scenarios. Here's a new version
of the main patch
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Josh Berkus
Sent: 05 December 2012 01:17
To: Tom Lane
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] ALTER TABLE ... NOREWRITE option
However, as I said,
On 5 December 2012 09:46, John R Pierce pie...@hogranch.com wrote:
On 12/5/2012 1:42 AM, Simon Riggs wrote:
I think we need a parameter called
schema_change_reporting = off (default) | on [USERSET]
which displays relevant statistics/reports about the actions taken by
DDL statements. That
Hello everybody,
There is message from Tom Lane (2008 !) about ramdisk:
begin /
So, IMHO, saying trust your OS + PostgreSQL is not a 100% perfect
approach for the people who are asking to keep their objects on RAM,
even though I know that there is nothing we can say right now.
Well,
I have done a high level review of the patch, and here are my comments:
1) I don't know if community is really looking for this functionality, I
followed the thread a bit and appraently there is a disagreement over it. I
will not comments on that. Let the big guys decide if they really want this
Phil Sorber escribió:
On Mon, Dec 3, 2012 at 11:59 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
- Same thing with this example:
+ para
+Standard Usage:
+screen
+ prompt$/prompt userinputpg_isready/userinput
+ prompt$/prompt userinputecho $?/userinput
+
1) I don't know if community is really looking for this functionality, I
followed the thread a bit and appraently there is a disagreement over it. I
will not comments on that. Let the big guys decide if they really want this
feature.
I saw very few distinct people voting on that.
I think this
John R Pierce pie...@hogranch.com writes:
On 12/5/2012 1:42 AM, Simon Riggs wrote:
I think we need a parameter called
schema_change_reporting = off (default) | on [USERSET]
which displays relevant statistics/reports about the actions taken by
DDL statements. That will also highlight
On Tue, Dec 4, 2012 at 2:05 PM, Jan Wieck janwi...@yahoo.com wrote:
So the question on the table is which of these three intervals
should be GUCs, and what values to use if they aren't.
I could live with all the above defaults, but would like to see more
comments on them.
I largely agree
Here's a first attempt at a new documentation chapter. This goes in
part Server Programming, just after the SPI chapter.
I just noticed that worker_spi could use some more sample code, for
example auth_counter was getting its own LWLock and also its own shmem
area, which would be helpful to
On Wed, Dec 5, 2012 at 8:53 AM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Phil Sorber escribió:
On Mon, Dec 3, 2012 at 11:59 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
- Same thing with this example:
+ para
+Standard Usage:
+screen
+ prompt$/prompt
Hi,
Thanks for your review!
Ali Dar ali.munir@gmail.com writes:
1) I don't know if community is really looking for this functionality, I
followed the thread a bit and appraently there is a disagreement over it. I
will not comments on that. Let the big guys decide if they really want this
Robert Haas wrote:
Since people *already* raise deadlock_timeout to obscenely high
values (a minute? an hour???) and then complain that things blow
up in their face, I think there's a decent argument to be made
that piggybacking anything else on that setting is unwise.
If people are really
On Nov 26, 2012, at 11:12 AM, Peter Eisentraut pete...@gmx.net wrote:
Although my intuition would be [], the existing concatenation-like
aggregates return null for no input rows, so this probably ought to be
consistent with those.
This annoys me at times, but I wrap such calls in COALESCE()
On Dec 4, 2012, at 10:05 AM, Josh Berkus j...@agliodbs.com wrote:
json_get(json, variadic text) = json
Given that I already do the equivalent in Python, this would suit me
well. Not sure about other users ...
Well, given that sometimes you will have mixed arrays and objects, how would
On 05.12.2012 12:22, Dimitri Fontaine wrote:
Heikki Linnakangashlinnakan...@vmware.com writes:
No doubt about that. I'm sure extensions written in pure SQL or PL/pgSQL are
very common. But what does that have to do with this patch?
This patch is all about enabling users to create extension
Simon Riggs si...@2ndquadrant.com writes:
On 5 December 2012 09:46, John R Pierce pie...@hogranch.com wrote:
On 12/5/2012 1:42 AM, Simon Riggs wrote:
I think we need a parameter called
schema_change_reporting = off (default) | on [USERSET]
which displays relevant statistics/reports about
On Nov 28, 2012, at 4:10 PM, Merlin Moncure mmonc...@gmail.com wrote:
Yes, it's iterative. And for deeply nested json it might be somewhat
inefficient, although the parser is pretty fast AFAICT. But it's a start.
not completely buying that: see comments below. not supporting xpath
style
On 12/05/2012 12:11 PM, David E. Wheeler wrote:
On Dec 4, 2012, at 10:05 AM, Josh Berkus j...@agliodbs.com wrote:
json_get(json, variadic text) = json
Given that I already do the equivalent in Python, this would suit me
well. Not sure about other users ...
Well, given that sometimes
On 12/05/2012 12:14 PM, David E. Wheeler wrote:
On Nov 28, 2012, at 4:10 PM, Merlin Moncure mmonc...@gmail.com wrote:
Yes, it's iterative. And for deeply nested json it might be somewhat
inefficient, although the parser is pretty fast AFAICT. But it's a start.
not completely buying that: see
On 2012-12-05 19:13:10 +0200, Heikki Linnakangas wrote:
On 05.12.2012 12:22, Dimitri Fontaine wrote:
Heikki Linnakangashlinnakan...@vmware.com writes:
No doubt about that. I'm sure extensions written in pure SQL or PL/pgSQL are
very common. But what does that have to do with this patch?
On Dec 5, 2012, at 9:21 AM, Andrew Dunstan and...@dunslane.net wrote:
For sufficiently large columns, I expect I would want a GIN index to speed
JSON value extraction queries. Possible with this proposal?
Probably not.
That greatly reduces its utility for querying, though not, of course,
On 05.12.2012 19:27, Andres Freund wrote:
And I still don't understand why pg_dump needs to know about any of this...
Extensions should be fully per-database and we want pg_dump backups to
be restorable into another database/clusters/servers. So having a mode
for pg_dump that actually makes
On 5 December 2012 15:01, Tom Lane t...@sss.pgh.pa.us wrote:
John R Pierce pie...@hogranch.com writes:
On 12/5/2012 1:42 AM, Simon Riggs wrote:
I think we need a parameter called
schema_change_reporting = off (default) | on [USERSET]
which displays relevant statistics/reports about the
On 2012-12-05 19:40:58 +0200, Heikki Linnakangas wrote:
On 05.12.2012 19:27, Andres Freund wrote:
And I still don't understand why pg_dump needs to know about any of this...
Extensions should be fully per-database and we want pg_dump backups to
be restorable into another
Heikki Linnakangas hlinnakan...@vmware.com writes:
Ok - but that it yet another issue, not to be confused with how you deploy
extensions. If we are to have such a mode in pg_dump, it should be able to
dump *all* extensions, regardless of how they were deployed. (ok, might be
difficult for
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-05 19:13:10 +0200, Heikki Linnakangas wrote:
And I still don't understand why pg_dump needs to know about any of this...
Extensions should be fully per-database and we want pg_dump backups to
be restorable into another
On Wed, Dec 5, 2012 at 11:14 AM, David E. Wheeler da...@justatheory.com wrote:
On Nov 28, 2012, at 4:10 PM, Merlin Moncure mmonc...@gmail.com wrote:
Yes, it's iterative. And for deeply nested json it might be somewhat
inefficient, although the parser is pretty fast AFAICT. But it's a start.
On 12/05/2012 12:29 PM, David E. Wheeler wrote:
On Dec 5, 2012, at 9:21 AM, Andrew Dunstan and...@dunslane.net wrote:
For sufficiently large columns, I expect I would want a GIN index to speed JSON
value extraction queries. Possible with this proposal?
Probably not.
That greatly reduces
Heikki Linnakangas hlinnakan...@vmware.com writes:
And whether extension control files (or the same information stored in a
table or wherever) should be per-database or per cluster - that's *yet*
another separate issue. You could argue for either behavior.
I think anyone arguing for the
Simon Riggs si...@2ndquadrant.com writes:
On 5 December 2012 15:01, Tom Lane t...@sss.pgh.pa.us wrote:
And perhaps more to the point, what's the advantage compared to
good old log_statement = ddl?
That logs DDL statements for the whole system and isn't user settable.
Not true; you can set it
On 2012-12-05 12:55:42 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-05 19:13:10 +0200, Heikki Linnakangas wrote:
And I still don't understand why pg_dump needs to know about any of this...
Extensions should be fully per-database and we want pg_dump backups
On 05.12.2012 20:07, Tom Lane wrote:
Heikki Linnakangashlinnakan...@vmware.com writes:
And whether extension control files (or the same information stored in a
table or wherever) should be per-database or per cluster - that's *yet*
another separate issue. You could argue for either behavior.
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
At the SQL level, extensions do live in a database. The only reason why
we currently have them on the file system is binary executables (.so,
.dylib, .dll). And those are not per database, not even per cluster, not
even per major version, they
On 05.12.2012 20:13, Andres Freund wrote:
But I really really would like them to go to a per-database directory
not a per-cluster one. Otherwise the coordination between different
database owners inside a cluster will get really hairy. I want to be
able to install different versions of an
On 2012-12-05 20:15:42 +0200, Heikki Linnakangas wrote:
On 05.12.2012 20:07, Tom Lane wrote:
Heikki Linnakangashlinnakan...@vmware.com writes:
And whether extension control files (or the same information stored in a
table or wherever) should be per-database or per cluster - that's *yet*
On 2012-12-05 20:23:29 +0200, Heikki Linnakangas wrote:
On 05.12.2012 20:13, Andres Freund wrote:
But I really really would like them to go to a per-database directory
not a per-cluster one. Otherwise the coordination between different
database owners inside a cluster will get really hairy. I
On 2012-12-05 13:18:16 -0500, Tom Lane wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
At the SQL level, extensions do live in a database. The only reason why
we currently have them on the file system is binary executables (.so,
.dylib, .dll). And those are not per database, not even
Simon,
And anything which assumes the *absence* of a manual script is also
leaving out a large class of users. ORMs are very important, but not
the only thing we serve.
Yes. In the long run, we'll probably need two solutions. An
interactive EXPLAIN, and something which logs or aborts for
On Dec 5, 2012, at 9:57 AM, Merlin Moncure mmonc...@gmail.com wrote:
Indexing large documents for fancy querying is a niche case but also
quite complex. This isn't very well covered by xmlpath either btw --
I think for inspiration we should be looking at hstore.
Agreed, although hstore,
On Wed, Dec 5, 2012 at 5:22 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
This patch is all about enabling users to create extension without
having to ship them as root on the file system of the database(s)
server(s) first.
Right, but it changes the way that existing extensions *dump*,
On Dec 5, 2012, at 10:04 AM, Andrew Dunstan and...@dunslane.net wrote:
Indexing tree-like data isn't at all easy. We don't index XML either. There
has been discussion of this sort of indexing it in the past, and a couple of
people have said they would work on it, but I have not seen a
*) xmlpath/jsonpath do searching (and decomposition) but are very
clunky from sql perspective and probably absolutely nogo in terms if
GIST/GIN. postgres spiritually wants to do things via operators and
we should (if possible) at least consider that first
Why is it a nogo for GiST? Ltree
On Wed, Dec 5, 2012 at 12:47 PM, Andres Freund and...@2ndquadrant.com wrote:
For me it seems pretty natural to support dumping extension the way they
got created. I.e. a plain CREATE EXTENSION ...; if the extension was
preinstalled and some form that includes the extension source if you
On Wed, Dec 5, 2012 at 11:24 AM, Kevin Grittner kgri...@mail.com wrote:
Robert Haas wrote:
Since people *already* raise deadlock_timeout to obscenely high
values (a minute? an hour???) and then complain that things blow
up in their face, I think there's a decent argument to be made
that
On 2012-12-05 13:50:27 -0500, Robert Haas wrote:
On Wed, Dec 5, 2012 at 12:47 PM, Andres Freund and...@2ndquadrant.com wrote:
For me it seems pretty natural to support dumping extension the way they
got created. I.e. a plain CREATE EXTENSION ...; if the extension was
preinstalled and some
On Wed, Dec 5, 2012 at 2:01 PM, Andres Freund and...@2ndquadrant.com wrote:
E.g. for years I had a set of (trigger) functions to counted the number
of rows in a table in a lockless manner. That's used in 10+ applications
of former clients of mine. All (plpg)sql.
Imagine I want to ship an
On Wed, Dec 5, 2012 at 1:41 PM, Josh Berkus j...@agliodbs.com wrote:
That's why we need a mechanism which either logs, or aborts on specific
actions. From the perspective of the DevOps staff, abort is possibly
the better option, but there may be issues with it on our end. That was
the
On 2012-12-05 14:10:34 -0500, Robert Haas wrote:
On Wed, Dec 5, 2012 at 2:01 PM, Andres Freund and...@2ndquadrant.com wrote:
E.g. for years I had a set of (trigger) functions to counted the number
of rows in a table in a lockless manner. That's used in 10+ applications
of former clients of
On 05.12.2012 14:32, Amit Kapila wrote:
On Tuesday, December 04, 2012 10:01 PM Heikki Linnakangas wrote:
After some diversions to fix bugs and refactor existing code, I've
committed a couple of small parts of this patch, which just add some
sanity checks to notice incorrect PITR scenarios.
On Wed, Dec 5, 2012 at 12:49 PM, Josh Berkus j...@agliodbs.com wrote:
*) xmlpath/jsonpath do searching (and decomposition) but are very
clunky from sql perspective and probably absolutely nogo in terms if
GIST/GIN. postgres spiritually wants to do things via operators and
we should (if
On Wed, Dec 5, 2012 at 2:19 PM, Andres Freund and...@2ndquadrant.com wrote:
IIUC, under this proposal, the client would instead need to execute
some SQL code that looks something this (I'm faking the syntax here,
forgive me, but the patch doesn't seem to contemplate ALTER):
ALTER EXTENSION
You know, event triggers seem like an awfully good solution to this
problem. All we'd need is a new event called table_rewrite:
CREATE EVENT TRIGGER my_event_trigger
ON table_rewrite
EXECUTE PROCEDURE consider_whether_to_throw_an_error();
Oh, wow, that would be perfect. That
On 2012-12-05 10:49:35 -0800, Josh Berkus wrote:
*) xmlpath/jsonpath do searching (and decomposition) but are very
clunky from sql perspective and probably absolutely nogo in terms if
GIST/GIN. postgres spiritually wants to do things via operators and
we should (if possible) at least
On 12/05/2012 01:49 PM, Josh Berkus wrote:
*) xmlpath/jsonpath do searching (and decomposition) but are very
clunky from sql perspective and probably absolutely nogo in terms if
GIST/GIN. postgres spiritually wants to do things via operators and
we should (if possible) at least consider that
On 12/05/2012 01:48 PM, David E. Wheeler wrote:
I'm sorry what I have offered isn't what you want, but plenty of other people
have told me it will go a long way meeting their needs.
*Sigh.* I guess I have not been clear.
The stuff you propose is *awesome*. I love it. The syntax with the
On Wed, Dec 5, 2012 at 12:42 PM, David E. Wheeler da...@justatheory.com wrote:
On Dec 5, 2012, at 9:57 AM, Merlin Moncure mmonc...@gmail.com wrote:
Indexing large documents for fancy querying is a niche case but also
quite complex. This isn't very well covered by xmlpath either btw --
I
On Dec 5, 2012, at 11:51 AM, Andrew Dunstan and...@dunslane.net wrote:
So I'm happy with this stuff, as long as it does not get in the way of
supporting indexing at some point in the future. I can’t wait to start using
it!
I don't see why it should get in the way of anything like that. If
Robert Haas escribió:
I have no objection whatsoever to the concept of storing the SQL and
control files somewhere that doesn't need access to the server
filesystem - in fact, I think I previously proposed allowing those to
be stored in a database table. You could do that with something
Andres Freund and...@2ndquadrant.com writes:
Maybe I am missing something, but you already can separate them per
major version. You co-wrote the debian infrastructure to do so for some
debian packages, so I am not sure what you mean here.
The debian infrastructure I've help building is all
On 2012-12-05 21:16:52 +0100, Dimitri Fontaine wrote:
Andres Freund and...@2ndquadrant.com writes:
Adding some *NON WRITABLE* per-cluster library directory doesn't seem to
be as controversion as other suggestions.
Well, it means a per-initdb (user driven) location where to store binary
So,
Lots of things are being said, most of them are really interesting and
some of them are just re-hashing what we said about a year ago in the
Inline Extensions thread, whose conclusion was that the key not to
have two different beasts (inline, file based) was for pg_dump to
process them all
On 5 December 2012 19:15, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 5, 2012 at 1:41 PM, Josh Berkus j...@agliodbs.com wrote:
That's why we need a mechanism which either logs, or aborts on specific
actions. From the perspective of the DevOps staff, abort is possibly
the better
Andres Freund escribió:
On 2012-12-05 21:16:52 +0100, Dimitri Fontaine wrote:
Now if we can't fix the executable files situation, what about making
the C coded extensions not require an executable anymore? I'm thinking
about studying what it would take exactly to write a PL/C where the
Asif Rehman asifr.reh...@gmail.com writes:
Here is the updated patch. I overlooked the loop, checking to free the
conversions map. Here are the results now.
I looked at this patch briefly. It seems to me to be completely
schizophrenic about the coercion rules. This bit:
-
Alvaro Herrera alvhe...@2ndquadrant.com writes:
+1. Certainly a pg_dump patch's thread is not the place to propose it.
Sure. Sorry about that, the goal of that previous message was to let
people come to understand better my whole vision of what is an
Extension, a contrib, and where we are what
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-05 21:16:52 +0100, Dimitri Fontaine wrote:
Now if we can't fix the executable files situation, what about making
the C coded extensions not require an executable anymore? I'm thinking
about studying what it would take exactly to write a
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
On 2012-12-05 13:18:16 -0500, Tom Lane wrote:
I think you're wasting your time to imagine that that case will ever be
fixed. Allowing the server to scribble on executable files would set
off all kinds of security alarm bells, and rightly so. If
Hi all!
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=guaibasaurusdt=2012-12-05%2016%3A17%3A01
seems like a rather odd failure in the isolation test (client)
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 2012-12-05 12:09:58 -0300, Alvaro Herrera wrote:
Here's a first attempt at a new documentation chapter. This goes in
part Server Programming, just after the SPI chapter.
I just noticed that worker_spi could use some more sample code, for
example auth_counter was getting its own LWLock and
On 2012-12-05 16:20:41 -0500, Tom Lane wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
On 2012-12-05 13:18:16 -0500, Tom Lane wrote:
I think you're wasting your time to imagine that that case will ever be
fixed. Allowing the server to scribble on executable files would set
off all
Andres Freund and...@anarazel.de writes:
On 2012-12-05 16:20:41 -0500, Tom Lane wrote:
GUC or no GUC, it'd still be letting an unprivileged network-exposed
application (PG) do something that's against any sane system-level
security policy. Lipstick is not gonna help this pig.
What about the
Andres Freund wrote:
On 2012-12-05 12:09:58 -0300, Alvaro Herrera wrote:
Here's a first attempt at a new documentation chapter. This goes in
part Server Programming, just after the SPI chapter.
I just noticed that worker_spi could use some more sample code, for
example auth_counter was
On 5 December 2012 15:09, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Here's a first attempt at a new documentation chapter. This goes in
part Server Programming, just after the SPI chapter.
I just noticed that worker_spi could use some more sample code, for
example auth_counter was
On 2012-12-05 16:42:38 -0500, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On 2012-12-05 16:20:41 -0500, Tom Lane wrote:
GUC or no GUC, it'd still be letting an unprivileged network-exposed
application (PG) do something that's against any sane system-level
security policy.
On Wed, Dec 5, 2012 at 2:54 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Robert Haas escribió:
I have no objection whatsoever to the concept of storing the SQL and
control files somewhere that doesn't need access to the server
filesystem - in fact, I think I previously proposed allowing
Simon Riggs wrote:
On 5 December 2012 15:09, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Here's a first attempt at a new documentation chapter. This goes in
part Server Programming, just after the SPI chapter.
I just noticed that worker_spi could use some more sample code, for
On Wed, Dec 5, 2012 at 7:08 AM, Filip Rembiałkowski
filip.rembialkow...@gmail.com wrote:
Robert, thank you for the answer.
1. need exclusive lock anyway to add triggers.
Why adding a trigger needs exclusive lock?
Someone would say blocking reads is not needed (since possible trigger
events
Robert Haas robertmh...@gmail.com writes:
Yeah, DROP will work. But what about ALTER .. UPDATE?
What about it?
Well, there's certainly a point, because IIUC Dimitri's patch dumps
the file into the pg_dump output no matter whether the file originally
came from an SQL command or the
On 2012-12-05 17:05:41 -0500, Robert Haas wrote:
On Wed, Dec 5, 2012 at 7:08 AM, Filip Rembiałkowski
filip.rembialkow...@gmail.com wrote:
Robert, thank you for the answer.
1. need exclusive lock anyway to add triggers.
Why adding a trigger needs exclusive lock?
Someone would say
Dimitri Fontaine escribió:
Robert Haas robertmh...@gmail.com writes:
Well, there's certainly a point, because IIUC Dimitri's patch dumps
the file into the pg_dump output no matter whether the file originally
came from an SQL command or the filesystem. IMHO, anyone who thinks
that isn't
Simon Riggs si...@2ndquadrant.com writes:
CREATE EVENT TRIGGER my_event_trigger
ON table_rewrite
EXECUTE PROCEDURE consider_whether_to_throw_an_error();
+1, I was just thinking that myself.
+1, and I think that can happen for 9.3, as soon as we agree on the list
of code points where
On 2012-12-05 19:03:44 -0300, Alvaro Herrera wrote:
Simon Riggs wrote:
Prefer
BgWorkerStart_ConsistentState to be renamed to BgWorkerRun_InHotStandby
BgWorkerStart_RecoveryFinished to be renamed to BgWorkerRun_InNormalMode
presumably a process will shutdown if (BgWorkerRun_InHotStandby
On 2012-12-05 18:42:42 -0300, Alvaro Herrera wrote:
para
structfieldbgw_sighup/structfield and structfieldbgw_sigterm/
are
pointers to functions that will be installed as signal handlers for the
new
- process.
+ process. XXX: Can they be NULL?
/para
Hm. The
1 - 100 of 134 matches
Mail list logo
