Re: [HACKERS] postgresql latency & bgwriter not doing its job

On Sat, Aug 30, 2014 at 8:50 PM, Tom Lane wrote: > Andres Freund writes: >> On 2014-08-27 19:23:04 +0300, Heikki Linnakangas wrote: >>> A long time ago, Itagaki Takahiro wrote a patch sort the buffers and write >>> them out in order >>> (http://www.postgresql.org/message-id/flat/20070614153758.6

Re: [HACKERS] postgresql latency & bgwriter not doing its job

On Thu, Sep 4, 2014 at 12:36 AM, Andres Freund wrote: > It's imo quite clearly better to keep it allocated. For one after > postmaster started the checkpointer successfully you don't need to be > worried about later failures to allocate memory if you allocate it once > (unless the checkpointer FAT

Re: [Fwd: Re: [HACKERS] proposal: new long psql parameter --on-error-stop]

Hi here is a second variant with support --help=variables Regards Pavel 2014-09-04 4:25 GMT+02:00 Robert Haas : > On Thu, Aug 28, 2014 at 11:20 AM, Andres Freund > wrote: > >> >* How about making it --help=variables instead of --help-variables? > >> > >> -1, help is not a variable to be assi

Re: [HACKERS] implement subject alternative names support for SSL connections

On Wed, Sep 3, 2014 at 11:50 AM, Heikki Linnakangas wrote: > * It's ugly that the caller does the malloc and memcpy, and the > certificate_name_entry_validate_match function then modifies its name > argument. Move the malloc+memcpy inside the function. For the case of CN the caller has to do the

Re: [HACKERS] PL/pgSQL 1.2

On Wed, Sep 3, 2014 at 11:19 PM, Hannu Krosing wrote: > SELECT[1] - select exactly one row, anything else raises error > SELECT[0:1] - select zero or one rows, anything else raises error > SELECT[1:] - select one or more rows > > plain SELECT is equivalent to SELECT[0:] > > same syntax could b

Re: [HACKERS] PL/pgSQL 1.2

2014-09-04 9:37 GMT+02:00 Joel Jacobson : > On Wed, Sep 3, 2014 at 11:19 PM, Hannu Krosing > wrote: > > SELECT[1] - select exactly one row, anything else raises error > > SELECT[0:1] - select zero or one rows, anything else raises error > > SELECT[1:] - select one or more rows > > > > plain S

Re: [HACKERS] PL/pgSQL 1.2

On Thu, Sep 4, 2014 at 9:39 AM, Pavel Stehule wrote: > we have totally different opinion what is good Can you elaborate on that? Your "ASSERT CHECK ROWCOUNT = 1;" is lengthly, which is why I don't like it. Imagine if having to type my $var === 'foo'; instead of my $var =

Re: [HACKERS] implement subject alternative names support for SSL connections

On 09/04/2014 10:33 AM, Alexey Klyukin wrote: On Wed, Sep 3, 2014 at 11:50 AM, Heikki Linnakangas wrote: * It's ugly that the caller does the malloc and memcpy, and the certificate_name_entry_validate_match function then modifies its name argument. Move the malloc+memcpy inside the function.

Re: [HACKERS] PL/pgSQL 1.2

On 9/4/14 2:10 AM, Hannu Krosing wrote: On 09/04/2014 12:17 AM, Marko Tiikkaja wrote: I'm not sure how much I like that syntax in cases like: WITH t AS ( -- multi-line query here ) SELECT[0:] foo, bar INTO _bat, _man FROM foo JOIN .. JOIN .. WHERE .. -- etc. It

Re: [HACKERS] PL/pgSQL 1.2

2014-09-04 10:06 GMT+02:00 Joel Jacobson : > On Thu, Sep 4, 2014 at 9:39 AM, Pavel Stehule > wrote: > > we have totally different opinion what is good > > Can you elaborate on that? > I would to elaborate on enhancing plpgsql - but my primary target is readability without necessity of special sp

Re: [HACKERS] PL/pgSQL 1.2

On 9/4/14 10:42 AM, Pavel Stehule wrote: 2014-09-04 10:06 GMT+02:00 Joel Jacobson : *) but there are probably equally who prefer to handle business logics outside the database It is maybe main difference between me and you. Usually I don't write CRUD applications, and I am not sure if plpgsql

Re: [HACKERS] PL/pgSQL 1.2

On Thu, Sep 4, 2014 at 10:42 AM, Pavel Stehule wrote: > I am strong in opinion so PLpgSQL is targeted primary for implementation > business logic in server side. CRUD is only one from possible use cases - > and without any special importance to others. Just curious, what kind of business logic d

Re: [HACKERS] PL/pgSQL 1.2

2014-09-04 10:53 GMT+02:00 Marko Tiikkaja : > On 9/4/14 10:42 AM, Pavel Stehule wrote: > >> 2014-09-04 10:06 GMT+02:00 Joel Jacobson : >> >>> *) but there are probably equally who prefer to handle business logics >>> outside the database >>> >>> It is maybe main difference between me and you. Usu

