[HACKERS] Toward a Database URI Standard

Hackers, I've been toying with the idea of a standard for database URIs, mostly inspired by the libpq and JDBC formats Here's a writeup: http://theory.so/rfc/2013/11/26/toward-a-database-uri-standard/ What do you think? Thanks, David -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On Tue, Nov 26, 2013 at 8:25 AM, Robert Haas wrote: > On Mon, Jul 22, 2013 at 2:31 PM, Greg Smith wrote: > > I spent a little time running the tests from Heikki's script under > perf. On all three "two short fields" tests and also on the "ten tiny > fields, all changed" test, we spend about 1% o

Re: [HACKERS] New option for pg_basebackup, to specify a different directory for pg_xlog

On Wed, Nov 27, 2013 at 1:27 PM, Haribabu kommi wrote: > On 26 November 2013 23:11 Fujii Masao wrote: >> On Wed, Nov 20, 2013 at 7:43 PM, Haribabu kommi >> wrote: >> > I tried using of stat'ing in two directories, which is having a >> problem in windows. >> > So modified old approach to detect li

Re: [HACKERS] Assertions in PL/PgSQL

On Tue, 2013-11-19 at 10:40 -0500, Robert Haas wrote: > I think the goal was to get to RAISE ASSERT > WHEN ...; then, if assertions are off, you do nothing; if they're on, > you error. IF condition THEN RAISE..." isn't a suitable surrogate in > that case because you incur the overhead of testing t

Re: [HACKERS] COPY table FROM STDIN doesn't show count tag

On 26 November 2013, Amit Khandelkar wrote: >>Now if \copy command is called then, we are setting the appropriate value of >>_psqlSettings->copystream in do_copy and same is being used inside >>handleCopyIn() and handleCopyOut(). Once the \copy command execution >>finishes, we are resetting >> t

Re: [HACKERS] New option for pg_basebackup, to specify a different directory for pg_xlog

On 26 November 2013 23:11 Fujii Masao wrote: > On Wed, Nov 20, 2013 at 7:43 PM, Haribabu kommi > wrote: > > I tried using of stat'ing in two directories, which is having a > problem in windows. > > So modified old approach to detect limited errors. Updated patch > attached. > > This will detect an

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

On Tue, Nov 26, 2013 at 1:41 PM, Peter Geoghegan wrote: > Great. I'll let you know what I think. So having taken a look at what you've done here, some concerns remain. I'm coming up with a good explanation/test case, which might be easier than trying to explain it any other way. There are some v

Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

2013/11/19 Kohei KaiGai : > OK, I split them off. The part-1 is custom-scan API itself, the part-2 is > ctidscan portion, and the part-3 is remote join on postgres_fdw. These three patches can be applied with no conflict onto 2013-11-27 HEAD, but some fixes are necessary to build because commit 78

Re: [HACKERS] lock on object is already held

Does the original version of my stress test not repro the problem on 9.2? My primary concern with the fix is that I simply didn't understand what might happen after a failed lock attempt called CleanUpLock freeing the PROCLOCK but leaving some LOCALLOCK still pointing at it. As long as "nLocks ==

Re: [HACKERS] Shave a few instructions from child-process startup sequence

On Tue, Nov 26, 2013 at 9:42 PM, Peter Eisentraut wrote: > src/backend/postmaster/postmaster.c:2255: indent with spaces. > +else > src/backend/postmaster/postmaster.c:2267: indent with spaces. > +break Not sure how that happened! Attached is the updated patch. Best regards,

Re: [HACKERS] GIN improvements part 1: additional information

This patch needs to be rebased. > > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Shave a few instructions from child-process startup sequence

src/backend/postmaster/postmaster.c:2255: indent with spaces. +else src/backend/postmaster/postmaster.c:2267: indent with spaces. +break; -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/ma

Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

contrib/ctidscan/ctidscan.c:44: indent with spaces. contrib/ctidscan/ctidscan.c:250: indent with spaces. contrib/ctidscan/ctidscan.c:266: trailing whitespace. contrib/postgres_fdw/deparse.c:1044: indent with spaces. contrib/postgres_fdw/postgres_fdw.c:940: indent with spaces. src/backend/commands/e

Re: [HACKERS] Get more from indices.

