Re: [HACKERS] PL/PgSQL: EXIT USING ROLLBACK

> On 3 sep 2014, at 16:20, Robert Haas wrote: > >> On Mon, Sep 1, 2014 at 5:08 AM, Joel Jacobson wrote: >>> On Sat, Jul 26, 2014 at 8:39 PM, Tom Lane wrote: >>> Basically my point is that this just seems like inventing another way to >>> do what one can already do with RAISE, and it doesn't have

Re: [HACKERS] ODBC Driver performance comparison

I just replied to this on pgsql-odbc mailing list. Since we're talking about client performance, please keep the discussion there. On 09/05/2014 08:54 AM, Vladimir Romanov wrote: Hello all! I do some test with ODBC driver for PosgreSql, TimesTen & MySQL. I compare performance on very simple req

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

Hello, > > - This patch introduced redundant socket emulation for win32 > >backend but win32 bare socket for Port is already nonblocking > >as described so it donsn't seem to be a serious problem on > >performance. Addition to it, since I don't know the reason why > >win32/socket.c

Re: [HACKERS] Re: proposal: ignore null fields in not relation type composite type based constructors

Thank you Regards Pavel 2014-09-05 8:29 GMT+02:00 Jeevan Chalke : > > > > On Thu, Sep 4, 2014 at 11:41 AM, Pavel Stehule > wrote: > >> I am sory >> >> too much patches >> > > :) > > Patch looks good to me. > Marking "Ready for Committer". > > Thanks > > >> >> Regards >> >> Pavel >> > > > -- >

Re: [HACKERS] Re: proposal: ignore null fields in not relation type composite type based constructors

On Thu, Sep 4, 2014 at 11:41 AM, Pavel Stehule wrote: > I am sory > > too much patches > :) Patch looks good to me. Marking "Ready for Committer". Thanks > > Regards > > Pavel > -- Jeevan B Chalke Principal Software Engineer, Product Development EnterpriseDB Corporation The Enterprise Pos

[HACKERS] proposal: plpgsql - Assert statement

Hello Assert is usually implemented as custom functions and used via PERFORM statement now -- usual current solution PERFORM Assert(some expression) I would to implement Assert as plpgsql internal statement due bigger possibilities to design syntax and internal implementation now and in future.

[HACKERS] ODBC Driver performance comparison

Hello all! I do some test with ODBC driver for PosgreSql, TimesTen & MySQL. I compare performance on very simple request. Database always located on same PC as test application. Test PC - Lenovo T500, Cnetos 6.5 64, 8 Gb RAM, SSD. I found what PostgreSql ODBC driver is slowest in comparison. IMHO p

Re: [HACKERS] pg_receivexlog --status-interval add fsync feedback

> > Thanks for the review! > > > > I understand the attention message wasn't appropriate. > > > > To report the write location, even If you do not specify a replication > slot. > > So the fix only appended messages. > > > > There was a description of the flush location section of '-S' option, > > b

Re: [HACKERS] A mechanism securing web applications in DBMS

> > 2.1 The authentication problem > > We address the authentication problem by requiring developers to > > define an authentication function in the DBMS. This function is > > invoked whenever an application-level user logs in. An authentication > > function contains the authentication logic in the

Re: [HACKERS] Scaling shared buffer eviction

On 04/09/14 14:42, Amit Kapila wrote: On Thu, Sep 4, 2014 at 8:00 AM, Mark Kirkwood wrote: Hi Amit, Results look pretty good. Does it help in the read-write case too? Last time I ran the tpc-b test of pgbench (results of which are posted earlier in this thread), there doesn't seem to be an

Re: [HACKERS] pg_receivexlog --status-interval add fsync feedback

On Fri, Aug 22, 2014 at 1:35 PM, wrote: >> Thank you for updating the patch. >> I reviewed the patch. >> >> First of all, I think that we should not append the above message to >> section of '-r' option. >> (Or these message might not be needed at all) Whether flush location in >> feedback messag

Re: [HACKERS] jsonb format is pessimal for toast compression

On 08/08/2014 11:18 AM, Tom Lane wrote: Andrew Dunstan writes: On 08/07/2014 11:17 PM, Tom Lane wrote: I looked into the issue reported in bug #11109. The problem appears to be that jsonb's on-disk format is designed in such a way that the leading portion of any JSON array or object will be f

Re: [HACKERS] jsonb format is pessimal for toast compression

On 08/08/2014 10:21 AM, Andrew Dunstan wrote: On 08/07/2014 11:17 PM, Tom Lane wrote: I looked into the issue reported in bug #11109. The problem appears to be that jsonb's on-disk format is designed in such a way that the leading portion of any JSON array or object will be fairly incompressib

Re: [HACKERS] jsonb format is pessimal for toast compression

On 08/12/2014 10:58 AM, Robert Haas wrote: What would really be ideal here is if the JSON code could inform the toast compression code "this many initial bytes are likely incompressible, just pass them through without trying, and then start compressing at byte N", where N is the byte following th

Re: [HACKERS] A mechanism securing web applications in DBMS

Zhaomo, * Zhaomo Yang (zhy...@cs.ucsd.edu) wrote: > I am a graduate student from UC San Diego. My adviser, Dr. Kirill > Levchenko, and I have been working on a web/DB security project for > the last few months. Since fine-grained access control in DBMS is part > of our project and the PostgreSQL c

[HACKERS] A mechanism securing web applications in DBMS