Re: [HACKERS] PL/pgSQL 1.2

2014-09-04 10:57 GMT+02:00 Joel Jacobson : > On Thu, Sep 4, 2014 at 10:42 AM, Pavel Stehule > wrote: > > I am strong in opinion so PLpgSQL is targeted primary for implementation > > business logic in server side. CRUD is only one from possible use cases > - > > and without any special importance

Re: [HACKERS] PL/pgSQL 1.2

On Thu, Sep 4, 2014 at 11:07 AM, Pavel Stehule wrote: > it is different semantic - returns composite or set of composites --- it is > not row or rows The point was, RETURNS returns 1 while RETURNS SETOF returns 0 .. n. > Actually BL is usually processed oriented, so PL functions coverages chang

Re: [HACKERS] PL/pgSQL 1.2

2014-09-04 11:22 GMT+02:00 Joel Jacobson : > On Thu, Sep 4, 2014 at 11:07 AM, Pavel Stehule > wrote: > > it is different semantic - returns composite or set of composites --- > it is > > not row or rows > > The point was, RETURNS returns 1 while RETURNS SETOF returns 0 .. n. > no RETURNS return

Re: [HACKERS] Scaling shared buffer eviction

On Wed, Sep 3, 2014 at 8:03 PM, Robert Haas wrote: > On Wed, Sep 3, 2014 at 7:27 AM, Amit Kapila wrote: > > >> +while (tmp_num_to_free > 0) > >> > >> I am not sure it's a good idea for this value to be fixed at loop > >> start and then just decremented. > > > > It is based on the idea what bg

Re: [HACKERS] PL/pgSQL 1.2

Everyone, I've started a wiki page with the list of the things I could think of at this very moment. I probably got the most annoying ones in there, but I also might have forgotten about some things. I invite discussion of every suggestion on -HACKERS. https://wiki.postgresql.org/wiki/Impr

Re: [HACKERS] PL/pgSQL 1.2

2014-09-04 13:37 GMT+02:00 Marko Tiikkaja : > Everyone, > > I've started a wiki page with the list of the things I could think of at > this very moment. I probably got the most annoying ones in there, but I > also might have forgotten about some things. I invite discussion of every > suggestion

Re: [HACKERS] PL/pgSQL 1.2

On 9/4/14 1:47 PM, Pavel Stehule wrote: 2014-09-04 13:37 GMT+02:00 Marko Tiikkaja : I've started a wiki page with the list of the things I could think of at this very moment. I probably got the most annoying ones in there, but I also might have forgotten about some things. I invite discussion

Re: [HACKERS] Scaling shared buffer eviction

On Wed, Sep 3, 2014 at 9:45 AM, Amit Kapila wrote: > > > Performance Data: > > --- > > > > Configuration and Db Details > > IBM POWER-7 16 cores, 64 hardware threads > > RAM = 64GB > > Database Locale =C > > checkpoint_segments=256 > > checkpoint_timeout=15min > >

Re: [HACKERS] PL/pgSQL 1.2

2014-09-04 13:54 GMT+02:00 Marko Tiikkaja : > On 9/4/14 1:47 PM, Pavel Stehule wrote: > >> 2014-09-04 13:37 GMT+02:00 Marko Tiikkaja : >> >>> I've started a wiki page with the list of the things I could think of at >>> >>> this very moment. I probably got the most annoying ones in there, but I >>

Re: [HACKERS] PL/pgSQL 1.2

On Thu, Sep 4, 2014 at 4:06 AM, Joel Jacobson wrote: > Your "ASSERT CHECK ROWCOUNT = 1;" is lengthly, which is why I don't like it. > Imagine if having to type > my $var === 'foo'; > instead of > my $var = 'foo'; > on every single line of could where you want to assign a va

Re: [HACKERS] Scaling shared buffer eviction

On Thu, Sep 4, 2014 at 7:25 AM, Amit Kapila wrote: > Its not difficult to handle such cases, but it can have downside also > for the cases where demand from backends is not high. > Consider in above case if instead of 500 more allocations, it just > does 5 more allocations, then bgreclaimer will a

Re: [HACKERS] Spinlocks and compiler/memory barriers

On Tue, Aug 5, 2014 at 11:55 AM, Robert Haas wrote: > On Sun, Jul 6, 2014 at 3:12 PM, Andres Freund wrote: >>> > If you want to do that, it's fine with me. What I would do is: >>> > >>> > - Back-patch the addition of the sparcv8+ stuff all the way. If >>> > anyone's running anything older, let

