On 15 October 2012 00:30, 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.
>>>
>>> This is a bizarre disc
2012-10-14 22:31 keltezéssel, Boszormenyi Zoltan írta:
2012-10-14 22:26 keltezéssel, Boszormenyi Zoltan írta:
2012-10-14 22:23 keltezéssel, Boszormenyi Zoltan írta:
Hi,
2012-10-14 18:41 keltezéssel, Boszormenyi Zoltan írta:
2012-10-14 18:02 keltezéssel, Fujii Masao írta:
Thanks for updating
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 as well, as much as possible. But whether or not
> > something is in core is
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, causing a
> process id less than 4096 to not display a full four hex dig
[Removing all lists except -hackers. Please do not cross-post to every
list again!]
On Mon, Oct 15, 2012 at 9:22 AM, John Nash
wrote:
> Hi,
>
> Our IT Company systems architecture is based on IBM Websphere
> Application Server, we would like to migrate our databases to
> Postgres, the main proble
On Thursday, October 11, 2012 06:37:59 PM Andres Freund wrote:
> On Thursday, October 11, 2012 03:27:17 PM Andres Freund wrote:
> > On Thursday, October 11, 2012 03:23:12 PM Alvaro Herrera wrote:
> > > Alvaro Herrera escribió:
> > > > I also included two new functions in that patch, dlisti_push_hea
Hello
2012/10/14 Tom Lane :
> Pavel Stehule writes:
>> [ gset_08.diff ]
>
> In the course of adding a new backslash command, this patch manages to
> touch:
>
> * the main loop's concept of what types of backslash commands exist
> (PSQL_CMD_NOSEND ... what's the point of that, rather than making
2012/10/15 Pavel Stehule :
> Hello
>
> 2012/10/14 Tom Lane :
>> Pavel Stehule writes:
>>> [ gset_08.diff ]
>>
>> In the course of adding a new backslash command, this patch manages to
>> touch:
>>
>> * the main loop's concept of what types of backslash commands exist
>> (PSQL_CMD_NOSEND ... what
On 13.10.2012 19:35, Fujii Masao wrote:
On Thu, Oct 11, 2012 at 11:52 PM, Heikki Linnakangas
wrote:
Ok, thanks. Committed.
I found one typo. The attached patch fixes that typo.
Thanks, fixed.
ISTM you need to update the protocol.sgml because you added
the field 'replyRequested' to WalSnd
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's concept of how to process command results
>> (why? surely we don't need \g
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.
Being written as a view doesn't help
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's concept of how to process command r
On 14 October 2012 22:17, Daniel Farina wrote:
> The problem there is that it's a pain to get signed certs in, say, a
> test environment, so "don't check certs" will make its way into the
> default configuration, and now you have all pain and no gain.
This is precisely the issue that Debian dea
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 Sun, Oct 14, 2012 at 11:13:46PM +0200, Brar Piening wrote:
> Noah Misch wrote:
>> Since SDK version 7.1 is named as the "latest supported version", I
>> understand
>> from that text that installing SDK version 8.0a along with compilers from
>> another source (VS 2012 full, VS 2012 Express for D
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 -Fc -l mybackup.custom > mybackup.toc
Then, I ca
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'
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 -
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 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 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 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 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 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 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 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 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 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 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
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 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
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
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 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
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 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
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
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 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.
>
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: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 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 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 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 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 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 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 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
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 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
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
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:
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
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
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 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: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 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: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 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 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 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 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 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 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 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 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 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: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 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
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
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:
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
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 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 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: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:
>>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
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
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
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 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 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
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: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 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 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: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 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 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 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 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 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
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 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
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 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,
> 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
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
> -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
1 - 100 of 116 matches
Mail list logo