Hi all, I am a graduate student from UC San Diego. My adviser, Dr. Kirill Levchenko, and I have been working on a web/DB security project for the last few months. Since fine-grained access control in DBMS is part of our project and the PostgreSQL community is also working on it now, we would like

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

On Thu, Sep 4, 2014 at 5:07 PM, Peter Geoghegan wrote: > So I came up with what I imagined to be an unsympathetic case: BTW, this "cities" data is still available from: http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/data/cities.dump -- Peter Geoghegan -- Sent via pgsql-hacker

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

On Thu, Sep 4, 2014 at 11:12 AM, Peter Geoghegan wrote: > What I > consider an open question is whether or not we should do that on the > first call when there is no abbreviated comparison, such as on the > second or subsequent attribute in a multi-column sort, in the hope > that equality will jus

[HACKERS] settings without unit

Hi, I noticed that a setting in pg_settings without units have NULL and "" as unit values ("" for integer and NULL for the other ones). Could we be consistent? It is like that since units were introduced (b517e65). No unit means unit = NULL. A proposed patch is attached. -- Euler Taveira

Re: [HACKERS] PL/pgSQL 2

On Sep4, 2014, at 20:50 , Pavel Stehule wrote: > 2014-09-04 20:31 GMT+02:00 Josh Berkus : > * The ability to "compile" functions/procedures for faster execution. > > This point is more complex, because bottleneck is not in plpgsql - it is > terrible fast against noncompiled pcode interpreted PL/S

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

On Thu, Sep 4, 2014 at 5:13 PM, Robert Haas wrote: > On Thu, Sep 4, 2014 at 1:18 PM, David G Johnston > wrote: > > Specific observations would help though that is partly the idea - I've > been > > more focused on clarity and organization even if it requires deviating > from > > the current gener

Re: [HACKERS] Pg_upgrade and toast tables bug discovered

On Thu, Sep 4, 2014 at 03:24:05PM -0600, Noah Yetter wrote: > Doing the upgrade with an installation built from REL9_3_STABLE at > commit 52eed3d4267faf671dae0450d99982cb9ba1ac52 was successful. > > The view that I saw get re-created as a table doesn't have any circular > references, or indeed an

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

On Thu, Sep 4, 2014 at 2:18 PM, Robert Haas wrote: > Eh, maybe? I'm not sure why the case where we're using abbreviated > keys should be different than the case we're not. In either case this > is a straightforward trade-off: if we do a memcmp() before strcoll(), > we win if it returns 0 and los

Re: [HACKERS] PL/pgSQL 2

On Thu, Sep 4, 2014 at 2:31 PM, Josh Berkus wrote: > Sadly, what's prevented us from having "packages" already has been the > insistence of potential feature sponsors that they work *exactly* like > PL/SQL's packages, which is incompatible with Postgres namespacing. > Also, we'd want any "package"

Re: [HACKERS] Pg_upgrade and toast tables bug discovered

Doing the upgrade with an installation built from REL9_3_STABLE at commit 52eed3d4267faf671dae0450d99982cb9ba1ac52 was successful. The view that I saw get re-created as a table doesn't have any circular references, or indeed any references to other views, nor do any other views reference it. But

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

On Thu, Sep 4, 2014 at 2:12 PM, Peter Geoghegan wrote: > 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 tiebre

Re: [HACKERS] Commitfest status

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > * Heikki Linnakangas (hlinnakan...@vmware.com) wrote: > > > 5. Better syntax for REINDEX > > > > I think the latter 3 patches are missing a reviewer because no-one > > > is interested in them. There was some discussion o

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

On Thu, Sep 4, 2014 at 1:18 PM, David G Johnston wrote: > Specific observations would help though that is partly the idea - I've been > more focused on clarity and organization even if it requires deviating from > the current general documentation style. OK. - to the network connection used by

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

On Thu, Sep 4, 2014 at 11:55 AM, Peter Geoghegan wrote: > It's not an immediate concern, though. My immediate concern is to get some level of buy-in about how everything fits together at a high level. Separately, as discussed in my opening mail, there is the question of how value locking should u

Re: [HACKERS] Commitfest status

Stephen Frost wrote: > * Heikki Linnakangas (hlinnakan...@vmware.com) wrote: > > 5. Better syntax for REINDEX > > I think the latter 3 patches are missing a reviewer because no-one > > is interested in them. There was some discussion on the REINDEX > > syntax, and whether we want the patch at all.

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

On Thu, Sep 4, 2014 at 11:56 AM, Bruce Momjian wrote: >> I am thinking eventually we will need to cache the foreign server >> statistics on the local server. >> >> Wouldn't that lead to issues where the statistics get outdated and we have to >> anyways query the foreign server before plann

Re: [HACKERS] vacuumdb --all --analyze-in-stages - wrong order?

2014-09-04 5:36 GMT+02:00 Peter Eisentraut : > On Mon, 2014-05-19 at 13:51 -0400, Peter Eisentraut wrote: > > On 5/18/14, 3:52 AM, Pavel Stehule wrote: > > > I am looking on --analyze-in-stages option. If I understand well, > > > motivation for this option is a get some minimal statistic for > dat

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 > >>

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] 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] 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] 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 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] 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

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] 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] 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] 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] 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

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] 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] 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] 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] 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] 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] 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] 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] 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] 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 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] 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] 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] 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] 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] 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] 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] 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

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] 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 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] 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] 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] 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] 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,

[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 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

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

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

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

> 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] 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 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] 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 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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 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] 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] 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] 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] 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

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] 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

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] 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

[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] 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

  1   2   >