Re: [HACKERS] Spinlocks and compiler/memory barriers

On September 4, 2014 2:18:37 PM CEST, Robert Haas wrote: >On Tue, Aug 5, 2014 at 11:55 AM, Robert Haas >wrote: >> On Sun, Jul 6, 2014 at 3:12 PM, Andres Freund > wrote: > If you want to do that, it's fine with me. What I would do is: > > - Back-patch the addition of the sparcv8+ s

Re: [HACKERS] PL/pgSQL 1.2

On 9/4/14 2:04 PM, Pavel Stehule wrote: for example best practices for PL/SQL by Steven Feuerstein I'll spend some time with that book to have a better idea on where you're coming from. Also, *please* don't try and extrapolate what I do based on the code examples on the wiki page; they're a

Re: [HACKERS] Join push-down support for foreign tables

On Wed, Sep 3, 2014 at 5:16 AM, Shigeru Hanada wrote: > In 2011 I proposed join push-down support for foreign tables, which > would improve performance of queries which contain join between > foreign tables in one server, but it has not finished before time-up. > This performance improvement would

Re: [HACKERS] PL/pgSQL 1.2

On 4 sep 2014, at 11:42, Pavel Stehule wrote: 2014-09-04 11:22 GMT+02:00 Joel Jacobson : > > The point was, RETURNS returns 1 while RETURNS SETOF returns 0 .. n. > no RETURNS return "VALUE" (it is not a row) .. and in combination with SELECT - value will be a row. RETURNS SETOF returns rows I

Re: [HACKERS] xslt_process deprecated?

On Wed, Sep 3, 2014 at 6:23 AM, Mark wrote: > I'd like to use the xslt_process function but it is in part of the > documentation that is deprecated. I don't want to use something that is > going to disappear and if there is a better alternative I'd like to use it, > however I cannot find an equiv

Re: [HACKERS] PL/pgSQL 1.2

2014-09-04 14:37 GMT+02:00 Joel Jacobson : > > > On 4 sep 2014, at 11:42, Pavel Stehule wrote: > > 2014-09-04 11:22 GMT+02:00 Joel Jacobson : > >> The point was, RETURNS returns 1 while RETURNS SETOF returns 0 .. n. >> > > no RETURNS return "VALUE" (it is not a row) .. and in combination with > S

Re: [HACKERS] Escaping from blocked send() reprised.

On Tue, Sep 2, 2014 at 3:01 PM, Andres Freund wrote: > I'm slightly worried about the added overhead due to the latch code. In > my implementation I only use latches after a nonblocking read, but > still. Every WaitLatchOrSocket() does a drainSelfPipe(). I wonder if > that can be made problematic.

Re: [HACKERS] Escaping from blocked send() reprised.

On 09/04/2014 03:49 PM, Robert Haas wrote: On Tue, Sep 2, 2014 at 3:01 PM, Andres Freund wrote: I'm slightly worried about the added overhead due to the latch code. In my implementation I only use latches after a nonblocking read, but still. Every WaitLatchOrSocket() does a drainSelfPipe(). I w

[HACKERS] Re: [HACKERS] RE: 答复: [HACKERS] why after increase the hash table partitions, TPMC decrease

On Tue, Sep 2, 2014 at 11:02 PM, Xiaoyulei wrote: > benchmarSQL has about half reads. So I think it should be effective. > > I don't think BufFreelistLock take much time, it just get a buffer from list. > It should be very fast. You're wrong. That list is usually empty right now; so it does a l

Re: [HACKERS] PL/pgSQL 2

On 09/01/2014 04:04 AM, Joel Jacobson wrote: + Make UPDATE/INSERT/DELETE throw error if they didnt' modify exactly 1 row, as that's the most common use-case, and provide alternative syntax to modify multiple or zero rows. What? No. The whole point of SQL is that it's set-based and can modify

Re: [HACKERS] PL/pgSQL 1.2

On 09/04/2014 01:14 AM, Pavel Stehule wrote: 2014-09-03 23:19 GMT+02:00 Hannu Krosing Only if the ASSERT syntax would become part of the original statement, it is supposed to check. In Hannu's command constraint example above, the statement that causes the error, and thus will be logged and b

Re: [HACKERS] missing tab-completion for relation options

On Thu, Sep 4, 2014 at 1:53 PM, Fujii Masao wrote: > Attached patch adds the missing tab-completion for the relation > options like autovacuum_multixact_freeze_max_age. That's a nice catch. Multixact parameters are present since 9.3. user_catalog_table since 9.4. Regards, -- Michael -- Sent v

Re: [HACKERS] PL/pgSQL 1.2