On Fri, 2013-11-22 at 16:59 +0900, Kyotaro HORIGUCHI wrote: > Hello. I found a bug(?) in thsi patch as I considered on another > patch. src/backend/optimizer/util/plancat.c:256: trailing whitespace. src/backend/optimizer/util/plancat.c:261: space before tab in indent. -- Sent via pgsql-hacke

Re: [HACKERS] Logging WAL when updating hintbit

On Wed, Nov 27, 2013 at 11:04 AM, Sawada Masahiko wrote: > Thank you for feedback. > I attached the v4 patch which have modified. Just name changed to > 'wal_log_hintbtis'. Few typos in this patch found while I quickly went through: 1) s/logging hintbit/logging of hint bits/ 2) s/hintbit/hint bits

Re: [HACKERS] Logging WAL when updating hintbit

On Wed, Nov 27, 2013 at 2:28 AM, Tom Lane wrote: > Peter Eisentraut writes: >> On 11/25/13, 7:02 AM, Sawada Masahiko wrote: >>> I attached the new version patch which adds separated parameter >>> 'enable_logging_hintbit'. > >> Let's not add more parameters named enable_*. Every parameter enables

Re: [HACKERS] lock on object is already held

Daniel Wood writes: > Sorry but I don't know how to respond to an old thread I found on > postgresql.org: > http://www.postgresql.org/message-id/20766.1357318...@sss.pgh.pa.us > I presume this is still an open issue. While working on a new feature I > wrote a stress test for it. After fixing my

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

On Tue, Nov 26, 2013 at 03:25:44PM -0800, Kevin Grittner wrote: > Bruce Momjian wrote: > > > How are we handling breakage of pg_dump, not pg_dumpall? > > That was discussed.  Do you have something to add? I am confused what we are patching. Are we patching pg_dump, pg_dumpall, or both? Can I

Re: [HACKERS] Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist

Dean Rasheed writes: > Actually the IF EXISTS in DROP TABLE now applies to the schema as > well. Unfortunately there is currently no consistency across the > various DROP commands --- some tolerate a non-existent schema, while > others error out. Yeah. I think now that we've had this discussion,

Re: [HACKERS] Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist

On 26 November 2013 19:54, Peter Eisentraut wrote: > On 11/24/13, 2:28 PM, Pavel Stehule wrote: >> Note: DROP TRIGGER ON tablename is PostgreSQL feature - no other >> databases (without PostgreSQL forks) uses this syntax - so we don't need >> thinking what is in (or what will be) in ANSI standard

[HACKERS] Platform-dependent(?) failure in timeout handling

Dan Wood sent me off-list the test case mentioned in http://www.postgresql.org/message-id/CAPweHKfExEsbACRXQTBdu_4QxhHk-Cic_iwmbh5XHo_0Z=q...@mail.gmail.com I've been poking at it, and one of the failure modes I'm seeing is that all the backends hang up without crashing. I thought at first it wa

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

Bruce Momjian wrote: > How are we handling breakage of pg_dump, not pg_dumpall? That was discussed.  Do you have something to add? > doc patch? Instead of the fix you mean, or with it?  I don't see what we would change in the docs for the fix; the alternative might be to document that pg_dumpa

Re: [HACKERS] Incomplete freezing when truncating a relation during vacuum

On 2013-11-26 13:32:44 +0100, Andres Freund wrote: > A longer period of staring revealed a likely reason, in lazy_vacuum_rel: > /* Do the vacuuming */ > lazy_scan_heap(onerel, vacrelstats, Irel, nindexes, scan_all); > ... > if (whatever) >lazy_truncate_heap(onerel, vacrelstats);

Re: [HACKERS] Traffic jams in fn_extra

On Sunday, November 24, 2013 at 4:42 PM, Tom Lane wrote: > The real question of course is whether transaction-level caching is > appropriate for what they're storing. If they want only statement-level > caching then using fn_extra is often the right thing. I'm not certain it is... we get some grea

Re: [HACKERS] doPickSplit stack buffer overflow in XLogInsert?

