On 16 October 2012 03:03, Christopher Browne wrote:
> There's a necessary trade-off; you can either have it globally
> *strongly* ordered, and, if so, you'll have to pay a hefty
> coordination price, or you can have the cheaper answer of a weakly
> ordered sequence. The latter leaves me feeling
On Mon, 2012-10-15 at 11:14 -0700, Josh Berkus wrote:
> I'd be in favor of a warning on create index.
Only if you can turn it off, please.
But I don't think a warning is appropriate if the statement does exactly
what the user wanted. The place to point out shortcomings of the
implementation is i
* Christopher Browne (cbbro...@gmail.com) wrote:
> There's a necessary trade-off; you can either have it globally
> *strongly* ordered, and, if so, you'll have to pay a hefty
> coordination price, or you can have the cheaper answer of a weakly
> ordered sequence. The latter leaves me feeling rathe
On Mon, Oct 15, 2012 at 5:33 PM, Simon Riggs wrote:
> Sequences, as defined by SQL Standard, provide a series of unique
> values. The current implementation on PostgreSQL isolates the
> generation mechanism to only a single node, as is common on many
> RDBMS.
I remember constructing at least the
On Tue, Oct 16, 2012 at 10:30 AM, Josh Berkus wrote:
> Stephen,
>
> > AIUI, PG-XC and PG-R need an order, so they both use an independent
> > system (eg, the PG-XC GTM) to provide that ordering.
>
> You're thinking of XIDs. This is a proposal for user-defined sequences.
>
XC also provides global
On Mon, Oct 15, 2012 at 9:18 PM, Tom Lane wrote:
> Phil Sorber writes:
>> I would also like it to have a regression test
>> which none of those seem to have.
>
> [ shrug... ] There is nothing in the current regression infrastructure
> that would work for this, so that desire is pie-in-the-sky re
* Josh Berkus (j...@agliodbs.com) wrote:
> > AIUI, PG-XC and PG-R need an order, so they both use an independent
> > system (eg, the PG-XC GTM) to provide that ordering.
>
> You're thinking of XIDs. This is a proposal for user-defined sequences.
Right, I got that it's a proposal for user sequenc
On Sat, Oct 13, 2012 at 09:14:55PM +0200, Magnus Hagander wrote:
> On Sat, Oct 13, 2012 at 9:12 PM, Bruce Momjian wrote:
> > On Sat, Oct 13, 2012 at 09:10:05PM +0200, Magnus Hagander wrote:
> >> >> > I think the idea of having the short descriptions in SQL and longer
> >> >> > ones
> >> >> > in S
Stephen,
> AIUI, PG-XC and PG-R need an order, so they both use an independent
> system (eg, the PG-XC GTM) to provide that ordering.
You're thinking of XIDs. This is a proposal for user-defined sequences.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers
Phil Sorber writes:
> On Mon, Oct 15, 2012 at 7:12 PM, Tom Lane wrote:
>> Yeah, I know a whole new executable is kind of a pain, and the amount of
>> infrastructure and added maintenance seems a bit high compared to what
>> this does. But a lot of the programs in src/bin/scripts are not much
>>
"David Johnston" writes:
>> Yeah, I know a whole new executable is kind of a pain, and the amount of
>> infrastructure and added maintenance seems a bit high compared to what
>> this does. But a lot of the programs in src/bin/scripts are not much
>> bigger. (In fact that might be the best place f
Josh,
* Josh Berkus (j...@agliodbs.com) wrote:
> I'd also love to hear from the PostgresXC folks on whether this solution
> works for them. Postgres-R too. If it works for all three of those
> tools, it's liable to work for any potential new tool.
AIUI, PG-XC and PG-R need an order, so they bot
On 12-10-15 04:51 PM, Andres Freund wrote:
Well, as a crosscheck, could you list your requirements?
Do you need anything more than outputting data in a format compatible to whats
stored in sl_log_*? You wouldn't have sl_actionseq, everything else should be
there (Well, you would need to do look
On Mon, Oct 15, 2012 at 03:51:58PM -0400, Andrew Dunstan wrote:
>
> On 10/15/2012 03:23 PM, Bruce Momjian wrote:
> >I have trouble seeing how we could implement Postgres as efficiently
> >without C macros, but maybe that is the point --- efficiency is not
> >critical in SQL --- Java and C++ give o
On Mon, Oct 15, 2012 at 2:33 PM, Simon Riggs wrote:
> Sequences, as defined by SQL Standard, provide a series of unique
> values. The current implementation on PostgreSQL isolates the
> generation mechanism to only a single node, as is common on many
> RDBMS.
>
> For sharded or replicated systems
On Mon, Oct 15, 2012 at 7:12 PM, Tom Lane wrote:
> Andres Freund writes:
>> Why not add a pg_ctl subcommand for that? For me that sounds like a good
>> place
>> for it...
>
> I think that's a bad fit, because every other pg_ctl subcommand requires
> access to the data directory. It would be ver
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Tom Lane
> Sent: Monday, October 15, 2012 7:13 PM
> To: Andres Freund
> Cc: pgsql-hackers@postgresql.org; Thom Brown; Phil Sorber
> Subject: Re: [HACKERS] [WIP] pg_pin
Andres Freund writes:
> Why not add a pg_ctl subcommand for that? For me that sounds like a good
> place
> for it...
I think that's a bad fit, because every other pg_ctl subcommand requires
access to the data directory. It would be very confusing if this one
subcommand worked remotely when the
> The design Andres and Simon have advanced already eliminates a lot of
> the common failure cases (now(), random(), nextval()) suffered by pgPool
> and similar tools. But remember, this feature doesn't have to be
Well, pgpool-II already solved the now() case by using query rewriting
technique. T
On Tuesday, October 16, 2012 12:13:14 AM Christopher Browne wrote:
> On Mon, Oct 15, 2012 at 4:51 PM, Andres Freund
wrote:
> > On Monday, October 15, 2012 10:08:28 PM Christopher Browne wrote:
> >> On Mon, Oct 15, 2012 at 3:18 PM, Peter Geoghegan
> >
> > wrote:
> >> > On 15 October 2012 19:19,
On 10/15/12 2:33 PM, Simon Riggs wrote:
> 3) Lazy allocation from the value space. When a node is close to
> running out of values, it requests a new allocation and coordinates
> with all nodes to confirm the new allocation is good.
>
> (3) is similar to the way values are allocated currently, so
On Mon, Oct 15, 2012 at 4:51 PM, Andres Freund wrote:
> On Monday, October 15, 2012 10:08:28 PM Christopher Browne wrote:
>> On Mon, Oct 15, 2012 at 3:18 PM, Peter Geoghegan
> wrote:
>> > On 15 October 2012 19:19, Bruce Momjian wrote:
>> >> I think Robert is right that if Slony can't use the API
Sequences, as defined by SQL Standard, provide a series of unique
values. The current implementation on PostgreSQL isolates the
generation mechanism to only a single node, as is common on many
RDBMS.
For sharded or replicated systems it forces people to various hackish
mechanisms in user space for
On Mon, Oct 15, 2012 at 5:32 PM, Andres Freund wrote:
> On Monday, October 15, 2012 11:28:36 PM Thom Brown wrote:
>> On 13 October 2012 22:19, Phil Sorber wrote:
>> > Based on a previous thread
>> > (http://archives.postgresql.org/pgsql-hackers/2012-10/msg00131.php) I
>> > have put together a fir
On Monday, October 15, 2012 11:28:36 PM Thom Brown wrote:
> On 13 October 2012 22:19, Phil Sorber wrote:
> > Based on a previous thread
> > (http://archives.postgresql.org/pgsql-hackers/2012-10/msg00131.php) I
> > have put together a first attempt of a pg_ping utility. I am attaching
> > two patch
On 13 October 2012 22:19, Phil Sorber wrote:
> Based on a previous thread
> (http://archives.postgresql.org/pgsql-hackers/2012-10/msg00131.php) I
> have put together a first attempt of a pg_ping utility. I am attaching
> two patches. One for the executable and one for the docs.
>
> I would also li
On 10/13/2012 10:46 PM, Andrew Dunstan wrote:
On 09/17/2012 10:01 PM, Joachim Wieland wrote:
On Mon, Jun 18, 2012 at 10:05 PM, Joachim Wieland
wrote:
Attached is a rebased version of the parallel pg_dump patch.
Attached is another rebased version for the current commitfest.
These did not
On Mon, Oct 15, 2012 at 09:17:09PM +0200, Brar Piening wrote:
> Noah Misch wrote:
>> The only matter still requiring attention is a fix for IsoLocaleName().
>>
> Yep - I'll work on this and on some denoisifying of the build log files.
Great. Just to be clear, I consider the denoisification opti
On Monday, October 15, 2012 10:08:28 PM Christopher Browne wrote:
> On Mon, Oct 15, 2012 at 3:18 PM, Peter Geoghegan
wrote:
> > On 15 October 2012 19:19, Bruce Momjian wrote:
> >> I think Robert is right that if Slony can't use the API, it is unlikely
> >> any other replication system could use
On 15 October 2012 21:03, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Oct 15, 2012 at 3:18 PM, Peter Geoghegan
>> wrote:
>>> On 15 October 2012 19:19, Bruce Momjian wrote:
I think Robert is right that if Slony can't use the API, it is unlikely
any other replication system could
On Monday, October 15, 2012 10:03:40 PM Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Oct 15, 2012 at 3:18 PM, Peter Geoghegan
wrote:
> >> On 15 October 2012 19:19, Bruce Momjian wrote:
> >>> I think Robert is right that if Slony can't use the API, it is unlikely
> >>> any other replication
On Mon, Oct 15, 2012 at 3:18 PM, Peter Geoghegan wrote:
> On 15 October 2012 19:19, Bruce Momjian wrote:
>> I think Robert is right that if Slony can't use the API, it is unlikely
>> any other replication system could use it.
>
> I don't accept that. Clearly there is a circular dependency, and
>
Robert Haas writes:
> On Mon, Oct 15, 2012 at 3:18 PM, Peter Geoghegan
> wrote:
>> On 15 October 2012 19:19, Bruce Momjian wrote:
>>> I think Robert is right that if Slony can't use the API, it is unlikely
>>> any other replication system could use it.
>> I don't accept that. Clearly there is
On Mon, Oct 15, 2012 at 3:14 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>>> if (select 1 from pg_class where relname = 'foo' and
>>> pg_table_is_visible(oid)) then
>>> truncate table foo;
>>> end if;
>>
>> Yeah, I think the functionality that we need is pretty m
On 10/15/2012 03:23 PM, Bruce Momjian wrote:
I have trouble seeing how we could implement Postgres as efficiently
without C macros, but maybe that is the point --- efficiency is not
critical in SQL --- Java and C++ give other options that are "good
enough" and less error-prone.
Er, C++ uses
On Monday, October 15, 2012 09:18:57 PM Peter Geoghegan wrote:
> On 15 October 2012 19:19, Bruce Momjian wrote:
> > I think Robert is right that if Slony can't use the API, it is unlikely
> > any other replication system could use it.
>
> I don't accept that. Clearly there is a circular dependenc
On Sat, Oct 13, 2012 at 3:49 PM, Joshua Berkus wrote:
> So, problem #1 is coming up with a mathematical formula. My initial target
> values are in terms of # of rows in the table vs. # of writes before analyze
> is triggered:
>
> 1 : 3
> 10 : 5
> 100 : 10
> 1000 : 100
> 10 : 2000
> 100
I wrote:
> I got a bit suspicious of the transient-file mechanism introduced in
> commit fba105b1099f4f5fa7283bb17cba6fed2baa8d0c after noticing that
> ...
> I believe that we probably ought to revert this mechanism entirely, and
> build a new implementation based on these concepts:
> * An SMgrRela
Robert Haas writes:
>>WITH target AS (
>>TRUNCATE TABLE t FROM target;
>
> I'm not exactly sure what that is supposed to do, but it doesn't seem
> like an easy-to-use substitute for truncate-if-exists...
Indeed. I'm still a supporter of truncate-if-exists. Still, we're also
talking about
On Mon, Oct 15, 2012 at 3:18 PM, Peter Geoghegan wrote:
> On 15 October 2012 19:19, Bruce Momjian wrote:
>> I think Robert is right that if Slony can't use the API, it is unlikely
>> any other replication system could use it.
>
> I don't accept that. Clearly there is a circular dependency, and
>
On Mon, Oct 15, 2012 at 02:14:34PM +0100, Peter Geoghegan wrote:
> On 15 October 2012 00:30, Greg Stark wrote:
> > In fact it's not a very good analogy because the situation is
> > *precisely* the same -- rules *are* macros and manipulate the raw sql
> > before it's run and the reason they can't b
On Mon, Oct 15, 2012 at 3:14 PM, Dimitri Fontaine
wrote:
> What about continuing to extend on that incredibly useful WITH syntax we
> already have:
>
>WITH target AS (
> SELECT oid::regclass AS t
> FROM pg_class c JOIN pg_namespace n ON c.relnamespace = n.oid
>WHERE pg_ta
On 15 October 2012 18:43, Josh Berkus wrote:
> Perhaps we should take a different tack on this discussion: what feature
> development is the continued presense of RULES currently blocking? If
> the rest of us had some idea why you considered this deprecation urgent,
> it would help!
>From me, t
On 15 October 2012 19:19, Bruce Momjian wrote:
> I think Robert is right that if Slony can't use the API, it is unlikely
> any other replication system could use it.
I don't accept that. Clearly there is a circular dependency, and
someone has to go first - why should the Slony guys invest in adop
Noah Misch wrote:
The only matter still requiring attention is a fix for IsoLocaleName().
Yep - I'll work on this and on some denoisifying of the build log files.
Regards,
Brar
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:
Robert Haas writes:
>> if (select 1 from pg_class where relname = 'foo' and
>> pg_table_is_visible(oid)) then
>> truncate table foo;
>> end if;
>
> Yeah, I think the functionality that we need is pretty much there
> already today. What we need to do is to get the synta
On 15 October 2012 20:04, Jeff Janes wrote:
> On Mon, Oct 15, 2012 at 11:49 AM, Andres Freund
> wrote:
>> On Monday, October 15, 2012 08:46:40 PM Jeff Janes wrote:
>>> On Mon, Oct 15, 2012 at 11:14 AM, Josh Berkus wrote:
>>> > I would be in favor of moving them to contrib for 9.4. Assuming tha
On Mon, Oct 15, 2012 at 11:46:40AM -0700, Jeff Janes wrote:
> On Mon, Oct 15, 2012 at 11:14 AM, Josh Berkus wrote:
> >
> > I would be in favor of moving them to contrib for 9.4. Assuming that
> > someone can figure out how this interacts with the existing system table
> > opclasses. Them being i
On Mon, Oct 15, 2012 at 12:30:56AM +0100, Greg Stark wrote:
> On Sun, Oct 14, 2012 at 9:30 AM, Simon Riggs wrote:
> > On 12 October 2012 19:48, Greg Stark wrote:
> >> On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs wrote:
> >>> AFAICS all RULEs can be re-expressed as Triggers or Views.
> >>
> >> Th
On Mon, Oct 15, 2012 at 11:49 AM, Andres Freund wrote:
> On Monday, October 15, 2012 08:46:40 PM Jeff Janes wrote:
>> On Mon, Oct 15, 2012 at 11:14 AM, Josh Berkus wrote:
>> > I would be in favor of moving them to contrib for 9.4. Assuming that
>> > someone can figure out how this interacts with
On 15 October 2012 19:46, Jeff Janes wrote:
> On Mon, Oct 15, 2012 at 11:14 AM, Josh Berkus wrote:
>>
>> I would be in favor of moving them to contrib for 9.4. Assuming that
>> someone can figure out how this interacts with the existing system table
>> opclasses. Them being in /contrib would al
On 10/15/2012 04:54 AM, Robert Haas wrote:
PS. I'd love to see a basic Slony plugin for this, for example, to see how
>much extra code on top of the posted patches you need to write in a plugin
>like that to make it functional. I'm worried that it's a lot..
I agree. I would go so far as to say
On Mon, Oct 15, 2012 at 08:26:08PM +0200, Andres Freund wrote:
> > > > I do not personally believe that a WAL decoding solution adequate to
> > > > drive logical replication can live outside of core, at least not
> > > > unless core exposes a whole lot more interface than we do now, and
> > > > pro
On 10/15/2012 08:44 PM, Andres Freund wrote:
On Monday, October 15, 2012 08:38:07 PM Hannu Krosing wrote:
On 10/11/2012 01:42 PM, Andres Freund wrote:
On Thursday, October 11, 2012 09:15:47 AM Heikki Linnakangas wrote:
...
If the only meaningful advantage is reducing the amount of WAL written,
On Monday, October 15, 2012 08:46:40 PM Jeff Janes wrote:
> On Mon, Oct 15, 2012 at 11:14 AM, Josh Berkus wrote:
> > I would be in favor of moving them to contrib for 9.4. Assuming that
> > someone can figure out how this interacts with the existing system table
> > opclasses. Them being in /con
On 10/15/2012 04:54 AM, Robert Haas wrote:
On Thu, Oct 11, 2012 at 3:15 AM, Heikki Linnakangas
wrote:
IMHO that's a good thing, and I'd hope this new logical replication to live
outside core as well, as much as possible. But whether or not something is
in core is just a political decision, not
On Mon, Oct 15, 2012 at 11:14 AM, Josh Berkus wrote:
>
> I would be in favor of moving them to contrib for 9.4. Assuming that
> someone can figure out how this interacts with the existing system table
> opclasses. Them being in /contrib would also put less pressure on the
> next new hacker who d
On Monday, October 15, 2012 08:38:07 PM Hannu Krosing wrote:
> On 10/11/2012 01:42 PM, Andres Freund wrote:
> > On Thursday, October 11, 2012 09:15:47 AM Heikki Linnakangas wrote:
> > ...
> > If the only meaningful advantage is reducing the amount of WAL written,
> > I can't help thinking that we s
On 10/11/2012 01:42 PM, Andres Freund wrote:
On Thursday, October 11, 2012 09:15:47 AM Heikki Linnakangas wrote:
...
If the only meaningful advantage is reducing the amount of WAL written,
I can't help thinking that we should just try to address that in the
existing solutions, even if it seems "e
On Monday, October 15, 2012 08:19:54 PM Bruce Momjian wrote:
> On Mon, Oct 15, 2012 at 09:57:19AM +0200, Andres Freund wrote:
> > On Monday, October 15, 2012 04:54:20 AM Robert Haas wrote:
> > > On Thu, Oct 11, 2012 at 3:15 AM, Heikki Linnakangas
> > >
> > > wrote:
> > > > IMHO that's a good thin
On Mon, Oct 15, 2012 at 10:01:29AM +0200, Albe Laurenz wrote:
> Bruce Momjian wrote:
> > Currently, our session id, displayed by log_line_prefix and CSV
> output,
> > is made up of the session start time epoch seconds and the process id.
> > The problem is that the printf mask is currently %lx.%x,
On Monday, October 15, 2012 08:14:51 PM Josh Berkus wrote:
> > * Put WARNINGs in the docs against the use of hash indexes, backpatch
> > to 8.3. CREATE INDEX gives no warning currently, though Index Types
> > does mention a caution.
>
> I'd be in favor of a warning on create index.
>
> Also, are
On Mon, Oct 15, 2012 at 09:57:19AM +0200, Andres Freund wrote:
> On Monday, October 15, 2012 04:54:20 AM Robert Haas wrote:
> > On Thu, Oct 11, 2012 at 3:15 AM, Heikki Linnakangas
> >
> > wrote:
> > > IMHO that's a good thing, and I'd hope this new logical replication to
> > > live outside core a
Simon,
> * Put WARNINGs in the docs against the use of hash indexes, backpatch
> to 8.3. CREATE INDEX gives no warning currently, though Index Types
> does mention a caution.
I'd be in favor of a warning on create index.
Also, are hash indexes replicated?
> * Mention in the current docs that ha
Simon, Peter, etc.:
Perhaps we should take a different tack on this discussion: what feature
development is the continued presense of RULES currently blocking? If
the rest of us had some idea why you considered this deprecation urgent,
it would help!
--
Josh Berkus
PostgreSQL Experts Inc.
http:
On Sun, Oct 14, 2012 at 9:43 AM, Tom Lane wrote:
> Satoshi Nagayasu writes:
>> (2012/10/14 13:26), Fujii Masao wrote:
>>> The tracing lwlock usage seems to still cause a small performance
>>> overhead even if reporting is disabled. I believe some users would
>>> prefer to avoid such overhead even
On Mon, Oct 15, 2012 at 10:13:24AM -0400, Robert Haas wrote:
> On Sun, Oct 14, 2012 at 9:45 AM, Simon Riggs wrote:
> > * Put WARNINGs in the docs against the use of hash indexes, backpatch
> > to 8.3. CREATE INDEX gives no warning currently, though Index Types
> > does mention a caution.
>
> I'd
Robert,
> As I've said before (and I believe Simon has said similar things), I
> think we should be vacuuming the heap much more often but only doing
> index vac when we accumulate enough dead tuples to justify the cost of
> the index scan. Pruning the heap is cheap and very effective.
You are p
On 15 October 2012 18:07, Robert Haas wrote:
> On Mon, Oct 15, 2012 at 12:59 PM, Simon Riggs wrote:
>>> I don't think I'd go so far as to say that we should
>>> imply that they'll be removed in a future release. Given how deeply
>>> intertwined they are with the planner, I doubt that that will h
On Mon, Oct 15, 2012 at 12:53 PM, Christopher Browne wrote:
> The places where *I* care about this are places where performance is
> almost entirely irrelevant to the question.
>
> When I'm writing 'scripts' that are doing this kind of thing, I'm
> doing schema 'surgery', and, within reason, it's
On Monday, October 15, 2012 07:03:35 PM Simon Riggs wrote:
> On 15 October 2012 15:19, Andres Freund said...
>
> > I vote for at least logging a wal record when a hash index is modified
> > which uses incomplete actions to set 'indisready = false' in case its
> > replayed. That should only use a r
On Mon, Oct 15, 2012 at 7:35 AM, Peter Geoghegan wrote:
> On 3 October 2012 19:04, Tom Lane wrote:
>> Daniel Farina writes:
>>> Instead, I think it makes sense to assign a number -- arbitrarily, but
>>> uniquely -- to the generation of a new row in pg_stat_statements, and,
>>> on the flip side,
On Mon, Oct 15, 2012 at 12:59 PM, Simon Riggs wrote:
>> I don't think I'd go so far as to say that we should
>> imply that they'll be removed in a future release. Given how deeply
>> intertwined they are with the planner, I doubt that that will happen;
>> and I think there is enough interest in t
On 15 October 2012 15:19, Andres Freund said...
> I vote for at least logging a wal record when a hash index is modified which
> uses incomplete actions to set 'indisready = false' in case its replayed. That
> should only use a rather minor amount of code and should help users to find
> problems f
On 15 October 2012 15:13, Robert Haas wrote:
> On Sun, Oct 14, 2012 at 9:45 AM, Simon Riggs wrote:
>> * Put WARNINGs in the docs against the use of hash indexes, backpatch
>> to 8.3. CREATE INDEX gives no warning currently, though Index Types
>> does mention a caution.
>
> I'd be in favor of addi
On Mon, Oct 15, 2012 at 11:57 AM, Robert Haas wrote:
> On Mon, Oct 15, 2012 at 10:34 AM, Greg Stark wrote:
>> I'm a bit lost. I would think pl/pgsql is precisely the same as
>> Oracle's pl/sql and MS's T-SQL. I see the complaint you have as a
>> purely implementation detail. I don't think pl/pgsq
On Sat, Oct 13, 2012 at 3:49 PM, Joshua Berkus wrote:
> For my part, over the last 3 years of consulting and dealing with
> postgresql.conf settings for more than 140 clients:
>
> * only 10% of them ever touched the autoanalyze settings at all
> * of the ~~ 14 who did:
>* 1 improved the tunin
On Mon, Oct 15, 2012 at 11:27 PM, Heikki Linnakangas
wrote:
> On 15.10.2012 13:13, Heikki Linnakangas wrote:
>>
>> On 13.10.2012 19:35, Fujii Masao wrote:
>>>
>>> ISTM you need to update the protocol.sgml because you added
>>> the field 'replyRequested' to WalSndrMessage and StandbyReplyMessage.
>
2012/10/15 1:43, Tom Lane wrote:
> Satoshi Nagayasu writes:
>> (2012/10/14 13:26), Fujii Masao wrote:
>>> The tracing lwlock usage seems to still cause a small performance
>>> overhead even if reporting is disabled. I believe some users would
>>> prefer to avoid such overhead even if pg_stat_lwloc
On Mon, Oct 15, 2012 at 10:34 AM, Greg Stark wrote:
> I'm a bit lost. I would think pl/pgsql is precisely the same as
> Oracle's pl/sql and MS's T-SQL. I see the complaint you have as a
> purely implementation detail. I don't think pl/pgsql is the best
> implemented part of Postgres but I don't se
On 10/15/2012 12:41 PM, Greg Stark wrote:
On Mon, Oct 15, 2012 at 8:00 AM, Simon Riggs wrote:
Please can anyone show me the SQL for a rule that cannot be written as
a view or a trigger? I do not believe such a thing exists and I will
provide free beer to the first person that can prove me wrong
Andrew Dunstan writes:
> We seem to have an intermittent failure on the alter_generic tests that
> look like this:
>SET SESSION AUTHORIZATION regtest_alter_user1;
>CREATE FUNCTION alt_func1(int) RETURNS int LANGUAGE sql
> AS 'SELECT $1 + 1';
> + ERROR: permission de
On 15 October 2012 14:43, Andrew Dunstan wrote:
>
> On 10/15/2012 09:07 AM, Simon Riggs wrote:
>>
>> On 15 October 2012 11:41, Greg Stark wrote:
>>>
>>> On Mon, Oct 15, 2012 at 8:00 AM, Simon Riggs
>>> wrote:
Please can anyone show me the SQL for a rule that cannot be written as
a
2012/10/15 Andrew Dunstan :
> Sorry, but this doesn't strike me as a very good idea at all. Why not just
> alter the table ownership after the restore is done?
Yes, I could restore, wrote later ALTER ... OWNER TO ... - but this
method allowed me to do it quicker.
> If we start allowing
> stuff ot
On 10/15/2012 04:34 PM, Greg Stark wrote:
On Mon, Oct 15, 2012 at 3:26 PM, Robert Haas wrote:
To be perfectly frank, I think that's exactly where we ought to be
going. Oracle and Microsoft both did it, so why are we convinced it's
a bad idea? One of the huge problems with PL/pgsql is that eve
On 15.10.2012 13:13, Heikki Linnakangas wrote:
On 13.10.2012 19:35, Fujii Masao wrote:
ISTM you need to update the protocol.sgml because you added
the field 'replyRequested' to WalSndrMessage and StandbyReplyMessage.
Oh, I didn't remember that we've documented the specific structs that we
pass
Robert Haas writes:
> IMHO, it should be our explicit goal for clients not to need to parse
> any SQL at all. I think that the communication between the server and
> event triggers should be accomplished using magic variables. If the
+1 on that. There's a but.
> data is too complex to be struc
On 3 October 2012 19:04, Tom Lane wrote:
> Daniel Farina writes:
>> Instead, I think it makes sense to assign a number -- arbitrarily, but
>> uniquely -- to the generation of a new row in pg_stat_statements, and,
>> on the flip side, whenever a row is retired its number should be
>> eliminated, p
On Mon, Oct 15, 2012 at 3:26 PM, Robert Haas wrote:
> To be perfectly frank, I think that's exactly where we ought to be
> going. Oracle and Microsoft both did it, so why are we convinced it's
> a bad idea? One of the huge problems with PL/pgsql is that every SQL
> expression in there has to be
On Fri, Oct 12, 2012 at 2:05 PM, Abhijit Menon-Sen wrote:
> Yes. I'm sorry. Is there any concise description that applies? I think
> it's worth fixing, seeing that multiple competent people have got the
> wrong idea about what it means.
I don't think there is. I think we need to replace those co
On Fri, Oct 12, 2012 at 5:52 PM, Dimitri Fontaine
wrote:
> Christopher Browne writes:
>> I suggest the though of embracing statement modifiers in DDL, with
>> some options possible:
>> a) { DDL STATEMENT } IF CONDITION;
>> b) { DDL STATEMENT } UNLESS CONDITION;
>
> Just saying. I hate that. M
On Sunday, October 14, 2012 03:45:49 PM Simon Riggs wrote:
> As discussed on other threads, Hash Indexes are currently a broken
> feature and bring us into disrepute.
>
> I describe them as broken because they are neither crash safe, nor
> could they properly be called unlogged indexes (or if so,
On Sun, Oct 14, 2012 at 9:45 AM, Simon Riggs wrote:
> * Put WARNINGs in the docs against the use of hash indexes, backpatch
> to 8.3. CREATE INDEX gives no warning currently, though Index Types
> does mention a caution.
I'd be in favor of adding such warnings to the documentation if they
are not
On Fri, Oct 12, 2012 at 12:55 PM, Dimitri Fontaine
wrote:
> The user of that command string still has to know what to look for and
> maybe should include a proper SQL parser, but at least it doesn't need
> to do much guesswork about how the serial attached sequence will get
> named by the system a
On 10/15/2012 09:07 AM, Simon Riggs wrote:
On 15 October 2012 11:41, Greg Stark wrote:
On Mon, Oct 15, 2012 at 8:00 AM, Simon Riggs wrote:
Please can anyone show me the SQL for a rule that cannot be written as
a view or a trigger? I do not believe such a thing exists and I will
provide free
On 15 October 2012 00:30, Greg Stark wrote:
> In fact it's not a very good analogy because the situation is
> *precisely* the same -- rules *are* macros and manipulate the raw sql
> before it's run and the reason they can't be replaced by triggers is
> because, like functions, triggers happen afte
On Monday, October 15, 2012 03:07:21 PM Simon Riggs wrote:
> On 15 October 2012 11:41, Greg Stark wrote:
> > On Mon, Oct 15, 2012 at 8:00 AM, Simon Riggs wrote:
> >> Please can anyone show me the SQL for a rule that cannot be written as
> >> a view or a trigger? I do not believe such a thing exis
On 15 October 2012 11:41, Greg Stark wrote:
> On Mon, Oct 15, 2012 at 8:00 AM, Simon Riggs wrote:
>> Please can anyone show me the SQL for a rule that cannot be written as
>> a view or a trigger? I do not believe such a thing exists and I will
>> provide free beer to the first person that can pro
On 10/15/2012 07:59 AM, Piotr Gasidło wrote:
Hello,
I've created small patch which allows me easily change owner during
pg_restore with backup in custom format (-Fc).
This simplifies migration when users on new server are different that
ones in backup file.
First, I get TOC file:
pg_restore -
2012/10/15 Pavel Stehule :
> 2012/10/15 Shigeru HANADA :
>> Hi Pavel,
>>
>> First of all, I'm sorry that my previous review was rough. I looked
>> your patch and existing code closely again.
>>
>> On 2012/10/15, at 12:57, Pavel Stehule wrote:
>>> 2012/10/14 Tom Lane :
* ExecQueryUsingCursor'
1 - 100 of 116 matches
Mail list logo