2014-09-04 15:24 GMT+02:00 Jan Wieck : > On 09/04/2014 01:14 AM, Pavel Stehule wrote: > >> 2014-09-03 23:19 GMT+02:00 Hannu Krosing > A more SQL-ish way of doing the same could probably be called COMMAND >> CONSTRAINTS >> and look something like this >> >> SELECT >> ... >>

Re: [HACKERS] Escaping from blocked send() reprised.

On Thu, Sep 4, 2014 at 9:05 AM, Heikki Linnakangas wrote: > Hmm. Perhaps we should call drainSelfPipe() only after poll/select returns > saying that there is something in the self-pipe. That would be a win > assuming it's more common for the self-pipe to be empty. Couldn't hurt. >> But my >> imp

Re: [HACKERS] PL/pgSQL 1.2

On 09/04/2014 09:31 AM, Pavel Stehule wrote: 2014-09-04 15:24 GMT+02:00 Jan Wieck Making the COMMAND CONSTRAINT part of the core SQL parser was how I understood Hannu's idea. It would be horrible to tuck that feature away inside of a PL, rather than making it available to all PLs as well as

Re: [HACKERS] PL/pgSQL 1.2

2014-09-04 15:38 GMT+02:00 Jan Wieck : > On 09/04/2014 09:31 AM, Pavel Stehule wrote: > >> 2014-09-04 15:24 GMT+02:00 Jan Wieck > >> I think I like the COMMAND CONSTRAINT the best so far. >> >> >> I not, because when it will not be part of SQL, than parser in plpgsql >> will be more complex. Y

Re: [HACKERS] psql \watch versus \timing

On Thu, Sep 4, 2014 at 1:44 PM, Fujii Masao wrote: > On Thu, Aug 28, 2014 at 8:46 PM, Fujii Masao wrote: >> Good catch. So I will remove start_xact code later. > Attached patch removes start_xact from PSQLexec. Nothing negative to say here :) Patch simply removes the second argument of PSQLexec t

Re: [HACKERS] Escaping from blocked send() reprised.

On 09/04/2014 04:37 PM, Robert Haas wrote: Hrm. So we'd have to block SIGUSR1, check the flag, then use pselect() to temporarily unblock SIGUSR1 and wait, then on return again unblock SIGUSR1? Doesn't seem very appealing. I think changing the signal mask is fast on Linux, but quite slow on at

Re: [HACKERS] Patch for psql History Display on MacOSX

On Wed, Sep 3, 2014 at 12:35 AM, Noah Misch wrote: > On Tue, Sep 02, 2014 at 01:56:34AM -0400, Tom Lane wrote: >> Noah Misch writes: >> > On Mon, Sep 01, 2014 at 10:22:57PM -0400, Tom Lane wrote: >> >> Also, as best I can tell, .psql_history files from older libedit versions >> >> are not forward

Re: [HACKERS] Escaping from blocked send() reprised.

On Thu, Sep 4, 2014 at 9:53 AM, Heikki Linnakangas wrote: > On 09/04/2014 04:37 PM, Robert Haas wrote: >> Hrm. So we'd have to block SIGUSR1, check the flag, then use >> pselect() to temporarily unblock SIGUSR1 and wait, then on return >> again unblock SIGUSR1? Doesn't seem very appealing. I th

Re: [HACKERS] PL/pgSQL 1.2

On 09/03/2014 04:19 PM, Hannu Krosing wrote: 1. Conditions for number of rows returned by SELECT or touched by UPDATE or DELETE Now that I think upon this... don't we already have it? SELECT ... LIMIT 1 That already solves the purported problem of multiple results in SELECT INTO as well. Co

Re: [HACKERS] PL/pgSQL 1.2

On 9/4/14 4:09 PM, Shaun Thomas wrote: On 09/03/2014 04:19 PM, Hannu Krosing wrote: 1. Conditions for number of rows returned by SELECT or touched by UPDATE or DELETE Now that I think upon this... don't we already have it? SELECT ... LIMIT 1 No, that just hides any bugs. We want the oppos

Re: [HACKERS] Scaling shared buffer eviction

Robert Haas wrote: > On Thu, Sep 4, 2014 at 7:25 AM, Amit Kapila wrote: >> Its not difficult to handle such cases, but it can have downside also >> for the cases where demand from backends is not high. >> Consider in above case if instead of 500 more allocations, it just >> does 5 more allocation

Re: [HACKERS] Better support of exported snapshots with pg_dump

On Wed, Sep 3, 2014 at 11:57 PM, Robert Haas wrote: > I didn't find that option to be terribly important then, but I don't > see how we can possibly get by without it now, unless our goal is to > make logical decoding as hard to use as we possibly can. Yes. With 9.4 it is possible to take a consi

Re: [HACKERS] PL/pgSQL 1.2