On 2013-11-26 14:14:38 -0800, Kevin Grittner wrote: > I happened to build in a shell that was still set up for the clang > address sanitizer, and got the attached report.  On a rerun it was > repeatable.  XLogInsert() seems to read past the end of a variable > allocated on the stack in doPickSplit(

Re: [HACKERS] [PATCH] Add transforms feature

On 11/20/2013 10:58 PM, Robert Haas wrote: > On Wed, Nov 20, 2013 at 11:51 AM, Peter Eisentraut wrote: >> This is a transition problem. Nobody is required to install the >> transforms into their existing databases. They probably shouldn't. > Sure, but that's like saying "nobody's required to use

[HACKERS] doPickSplit stack buffer overflow in XLogInsert?

I happened to build in a shell that was still set up for the clang address sanitizer, and got the attached report.  On a rerun it was repeatable.  XLogInsert() seems to read past the end of a variable allocated on the stack in doPickSplit(). I haven't tried to analyze it past that, since this part

Re: [HACKERS] [PATCH] Add transforms feature

On 11/12/2013 12:21 PM, Peter Eisentraut wrote: > A transform is an SQL object that supplies to functions for converting > between data types and procedural languages. How hard would it be to extend this to add transforms directly between pairs of procedural languages ? One example would be calli

Re: [HACKERS] Suggestion: Issue warning when calling SET TRANSACTION outside transaction block

On Tue, Nov 26, 2013 at 01:58:04PM -0300, Alvaro Herrera wrote: > Bruce Momjian escribió: > > On Tue, Nov 26, 2013 at 11:22:39AM -0500, Tom Lane wrote: > > > > > Uh, I ended up mentioning "no effect" to highlight it does nothing, > > > > rather than mention a warning. Would people prefer I say "w

Re: [HACKERS] Cleaner build output when not much has changed

Peter Eisentraut wrote: > On 11/26/13, 1:36 PM, Alvaro Herrera wrote: > > A patch to use non-recursive make to construct the backend would be very > > much appreciated. We've talked about it at least two times, but no one > > seems interested enough to put in the effort. > > References? What, yo

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

On Tue, Nov 26, 2013 at 11:32 AM, Heikki Linnakangas wrote: > After fixing that bug, I'm getting a correctly-detected deadlock every now > and then with that test case. We'll probably want to carefully consider how predictably/deterministically this occurs. > Hmm. That's because the trick I used

Re: [HACKERS] Cleaner build output when not much has changed

On 11/26/13, 1:36 PM, Alvaro Herrera wrote: > A patch to use non-recursive make to construct the backend would be very > much appreciated. We've talked about it at least two times, but no one > seems interested enough to put in the effort. References? -- Sent via pgsql-hackers mailing list (pg

Re: [HACKERS] GIN improvements part 1: additional information

On 11/26/13 15:34, Alexander Korotkov wrote: What's your plans about GIN now? I tried to rebase packed posting lists with head. But I found that you've changed interface of placeToPage function. That's conflicts with packed posting lists, because dataPlaceToPageLeaf needs not only offset number t

Re: [HACKERS] PL/Python: domain over array support

2013/11/26 Heikki Linnakangas > On 11/26/13 19:07, Kevin Grittner wrote: > >> Heikki Linnakangas wrote: >> >> Ok, committed. >>> >> >> make check-world failure: >> > > Oops, sorry about that. Fixed. Maybe be you forgot to modify plpython_types_3.out

Re: [HACKERS] Extension Templates S03E11

Stephen Frost writes: > These wouldn't be PG "extensions" really though, which it seems folks > are pretty hung up on. There would also be no support for binary or > untrusted components, which is a bit frustrating, as you'd like to be > able to support those if you're a superuser. Trying to bui

Re: [HACKERS] PL/Python: domain over array support

On 11/26/13 19:07, Kevin Grittner wrote: Heikki Linnakangas wrote: Ok, committed. make check-world failure: Oops, sorry about that. Fixed. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailp

Re: [HACKERS] Incomplete freezing when truncating a relation during vacuum

On Tue, Nov 26, 2013 at 7:32 AM, Andres Freund wrote: > This is somewhat nasty :(. Yeah, that's bad. Real bad. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist

On 11/24/13, 2:28 PM, Pavel Stehule wrote: > Note: DROP TRIGGER ON tablename is PostgreSQL feature - no other > databases (without PostgreSQL forks) uses this syntax - so we don't need > thinking what is in (or what will be) in ANSI standard (or what other > databases does). In this moment syntax o

Re: [HACKERS] new unicode table border styles for psql

2013/11/26 Peter Eisentraut > On 11/22/13, 3:26 AM, Pavel Stehule wrote: > > website is related to patch for 9.3 (I add note there) > > > > patch for 9.4 is fixed - and now with small doc > > I think it would help if we considered the new border styles and the new > line styles separately. > > I

Re: [HACKERS] why semicolon after begin is not allowed in postgresql?

Josh Berkus wrote > On 11/25/2013 03:36 PM, David Johnston wrote: >> Doh! >> >> IF / THEN / ELSE / ENDIF (concept, not syntax) >> >> That also does help to reinforce the point being made here... >> >> David J. > > What point? That the status-quo should be maintained. David J. -- View

Re: [HACKERS] new unicode table border styles for psql

On 11/22/13, 3:26 AM, Pavel Stehule wrote: > website is related to patch for 9.3 (I add note there) > > patch for 9.4 is fixed - and now with small doc I think it would help if we considered the new border styles and the new line styles separately. I don't find the new border styles to be partic

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

On Tue, Nov 26, 2013 at 9:11 AM, Josh Berkus wrote: >> * It should be usable and perform well for both large batch updates and >> small transactions. >> >> * It should perform well both when there are no duplicates, and when >> there are lots of duplicates >> >> And from that follows some finer re

Re: [HACKERS] pre-commit triggers

On 11/26/2013 01:04 PM, Tom Lane wrote: Andrew Dunstan writes: "Write a hack" is not normally advice I like to give or receive. We're after a feature that at least one other RDBMS that we know of suports. But leaving that aside, what are the restrictions, if any, in what can be done in such a

Re: [HACKERS] [PATCH] SQL assertions prototype

On 11/24/13, 10:03 AM, Simon Riggs wrote: > So we'd need to get access to the changed rows, rather than > re-executing a huge SQL command that re-checks every row of the table. > That last point will make it unusable for sensible amounts of data. SQL assertions work with arbitrary expressions. So

Re: [HACKERS] Cleaner build output when not much has changed

Tom Lane wrote: > I'm pretty suspicious of cute changes like this to the makefiles. > They too often have unexpected side-effects. (I'm still pissed off > about having to manually remove objfiles.txt to get it to rebuild a .o > file, for instance.) Yeah, I've been bitten by that as well and I do

Re: [HACKERS] pre-commit triggers

On 11/26/2013 09:45 AM, Tom Lane wrote: > Josh Berkus writes: >> On 11/24/2013 06:42 AM, Simon Riggs wrote: >>> I think we should be thinking harder about how to implement >>> ASSERTIONs, possibly calling them ASSERTION TRIGGERs not pre-commit >>> write event triggers. > >> I don't know that anyo

Re: [HACKERS] pre-commit triggers

Andrew Dunstan writes: > "Write a hack" is not normally advice I like to give or receive. > We're after a feature that at least one other RDBMS that we know of suports. > But leaving that aside, what are the restrictions, if any, in what can > be done in such a callback? Are we allowed to alter

Re: [HACKERS] Cleaner build output when not much has changed

On Tue, Nov 26, 2013 at 12:37 PM, Tom Lane wrote: > Gurjeet Singh writes: > > I was looking for ways to reduce the noise in Postgres make output, > > specifically, I wanted to eliminate the "Nothing to be done for `all' " > > messages, since they don't add much value, and just ad to the clutter.

Re: [HACKERS] pre-commit triggers

Josh Berkus writes: > On 11/24/2013 06:42 AM, Simon Riggs wrote: >> I think we should be thinking harder about how to implement >> ASSERTIONs, possibly calling them ASSERTION TRIGGERs not pre-commit >> write event triggers. > I don't know that anyone is working on this, though, or even plans to.

Re: [HACKERS] New option for pg_basebackup, to specify a different directory for pg_xlog

On Wed, Nov 20, 2013 at 7:43 PM, Haribabu kommi wrote: > On 19 November 2013 19:12 Fujii Masao wrote: >> On Tue, Nov 19, 2013 at 9:14 PM, Haribabu kommi >> wrote: >> > On 18 November 2013 23:30 Fujii Masao wrote: >> >> On Tue, Nov 19, 2013 at 12:01 AM, Haribabu kommi >> >> wrote: >> >> >> >> Tha

Re: [HACKERS] Cleaner build output when not much has changed

Gurjeet Singh writes: > I was looking for ways to reduce the noise in Postgres make output, > specifically, I wanted to eliminate the "Nothing to be done for `all' " > messages, since they don't add much value, and just ad to the clutter. Why don't you just use "make -s" if you don't want to see

Re: [HACKERS] pre-commit triggers

On 11/24/2013 09:42 AM, Simon Riggs wrote: It looks to me that this idea is horribly physical and seems likely to be badly misused. I don't see any way to use these that won't be quite ugly. There is no trigger descriptor, so no way of writing a constraint sensibly, since you'll need to make a

Re: [HACKERS] Logging WAL when updating hintbit

Peter Eisentraut writes: > On 11/25/13, 7:02 AM, Sawada Masahiko wrote: >> I attached the new version patch which adds separated parameter >> 'enable_logging_hintbit'. > Let's not add more parameters named enable_*. Every parameter enables > something. More to the point: there's a convention th

Re: [HACKERS] why semicolon after begin is not allowed in postgresql?

On 11/25/2013 03:36 PM, David Johnston wrote: > Doh! > > IF / THEN / ELSE / ENDIF (concept, not syntax) > > That also does help to reinforce the point being made here... > > David J. What point? PL/pgSQL has been in use for 14 years. During that entire time, it has always used a block-ba

Re: [HACKERS] Extension Templates S03E11

Tom Lane writes: > As I've said multiple times before, this is an absolute nonstarter. FWIW, I was explaining the model that I didn't want to follow. Thanks for approving, even if that's not a surprise as the model I did follow is the one we agreed on a year ago. Regards, -- Dimitri Fontaine h

Re: [HACKERS] pre-commit triggers

On 11/24/2013 06:42 AM, Simon Riggs wrote: > I think we should be thinking harder about how to implement > ASSERTIONs, possibly calling them ASSERTION TRIGGERs not pre-commit > write event triggers. I don't know that anyone is working on this, though, or even plans to. -- Josh Berkus PostgreSQL

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

On 11/18/2013 06:44 AM, Heikki Linnakangas wrote: > I think it's important to recap the design goals of this. I don't think > these have been listed before, so let me try: > > * It should be usable and perform well for both large batch updates and > small transactions. > > * It should perform wel

Re: [HACKERS] [PATCH] Add transforms feature

Hi, Allow me to temporarily skip important questions that you asked so that we can focus on the main problem here. As soon as we decide how to handle any kind of selectivity for the transforms, then I'm back to answering the other things. Peter Eisentraut writes: > Let's review that, as there as

Re: [HACKERS] PL/Python: domain over array support

Heikki Linnakangas wrote: > Ok, committed. make check-world failure: *** /home/kgrittn/pg/master/src/pl/plpython/expected/plpython_types.out 2013-11-26 10:52:04.173441894 -0600 --- /home/kgrittn/pg/master/src/pl/plpython/results/plpython_types.out  2013-11-26 10:55:58.229445970 -0600

Re: [HACKERS] Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block

On Tue, Nov 26, 2013 at 08:54:13AM -0800, David Johnston wrote: > How about: > > "Issuing outside of a transaction has no effect and will provoke a > warning." > > I dislike "does no harm" because it can if someone thinks the current state > is different than reality. > > It is good to indicate

Re: [HACKERS] Extension Templates S03E11

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Dimitri Fontaine writes: > > So, to support uploading PGXN zip files directly within the backend, now > > the backend must be in a position to unpack the archive and build the > > extension, then it must know where the build artefacts are going to be > > fo

[HACKERS] Cleaner build output when not much has changed

I was looking for ways to reduce the noise in Postgres make output, specifically, I wanted to eliminate the "Nothing to be done for `all' " messages, since they don't add much value, and just ad to the clutter. Most of the solutions I have seen propose grepping out the noisy parts. But one of them

Re: [HACKERS] Suggestion: Issue warning when calling SET TRANSACTION outside transaction block

Bruce Momjian escribió: > On Tue, Nov 26, 2013 at 11:22:39AM -0500, Tom Lane wrote: > > > Uh, I ended up mentioning "no effect" to highlight it does nothing, > > > rather than mention a warning. Would people prefer I say "warning"? Or > > > should I say "issues a warning because it has no effect

[HACKERS] Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block

Bruce Momjian wrote >> >> - Issuing > > ABORT > > when not inside a transaction does >> >> - no harm, but it will provoke a warning message. >> >> + Issuing > > ABORT > > outside of a transaction block has no effect. >> >> >> >> Those things are not the same. >> >> > Uh, I ended up

Re: [HACKERS] Logging WAL when updating hintbit

On 11/25/13, 7:02 AM, Sawada Masahiko wrote: > I attached the new version patch which adds separated parameter > 'enable_logging_hintbit'. Let's not add more parameters named enable_*. Every parameter enables something. Also, I'd be worried about confusion with other log_* and logging_* paramete

Re: [HACKERS] Extension Templates S03E11

Dimitri Fontaine writes: > So, to support uploading PGXN zip files directly within the backend, now > the backend must be in a position to unpack the archive and build the > extension, then it must know where the build artefacts are going to be > found or it needs to `make install` in a known pref

Re: [HACKERS] Suggestion: Issue warning when calling SET TRANSACTION outside transaction block

On Tue, Nov 26, 2013 at 11:22:39AM -0500, Tom Lane wrote: > Bruce Momjian writes: > > On Mon, Nov 25, 2013 at 10:04:19PM -0500, Robert Haas wrote: > >> But the documentation says: > >> > >> - Issuing ABORT when not inside a transaction does > >> - no harm, but it will provoke a warning messag

Re: [HACKERS] Suggestion: Issue warning when calling SET TRANSACTION outside transaction block

Bruce Momjian writes: > On Mon, Nov 25, 2013 at 10:04:19PM -0500, Robert Haas wrote: >> But the documentation says: >> >> - Issuing ABORT when not inside a transaction does >> - no harm, but it will provoke a warning message. >> + Issuing ABORT outside of a transaction block has no effect.

Re: [HACKERS] UNION ALL on partitioned tables won't use indices.

Kyotaro HORIGUCHI writes: > My PATCH-1 which make them in the third group forcibly > classified as 'parent' instead of 'child' as before therefore > makes 'broken' ec member? If you marked child entries as non-child, then yes, it's broken. The definition of a regular EC member is that it's alwa

Re: [HACKERS] psql shows line number

On Tue, Nov 26, 2013 at 9:22 AM, Tom Lane wrote: > Marko Tiikkaja writes: >> On 11/26/13 2:24 PM, Pavel Stehule wrote: >>> yes, but we can define new statement like \sq+ (Show Query) > >> There's already \p; might not be too difficult to add a \p+ which would >> also show the line numbers. > > I

Re: [HACKERS] psql shows line number

Marko Tiikkaja writes: > On 11/26/13 2:24 PM, Pavel Stehule wrote: >> yes, but we can define new statement like \sq+ (Show Query) > There's already \p; might not be too difficult to add a \p+ which would > also show the line numbers. I don't actually see the point of this. If you're working wi

Re: [HACKERS] Logging WAL when updating hintbit

On Mon, Nov 25, 2013 at 9:02 PM, Sawada Masahiko wrote: > On Sun, Nov 24, 2013 at 6:02 AM, Jeff Davis wrote: >> On Tue, 2013-11-19 at 11:42 -0500, Robert Haas wrote: >> My take is that configuration options should be used to serve different >> use cases. One thing I like about postgres is that it

Re: [HACKERS] Heavily modified big table bloat even in auto vacuum is running

On 25 November 2013 10:43 Amit Kapila wrote: > On Fri, Nov 22, 2013 at 12:12 PM, Haribabu kommi > wrote: > > On 19 November 2013 10:33 Amit Kapila wrote: > >> If I understood correctly, then your patch's main intention is to > >> correct the estimate of dead tuples, so that it can lead to Vacuum >

Re: [HACKERS] psql shows line number

On 11/26/13 2:24 PM, Pavel Stehule wrote: yes, but we can define new statement like \sq+ (Show Query) There's already \p; might not be too difficult to add a \p+ which would also show the line numbers. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgres

Re: [HACKERS] psql shows line number

2013/11/26 22:24 "Pavel Stehule" : > > > > > 2013/11/26 Sawada Masahiko >> >> On Tue, Nov 26, 2013 at 9:23 PM, Marko Tiikkaja wrote: >> > On 11/26/13 1:05 PM, Sawada Masahiko wrote: >> >> >> >> When I execute query which contains error, the server returns error >> >> with line number. >> >> >> >>

Re: [HACKERS] new unicode table border styles for psql

sorry for offtopic 2013/11/25 Dimitri Fontaine > Andrew Dunstan writes: > > Even if it is it's totally off topic. Please don't hijack email threads. > > Well, when I read that parsing a user setup is too complex, for me that > calls for a solution that offers more power to the user without us

Re: [HACKERS] GIN improvements part 1: additional information

On Tue, Nov 26, 2013 at 5:34 PM, Alexander Korotkov wrote: > On Wed, Nov 20, 2013 at 9:02 PM, Heikki Linnakangas < > hlinnakan...@vmware.com> wrote: > >> On 06.11.2013 17:36, Alvaro Herrera wrote: >> >>> Just for my own illumination, can someone explain this bit? >>> >>> + If a posting list is too

Re: [HACKERS] GIN improvements part 1: additional information

Hi! On Wed, Nov 20, 2013 at 9:02 PM, Heikki Linnakangas wrote: > On 06.11.2013 17:36, Alvaro Herrera wrote: > >> Just for my own illumination, can someone explain this bit? >> >> + If a posting list is too large to store in-line in a key entry, a >> posting tree >> + is created. A posting tree i

Re: [HACKERS] COPY table FROM STDIN doesn't show count tag

On 25 November 2013 15:25, Rajeev rastogi wrote: > OK. I have revised the patch as per the discussion. > Could you please submit only the \COPY fix first ? The attached patch also contains the fix for the original COPY status fix. Now if \copy command is called then, we are setting the appropri

Re: [HACKERS] Regress tests to improve the function coverage of schemacmds and user and tablespace files

On 24 November 2013 03:04 David Rowley wrote: >I've done a quick benchmark on this this morning. >Note that I'm using windows here and I used powershell to time the regression >run with the following command: > >PS D:\Postgres\b\src\tools\msvc> Measure-Command { .\vcregress.bat check } > >I ran th

Re: [HACKERS] psql shows line number

2013/11/26 Sawada Masahiko > On Tue, Nov 26, 2013 at 9:23 PM, Marko Tiikkaja wrote: > > On 11/26/13 1:05 PM, Sawada Masahiko wrote: > >> > >> When I execute query which contains error, the server returns error > >> with line number. > >> > >> ERROR: relation "hoge" does not exist > >> LINE 35:

Re: [HACKERS] psql shows line number

On Tue, Nov 26, 2013 at 9:23 PM, Marko Tiikkaja wrote: > On 11/26/13 1:05 PM, Sawada Masahiko wrote: >> >> When I execute query which contains error, the server returns error >> with line number. >> >> ERROR: relation "hoge" does not exist >> LINE 35: hoge; >> >> But when query is long, I was not

Re: [HACKERS] PL/Python: domain over array support

On 11/26/13 11:56, Marko Kreen wrote: On Tue, Nov 26, 2013 at 12:23:48AM +0200, Heikki Linnakangas wrote: The new behavior is clearly better, but it is an incompatibility nonetheless. I don't do anything with PL/python myself, so I don't have a good feel of how much that'll break people's applic

[HACKERS] Incomplete freezing when truncating a relation during vacuum

Hi, A customer of ours reported that some columns were missing from pg_attribute. Investigation showed that they were visible to sequential but not index scans. Looking closer, the page with the missing attributes is marked as all-visible, but the xids on the individual rows were xids more than 2^

Re: [HACKERS] psql shows line number

On 11/26/13 1:05 PM, Sawada Masahiko wrote: When I execute query which contains error, the server returns error with line number. ERROR: relation "hoge" does not exist LINE 35: hoge; But when query is long, I was not sure the location where I wrote wrong SQL. Does the psql have option which sh

Re: [HACKERS] psql shows line number

2013/11/26 Sawada Masahiko > Hi all, > > When I execute query which contains error, the server returns error > with line number. > > ERROR: relation "hoge" does not exist > LINE 35: hoge; > > But when query is long, I was not sure the location where I wrote wrong > SQL. > Does the psql have opti

Re: [HACKERS] Suggestion: Issue warning when calling SET TRANSACTION outside transaction block

On Mon, Nov 25, 2013 at 10:12:43PM -0500, Bruce Momjian wrote: > > Those things are not the same. > > Uh, I ended up mentioning "no effect" to highlight it does nothing, > rather than mention a warning. Would people prefer I say "warning"? Or > should I say "issues a warning because it has no ef

Re: [HACKERS] ToDo: fast update of arrays with fixed length fields for PL/pgSQL

2013/11/25 Tom Lane > Heikki Linnakangas writes: > > In general, I'm not convinced this patch is worth the trouble. The > > speedup isn't all that great; manipulating large arrays in PL/pgSQL is > > still so slow that if you care about performance you'll want to rewrite > > your function in some

Re: [HACKERS] PostgreSQL Service on Windows does not start. ~ "is not a valid Win32 application"

On 25 November 2013, Rajeev Rastogi Wrote: > > > One suggestion: > > > Instead of using sizeof(cmdLine), > > > a. Can't we use strlen (hence small 'for' loop). > > > b. Or use memmove to move one byte. > > > > I looked at this patch a bit. I agree that we need to fix > > pgwin32_CommandLine t

Re: [HACKERS] ToDo: fast update of arrays with fixed length fields for PL/pgSQL

2013/11/25 Heikki Linnakangas > On 07.10.2013 17:00, Pavel Stehule wrote: > >> Hello >> >> I fixed patch - there was a missing cast to domain when it was used (and >> all regress tests are ok now). >> > > This doesn't work correctly for varlen datatypes. I modified your > quicksort example to wor

[HACKERS] psql shows line number

Hi all, When I execute query which contains error, the server returns error with line number. ERROR: relation "hoge" does not exist LINE 35: hoge; But when query is long, I was not sure the location where I wrote wrong SQL. Does the psql have option which shows line number? If no, I'm thinking

Re: [HACKERS] TODO: Split out pg_resetxlog output into pre- and post-sections

On 26 November 2013, Amit Kapila Wrote: > Further Review of this patch: > a. there are lot of trailing whitespaces in patch. Fixed. > b. why to display 'First log segment after reset' in 'Currrent > pg_control values' section as now the same information > is available in new section "Values

Re: [HACKERS] Completing PL support for Event Triggers

I made one significant change in the PL/Perl patch. You had this in plperl_event_trigger_handler(): + /* +* Create the call_data before connecting to SPI, so that it is not +* allocated in the SPI memory context +*/ + current_call_data = (plperl_call_data *) pa

Re: [HACKERS] Get more from indices.

Thank you for pointing out. > > the attched pathkey_and_uniqueindx_v4_20131122.patch is changed as > > follows. > > The patch is compiled successfully and passes all regression tests. Also, > the patch works well for the tests shown in an earlier email from > Horiguchi-san. But in this version

Re: [HACKERS] Sequence Access Method WIP

On 11/25/13 12:00, Simon Riggs wrote: On 25 November 2013 04:01, Heikki Linnakangas wrote: The proposed changes to alloc() would still suffer from all the problems that I complained about. Adding a new API alongside doesn't help with that. You made two proposals. I suggested implementing bot

Re: [HACKERS] Sequence Access Method WIP

On 11/24/13 19:15, Simon Riggs wrote: On 18 November 2013 07:36, Heikki Linnakangas wrote: On 14.11.2013 22:10, Simon Riggs wrote: Includes test extension which allows sequences without gaps - "gapless". I realize this is just for demonstration purposes, but it's worth noting that it doesn'

Re: [HACKERS] PL/Python: domain over array support

On Tue, Nov 26, 2013 at 12:23:48AM +0200, Heikki Linnakangas wrote: > The new behavior is clearly better, but it is an incompatibility > nonetheless. I don't do anything with PL/python myself, so I don't > have a good feel of how much that'll break people's applications. > Probably not much I guess

Re: [HACKERS] Extension Templates S03E11

Hi, Heikki Linnakangas writes: > I still don't like this. What I suggested back in December was to have a > simple mechanism to upload an extension zip file to the server via libpq > (http://www.postgresql.org/message-id/50bf80a6.20...@vmware.com). The idea > developed from that into the concept

Re: [HACKERS] Show lossy heap block info in EXPLAIN ANALYZE for bitmap heap scan

Amit Khandekar wrote: > On 25 November 2013 13:37, Etsuro Fujita wrote: >> So, my question is, we should show the number of exact/lossy pages in a >> TIDBitmap, not the number of these pages that has been fetched in the bitmap >> heap scan? > Yes, I agree that rather than looking at the bitmap