On 09/04/2014 02:40 PM, Pavel Stehule wrote: > > > > 2014-09-04 14:37 GMT+02:00 Joel Jacobson >: > > > > On 4 sep 2014, at 11:42, Pavel Stehule > wrote: >> 2014-09-04 11:22 GMT+02:00 Joel Jacobson >

Re: [HACKERS] Patch for psql History Display on MacOSX

Noah Misch writes: > I tried your patches against libedit-28. Wherever a command contains a > newline, unpatched psql writes the three bytes "\^A" to the history file, and > patched psql writes the four bytes "\012". Unpatched psql correctly reads > either form of the history file. Patched psql

Re: [HACKERS] Join push-down support for foreign tables

On Thu, Sep 4, 2014 at 08:37:08AM -0400, Robert Haas wrote: > The main problem I see here is that accurate costing may require a > round-trip to the remote server. If there is only one path that is > probably OK; the cost of asking the question will usually be more than > paid for by hearing that

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Wed, Sep 3, 2014 at 2:13 PM, Peter Geoghegan wrote: > On Wed, Sep 3, 2014 at 9:51 AM, Robert Haas wrote: >>> Essentially, the implementation has all stages of query processing >>> During the execution of the parent ModifyTable, a special auxiliary >>> subquery (the UPDATE ModifyTable) is consi

Re: [HACKERS] PL/pgSQL 2

> On 4 sep 2014, at 15:09, Shaun Thomas wrote: > >> On 09/01/2014 04:04 AM, Joel Jacobson wrote: >> >> + Make UPDATE/INSERT/DELETE throw error if they didnt' modify exactly 1 >> row, as that's the most common use-case, and provide alternative syntax >> to modify multiple or zero rows. > > What? No

Re: [HACKERS] Scaling shared buffer eviction

Robert Haas wrote: > On Wed, Sep 3, 2014 at 7:27 AM, Amit Kapila wrote: > >> +Background Reclaimer's Processing > >> +- > >> > >> I suggest titling this section "Background Reclaim". > > > > I don't mind changing it, but currently used title is based on similar > >

Re: [HACKERS] PL/pgSQL 1.2

On 4 sep 2014, at 15:32, Pavel Stehule wrote: 2014-09-04 15:24 GMT+02:00 Jan Wieck : > On 09/04/2014 01:14 AM, Pavel Stehule wrote: > >> 2014-09-03 23:19 GMT+02:00 Hannu Krosing > A more SQL-ish way of doing the same could probably be called COMMAND >> CONSTRAINTS >> and look some

Re: [HACKERS] Join push-down support for foreign tables

On Thursday, September 4, 2014, Bruce Momjian wrote: > On Thu, Sep 4, 2014 at 08:37:08AM -0400, Robert Haas wrote: > > The main problem I see here is that accurate costing may require a > > round-trip to the remote server. If there is only one path that is > > probably OK; the cost of asking th

Re: [HACKERS] PL/pgSQL 1.2

> On 4 sep 2014, at 16:45, Hannu Krosing wrote: > > When looking from the other end of the problem, we are > using SELECT/INSERT/UPDATE/DELETE *SET statements* in pl/pgsql > when we really want scalars. > > My understanding is that one main drivers of starting this thread > was wanting also guaran

Re: [HACKERS] PL/pgSQL 1.2

2014-09-04 17:16 GMT+02:00 Joel Jacobson : > > On 4 sep 2014, at 16:45, Hannu Krosing wrote: > > > > When looking from the other end of the problem, we are > > using SELECT/INSERT/UPDATE/DELETE *SET statements* in pl/pgsql > > when we really want scalars. > > > > My understanding is that one main

Re: [HACKERS] PL/pgSQL 1.2

2014-09-04 17:10 GMT+02:00 Joel Jacobson : > > > On 4 sep 2014, at 15:32, Pavel Stehule wrote: > > > > > 2014-09-04 15:24 GMT+02:00 Jan Wieck : > >> On 09/04/2014 01:14 AM, Pavel Stehule wrote: >> >>> 2014-09-03 23:19 GMT+02:00 Hannu Krosing >> A more SQL-ish way of doing the same could proba

Re: [HACKERS] PL/pgSQL 1.2

> On 4 sep 2014, at 17:18, Pavel Stehule wrote: > > You just need a ISAM API for Postgres, That is all. Now you are being ironic, and I would prefer to keep the discussion on a serious level. You know that's not applicable in my case, you know what I do for work and what kind of system we already

Re: [HACKERS] PL/pgSQL 1.2

On 09/04/2014 11:16 AM, Joel Jacobson wrote: On 4 sep 2014, at 16:45, Hannu Krosing wrote: When looking from the other end of the problem, we are using SELECT/INSERT/UPDATE/DELETE *SET statements* in pl/pgsql when we really want scalars. My understanding is that one main drivers of starting th

[HACKERS] .ready files appearing on slaves

Hi hackers, Since few months, we occasionally see .ready files appearing on some slave instances from various context. The two I have in mind are under 9.2.x. I tried to investigate a bit. These .ready files are created when a WAL file from pg_xlog has no corresponding file in pg_xlog/archive_st

Re: [HACKERS] PL/pgSQL 1.2

On Thu, Sep 4, 2014 at 11:32 AM, Joel Jacobson wrote: >> On 4 sep 2014, at 17:18, Pavel Stehule wrote: >> >> You just need a ISAM API for Postgres, That is all. > > Now you are being ironic, and I would prefer to keep the discussion on > a serious level. You know that's not applicable in my case,

Re: [HACKERS] PL/pgSQL 2

On 09/04/2014 02:48 AM, Robert Haas wrote: > To take another example, I've been complaining about the fact > that PostgreSQL 8.3+ requires far more typecasts in stored procedures > than any other database I'm aware of for years, probably since before > I joined EnterpriseDB. +10 This still drives

Re: [HACKERS] Join push-down support for foreign tables

On Thu, Sep 4, 2014 at 08:41:43PM +0530, Atri Sharma wrote: > > > On Thursday, September 4, 2014, Bruce Momjian wrote: > > On Thu, Sep  4, 2014 at 08:37:08AM -0400, Robert Haas wrote: > > The main problem I see here is that accurate costing may require a > > round-trip to the remot

Re: [HACKERS] Join push-down support for foreign tables

On Thu, Sep 4, 2014 at 9:26 PM, Bruce Momjian wrote: > On Thu, Sep 4, 2014 at 08:41:43PM +0530, Atri Sharma wrote: > > > > > > On Thursday, September 4, 2014, Bruce Momjian wrote: > > > > On Thu, Sep 4, 2014 at 08:37:08AM -0400, Robert Haas wrote: > > > The main problem I see here is t

Re: [HACKERS] PL/pgSQL 1.2

Pavel Stehule wrote: > You just need a ISAM API for Postgres, That is all. Joel sure hasn't *shown* us anything to suggest that wouldn't answer his needs better than any PL, or explained why that wouldn't be a better solution for him. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enter

Re: [HACKERS] PL/pgSQL 2

On 9/4/14 5:54 PM, Craig Ringer wrote: On 09/04/2014 02:48 AM, Robert Haas wrote: To take another example, I've been complaining about the fact that PostgreSQL 8.3+ requires far more typecasts in stored procedures than any other database I'm aware of for years, probably since before I joined Ent

Re: [HACKERS] PL/pgSQL 2

On 09/04/2014 06:48 AM, Joshua D. Drake wrote: > > On 09/03/2014 11:48 AM, Robert Haas wrote: > >> Anyway, to get back around to the topic of PL/SQL compatibility >> specifically, if you care about that issue, pick one thing that exists >> in PL/SQL but not in PL/pgsql and try to do something abo

Re: [HACKERS] Join push-down support for foreign tables

On Thu, Sep 4, 2014 at 09:31:20PM +0530, Atri Sharma wrote: > I am thinking we would eventually have to cache the statistics, then get > some kind of invalidation message from the foreign server.  I am also > thinking that cache would have to be global across all backends, I guess >

Re: [HACKERS] PL/pgSQL 2

Hi Craig 2014-09-04 17:54 GMT+02:00 Craig Ringer : > On 09/04/2014 02:48 AM, Robert Haas wrote: > > To take another example, I've been complaining about the fact > > that PostgreSQL 8.3+ requires far more typecasts in stored procedures > > than any other database I'm aware of for years, probably

Re: [HACKERS] pgcrypto: PGP signatures

Marko, et al, This is a review of the pgcrypto PGP signatures patch: http://www.postgresql.org/message-id/53edbcf0.9070...@joh.to There hasn't been any discussion, at least that I've been able to find. Contents & Purpose == This patch add functions to create, verify and extract i

Re: [HACKERS] Join push-down support for foreign tables

On Thu, Sep 4, 2014 at 9:33 PM, Bruce Momjian wrote: > On Thu, Sep 4, 2014 at 09:31:20PM +0530, Atri Sharma wrote: > > I am thinking we would eventually have to cache the statistics, then > get > > some kind of invalidation message from the foreign server. I am also > > thinking tha

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Tue, Sep 2, 2014 at 10:27 PM, Peter Geoghegan wrote: > * Still doesn't address the open question of whether or not we should > optimistically always try "memcmp() == 0" on tiebreak. I still lean > towards "yes". Let m be the cost of a memcmp() that fails near the end of the strings; and let s

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Wed, Sep 3, 2014 at 5:44 PM, Peter Geoghegan wrote: > On Wed, Sep 3, 2014 at 2:18 PM, Robert Haas wrote: >> My suggestion is to remove the special cases for Darwin and 32-bit >> systems and see how it goes. > > I guess it should still be a configure option, then. Or maybe there > should just b

Re: [HACKERS] PL/pgSQL 1.2

2014-09-04 18:02 GMT+02:00 Kevin Grittner : > Pavel Stehule wrote: > > > You just need a ISAM API for Postgres, That is all. > > Joel sure hasn't *shown* us anything to suggest that wouldn't > answer his needs better than any PL, or explained why that wouldn't > be a better solution for him. > I

Re: [HACKERS] PQputCopyEnd doesn't adhere to its API contract

On Wed, Sep 3, 2014 at 6:24 PM, Bruce Momjian wrote: > On Fri, May 9, 2014 at 12:03:36PM -0400, Robert Haas wrote: >> On Thu, May 8, 2014 at 5:21 PM, Tom Lane wrote: >> > Perhaps the text should be like this: >> > >> > The result is 1 if the termination message was sent; or in nonblocking >> > m

Re: [HACKERS] PQputCopyEnd doesn't adhere to its API contract

On Thu, Sep 4, 2014 at 12:52:14PM -0400, Robert Haas wrote: > On Wed, Sep 3, 2014 at 6:24 PM, Bruce Momjian wrote: > > On Fri, May 9, 2014 at 12:03:36PM -0400, Robert Haas wrote: > >> On Thu, May 8, 2014 at 5:21 PM, Tom Lane wrote: > >> > Perhaps the text should be like this: > >> > > >> > The

Re: [HACKERS] PQputCopyEnd doesn't adhere to its API contract

On Thu, Sep 4, 2014 at 12:53 PM, Bruce Momjian wrote: > On Thu, Sep 4, 2014 at 12:52:14PM -0400, Robert Haas wrote: >> On Wed, Sep 3, 2014 at 6:24 PM, Bruce Momjian wrote: >> > On Fri, May 9, 2014 at 12:03:36PM -0400, Robert Haas wrote: >> >> On Thu, May 8, 2014 at 5:21 PM, Tom Lane wrote: >>

Re: [HACKERS] postgresql latency & bgwriter not doing its job

On Thu, Sep 4, 2014 at 3:09 AM, Ants Aasma wrote: > On Thu, Sep 4, 2014 at 12:36 AM, Andres Freund wrote: >> It's imo quite clearly better to keep it allocated. For one after >> postmaster started the checkpointer successfully you don't need to be >> worried about later failures to allocate memor

Re: [HACKERS] PL/pgSQL 1.2

On Thu, Sep 4, 2014 at 5:51 PM, Robert Haas wrote: >> When you suggest ISAM, that's like saying "demolish your house and >> build a new one" when all I want is to make small but important >> changes to what I already do as a professional on a daily basis. > > Go right ahead: this is an open source

Re: [HACKERS] PQputCopyEnd doesn't adhere to its API contract

On Thu, Sep 4, 2014 at 1:00 PM, Robert Haas [via PostgreSQL] < ml-node+s1045698n581780...@n5.nabble.com> wrote: > On Thu, Sep 4, 2014 at 12:53 PM, Bruce Momjian <[hidden email] > > wrote: > > > On Thu, Sep 4, 2014 at 12:52:14PM -0400, Robert H

Re: [HACKERS] Display of timestamp in pg_dump custom format

On Wed, Sep 3, 2014 at 08:33:31PM -0400, Bruce Momjian wrote: > I can't seem to find a way to get the timezone offset via C; see: > > > http://stackoverflow.com/questions/635780/why-does-glibc-timezone-global-not-agree-with-system-time-on-dst > > On Linux, do 'man timezone' for details.

Re: [HACKERS] Pg_upgrade and toast tables bug discovered

The 9.3.5 release notes contain... - Fix pg_upgrade for cases where the new server creates a TOAST table but the old version did not (Bruce Momjian) This rare situation would manifest as "relation OID mismatch" errors. ...which I thought was this bug, hence my confusion. If anyon

Re: [HACKERS] pgcrypto: PGP armor headers

Marko, et al, This is a review of the pgcrypto PGP Armor Headers patch: http://www.postgresql.org/message-id/53edcae8.20...@joh.to Contents & Purpose == This patch add functions to create and extract OpenPGP Armor Headers. from OpenPGP messages. Included in the patch are updated

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Thu, Sep 4, 2014 at 9:19 AM, Robert Haas wrote: > On Tue, Sep 2, 2014 at 10:27 PM, Peter Geoghegan wrote: >> * Still doesn't address the open question of whether or not we should >> optimistically always try "memcmp() == 0" on tiebreak. I still lean >> towards "yes". > > Let m be the cost of a

Re: [HACKERS] PL/pgSQL 2

On 09/04/2014 09:02 AM, Craig Ringer wrote: > There are a few things I would like to see, like secure session > variables in PL/PgSQL. Mostly, though, I think talk of "Oracle > compatibility" seems to be something that comes up before the speaker > has really understood what that would mean, and th

Re: [HACKERS] Pg_upgrade and toast tables bug discovered

On Thu, Sep 4, 2014 at 11:37:27AM -0600, Noah Yetter wrote: > The 9.3.5 release notes contain... > > > • Fix pg_upgrade for cases where the new server creates a TOAST table but > the > old version did not (Bruce Momjian) > > This rare situation would manifest as "relation OID mismatc

Re: [HACKERS] PL/pgSQL 2

2014-09-04 20:31 GMT+02:00 Josh Berkus : > On 09/04/2014 09:02 AM, Craig Ringer wrote: > > There are a few things I would like to see, like secure session > > variables in PL/PgSQL. Mostly, though, I think talk of "Oracle > > compatibility" seems to be something that comes up before the speaker >

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Thu, Sep 4, 2014 at 8:03 AM, Robert Haas wrote: > I think there shouldn't be any plan nodes in the system that don't get > displayed by explain. If you're using a plan node for something, and > think it shouldn't be displayed by explain, then either (1) you are > wrong or (2) you are abusing t

Re: [HACKERS] Pg_upgrade and toast tables bug discovered

On Thu, Sep 4, 2014 at 2:39 PM, Bruce Momjian [via PostgreSQL] < ml-node+s1045698n5817828...@n5.nabble.com> wrote: > On Thu, Sep 4, 2014 at 11:37:27AM -0600, Noah Yetter wrote: > > > The 9.3.5 release notes contain... > > > > > > • Fix pg_upgrade for cases where the new server creates a TOAST t

Re: [HACKERS] Pg_upgrade and toast tables bug discovered

Isn't that exactly what the release note says? "where the new server creates a TOAST table but the old version did not" vs. "where the new cluster needs a TOAST table that the old cluster didn't" At any rate, I've additionally observed that the relation which is blowing up pg_upgrade is a VIEW in

Re: [HACKERS] Built-in binning functions

Hi I did a review of last patch 1. There is no problem with patching 2. compilation and doc compilation without warnings and issues. 3. code is clean, respects Postgres coding rules and is well documented - it is slightly modified Tom's version with float8 optimization 4. The name with_bucket is

Re: [HACKERS] Pg_upgrade and toast tables bug discovered

On Thu, Sep 4, 2014 at 01:14:01PM -0600, Noah Yetter wrote: > Isn't that exactly what the release note says?  > "where the new server creates a TOAST table but the old version did not"  > vs.  > "where the new cluster needs a TOAST table that the old cluster didn't" Sorry, yes, I got confused. W

Re: [HACKERS] Commitfest status

* Heikki Linnakangas (hlinnakan...@vmware.com) wrote: > 5. Better syntax for REINDEX > 6. pgcrypto: support PGP signatures > 7. pgcrypto: PGP armour headers [...] > I think the latter 3 patches are missing a reviewer because no-one > is interested in them. There was some discussion on the REINDEX

Re: [HACKERS] Pg_upgrade and toast tables bug discovered

On Thu, Sep 4, 2014 at 3:35 PM, Bruce Momjian wrote: >> At any rate, I've additionally observed that the relation which is blowing up >> pg_upgrade is a VIEW in the source cluster but gets created as a TABLE in the >> upgraded cluster, which may better explain why it had no toast table before >>

Re: [HACKERS] PL/pgSQL 2

* Robert Haas (robertmh...@gmail.com) wrote: > Second, if you did manage to develop something which was significantly > more compatible with Oracle than PostgreSQL or PL/pgsql is today, > you'd probably find that the community wouldn't accept it. Agreed. Moving PostgreSQL forward is what the comm

Re: [HACKERS] Commitfest status

On Thu, Sep 4, 2014 at 12:42 PM, Stephen Frost wrote: > I'm certainly interested in the pgcrypto patches and can look at REINDEX > this weekend. I'm thinking of picking one of these up, but I'll be on vacation next week, and so probably won't get to it until the 15th at the earliest. The hash joi

Re: [HACKERS] Pg_upgrade and toast tables bug discovered

On Thu, Sep 4, 2014 at 03:48:17PM -0400, Robert Haas wrote: > On Thu, Sep 4, 2014 at 3:35 PM, Bruce Momjian wrote: > >> At any rate, I've additionally observed that the relation which is blowing > >> up > >> pg_upgrade is a VIEW in the source cluster but gets created as a TABLE in > >> the > >>

  1   2   >