Re: [HACKERS] Slowness of extended protocol

On Tue, Aug 16, 2016 at 4:48 PM, Andres Freund wrote: > One approach to solving this, without changing the protocol, would be to > "fuse" parse/bind/execute/sync together, by peeking ahead in the > protocol stream. When that combination is seen looking ahead (without >

Re: [HACKERS] Block level parallel vacuum WIP

Robert Haas wrote: > On Tue, Aug 23, 2016 at 11:17 AM, Alvaro Herrera > wrote: > > Robert Haas wrote: > >> 2. When you finish the heap scan, or when the array of dead tuple IDs > >> is full (or very nearly full?), perform a cycle of index vacuuming. > >> For now, have

Re: [HACKERS] Index Onlys Scan for expressions

On Tue, Aug 16, 2016 at 2:43 AM, Alexander Korotkov wrote:g of pg_operator.oprassociative... > Another problem is computational complexity of such transformations. AFAIR, > few patches for making optimizer smarter with expressions were already > rejected because of

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

Thank you everyone for great comments! > have a permanent pg_class which holds the records for permanent tables > and an *unlogged* table, say pg_class_unlogged, which holds records > for temporary tables. Now everybody can see everybody else's data, > yet we don't have to create permanent

Re: [HACKERS] Logical decoding of sequence advances, part II

On Tue, Aug 23, 2016 at 9:36 AM, Kevin Grittner wrote: > On Tue, Aug 23, 2016 at 9:07 AM, Kevin Grittner wrote: >> On Tue, Aug 23, 2016 at 7:40 AM, Craig Ringer wrote: >>> On 23 Aug 2016 20:10, "Kevin Grittner"

Re: [HACKERS] Logical decoding of sequence advances, part II

On 2016-08-23 07:26:31 -0500, Kevin Grittner wrote: > On Tue, Aug 23, 2016 at 7:10 AM, Kevin Grittner wrote: > > On Mon, Aug 22, 2016 at 6:39 PM, Craig Ringer wrote: > > >> Could you provide an example of a case where xacts replayed in > >> commit order

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On 23 August 2016 at 22:18, Robert Haas wrote: > On Mon, Aug 22, 2016 at 8:55 PM, Craig Ringer > wrote: > > Updated patch series attached. As before, 0-4 intended for commit, 5 just > > because it'll be handy to have around for people doing

Re: [HACKERS] Server crash due to SIGBUS(Bus Error) when trying to access the memory created using dsm_create().

On Mon, Aug 22, 2016 at 8:18 PM, Thomas Munro wrote: > On Tue, Aug 23, 2016 at 8:41 AM, Robert Haas wrote: >> We could test to see how much it slows things down. But it >> may be worth paying the cost even if it ends up being kinda

Re: [HACKERS] multivariate statistics (v19)

On Tue, Aug 2, 2016 at 9:58 PM, Tomas Vondra wrote: > Attached is v19 of the "multivariate stats" patch series - essentially v18 > rebased on top of current master. Tom: ISTR that you were going to try to look at this patch set. It seems from the discussion that

Re: [HACKERS] Block level parallel vacuum WIP

On Tue, Aug 23, 2016 at 10:50 PM, Robert Haas wrote: > On Tue, Aug 23, 2016 at 7:02 AM, Masahiko Sawada > wrote: >> I'd like to propose block level parallel VACUUM. >> This feature makes VACUUM possible to use multiple CPU cores. > > Great. This is

Re: [HACKERS] Block level parallel vacuum WIP

On Tue, Aug 23, 2016 at 11:17 AM, Alvaro Herrera wrote: > Robert Haas wrote: >> 2. When you finish the heap scan, or when the array of dead tuple IDs >> is full (or very nearly full?), perform a cycle of index vacuuming. >> For now, have each worker process a separate

Re: [HACKERS] Logical decoding of sequence advances, part II

On 24 August 2016 at 00:26, Kevin Grittner wrote: > On Tue, Aug 23, 2016 at 9:36 AM, Kevin Grittner wrote: > > On Tue, Aug 23, 2016 at 9:07 AM, Kevin Grittner > wrote: > >> On Tue, Aug 23, 2016 at 7:40 AM, Craig Ringer

Re: [HACKERS] Proposal for CSN based snapshots

On 08/22/2016 08:38 PM, Andres Freund wrote: On 2016-08-22 20:32:42 +0300, Heikki Linnakangas wrote: I remember seeing ProcArrayLock contention very visible earlier, but I can't hit that now. I suspect you'd still see contention on bigger hardware, though, my laptop has oly 4 cores. I'll have

Re: [HACKERS] Logical decoding of sequence advances, part II

On 23/08/16 15:59, Robert Haas wrote: On Mon, Aug 22, 2016 at 4:32 PM, Andres Freund wrote: On 2016-08-22 16:29:12 -0400, Robert Haas wrote: So, I wish I could give you some better advice on this topic, but sadly I am not an expert in this area. However, it seems to me

Re: [HACKERS] Block level parallel vacuum WIP

Robert Haas wrote: > 2. When you finish the heap scan, or when the array of dead tuple IDs > is full (or very nearly full?), perform a cycle of index vacuuming. > For now, have each worker process a separate index; extra workers just > wait. Perhaps use the condition variable patch that I posted

Re: [HACKERS] Block level parallel vacuum WIP

On 2016-08-23 12:17:30 -0400, Robert Haas wrote: > On Tue, Aug 23, 2016 at 11:17 AM, Alvaro Herrera > wrote: > > Robert Haas wrote: > >> 2. When you finish the heap scan, or when the array of dead tuple IDs > >> is full (or very nearly full?), perform a cycle of index

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian wrote: > The Postgres docs specify that kB is based on 1024 or 2^10: > > https://www.postgresql.org/docs/9.6/static/functions-admin.html > > Note: The units kB, MB, GB and TB used by the functions >

Re: [HACKERS] Proposal for CSN based snapshots

On 2016-08-23 18:18:57 +0300, Heikki Linnakangas wrote: > I installed Greg Smith's pgbench-tools kit on that server, and ran some > tests. I'm seeing some benefit on "pgbench -N" workload, but only after > modifying the test script to use "-M prepared", and using Unix domain > sockets instead of

Re: [HACKERS] Slowness of extended protocol

On 2016-08-23 11:42:53 -0400, Robert Haas wrote: > I think this could possibly be done, but it seems a lot better to me > to just bite the bullet and add a new protocol message. That was > proposed by Tom Lane on July 31st and I think it's still by far the > best and easiest idea proposed, except

Re: [HACKERS] Question about MVCC-unsafe commands

On Tue, Aug 23, 2016 at 10:10 AM, Antonin Houska wrote: > I'm failing to understand why [1] mentions "table-rewriting forms of ALTER > TABLE" besides TRUNCATE command. > > For TRUNCATE it seems clear: if transaction A takes the snapshot before it > accesses the table first time

Re: [HACKERS] Logical decoding of sequence advances, part II

On 24 August 2016 at 00:50, Andres Freund wrote: > On 2016-08-23 07:26:31 -0500, Kevin Grittner wrote: > > On Tue, Aug 23, 2016 at 7:10 AM, Kevin Grittner > wrote: > > [an explanation of SSI anomalies] > I've generally a bit of difficulty to see this as a

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

On Tue, Aug 23, 2016 at 01:30:29PM -0400, Robert Haas wrote: > On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian wrote: > > and the units were copied when pg_size_pretty() was implemented. These > > units are based on the International System of Units (SI)/metric. > > However, the

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

On Tue, Aug 23, 2016 at 01:45:44PM -0400, Robert Haas wrote: > On Tue, Aug 23, 2016 at 1:43 PM, Bruce Momjian wrote: > > On Tue, Aug 23, 2016 at 01:30:29PM -0400, Robert Haas wrote: > >> On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian wrote: > >> > and the

Re: [HACKERS] Logical decoding of sequence advances, part II

On Tue, Aug 23, 2016 at 11:50 AM, Andres Freund wrote: > On 2016-08-23 07:26:31 -0500, Kevin Grittner wrote: >> On Tue, Aug 23, 2016 at 7:10 AM, Kevin Grittner wrote: >> > On Mon, Aug 22, 2016 at 6:39 PM, Craig Ringer >> > wrote: >>

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

On Tue, Aug 23, 2016 at 11:35:35AM -0700, Andres Freund wrote: > On 2016-08-23 14:33:15 -0400, Bruce Momjian wrote: > > On Tue, Aug 23, 2016 at 02:31:26PM -0400, Robert Haas wrote: > > > On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian wrote: > > > > That's why I was asking you to

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

Bruce Momjian wrote: > On Tue, Aug 23, 2016 at 02:31:26PM -0400, Robert Haas wrote: > > On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian wrote: > > > That's why I was asking you to comment on the final patch, which I am > > > planning to apply to PG 10 soon. > > > > Oh, OK. I

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian wrote: > That's why I was asking you to comment on the final patch, which I am > planning to apply to PG 10 soon. Oh, OK. I didn't understand that that was what you are asking. I don't find either of your proposed final patches

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

On Tue, Aug 23, 2016 at 1:47 PM, Bruce Momjian wrote: >> I have already read the entire thread, and replied only after reading >> all messages. > > Well, what are you replying to then? Your original message. I'm arguing that we should not change the behavior, as you proposed

Re: [HACKERS] dsm_unpin_segment

On Mon, Aug 22, 2016 at 10:04 AM, Amit Kapila wrote: > On Mon, Aug 22, 2016 at 6:06 PM, Thomas Munro > wrote: >> On Tue, Aug 23, 2016 at 12:07 AM, Amit Kapila >> wrote: >>> + int control_slot = -1; >>> ... >>> +

Re: [HACKERS] patch: function xmltable

Hi 2016-08-19 10:58 GMT+02:00 Pavel Stehule : > Hi > > I am sending implementation of xmltable function. The code should to have > near to final quality and it is available for testing. > > I invite any help with documentation and testing. > new update - the work with

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

On Tue, Aug 23, 2016 at 02:31:26PM -0400, Robert Haas wrote: > On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian wrote: > > That's why I was asking you to comment on the final patch, which I am > > planning to apply to PG 10 soon. > > Oh, OK. I didn't understand that that was

Re: [HACKERS] Changed SRF in targetlist handling

On 2016-08-17 17:41:28 -0700, Andres Freund wrote: > a) Allow to avoid using a tuplestore for SRF_PERCALL SRFs in ROWS FROM - >otherwise our performance would regress noticeably in some cases. To demonstrate the problem: master: =# COPY (SELECT generate_series(1, 5000)) TO '/dev/null';

Re: [HACKERS] Question about MVCC-unsafe commands

Robert Haas wrote: > On Tue, Aug 23, 2016 at 10:10 AM, Antonin Houska wrote: > CLUSTER preserves xmin/xmax when rewriting, but ALTER TABLE does not. Indeed, CLUSTER was the command I picked for my experiments. I didn't expect such a subtle difference.

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

On Tue, Aug 23, 2016 at 1:43 PM, Bruce Momjian wrote: > On Tue, Aug 23, 2016 at 01:30:29PM -0400, Robert Haas wrote: >> On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian wrote: >> > and the units were copied when pg_size_pretty() was implemented. These >> >

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

On 2016-08-23 14:33:15 -0400, Bruce Momjian wrote: > On Tue, Aug 23, 2016 at 02:31:26PM -0400, Robert Haas wrote: > > On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian wrote: > > > That's why I was asking you to comment on the final patch, which I am > > > planning to apply to PG

Re: [HACKERS] Slowness of extended protocol

Just a note from me - I also agree this thread evolved (or rather devolved) in a rather unproductive and strange way. One important note that came out, though, is that adding a new client message does have a backwards compatibility issue - intelligent proxies such as pgbouncer/pgpool will

Re: [HACKERS] "Some tests to cover hash_index"

Hi All, I have reverified the code coverage for hash index code using the test file (commit-hash_coverage_test) attached with this mailing list and have found that some of the code in _hash_squeezebucket() function flow is not being covered. For this i have added a small testcase on top of

Re: [HACKERS] "Some tests to cover hash_index"

Hi, I missed to attach the patch in my previous mail. Here i attach the patch. With Regards, Ashutosh Sharma EnterpriseDB:http://www.enterprisedb.com On Tue, Aug 23, 2016 at 11:47 AM, Ashutosh Sharma wrote: > Hi All, > > I have reverified the code coverage for hash

Re: [HACKERS] Write Ahead Logging for Hash Indexes

Hi All, Following are the steps that i have followed to verify the WAL Logging of hash index, 1. I used Mithun's patch to improve coverage of hash index code [1] to verify the WAL Logging of hash index. Firstly i have confirmed if all the XLOG records associated with hash index are being covered

Re: [HACKERS] Patch: initdb: "'" for QUOTE_PATH (non-windows)

Thanks for committing it Tom! Thank you all for your help. I really like the Postgres project! If there's anything that especially needs worked on let me know, I'd love to help. Best, Ryan

Re: [HACKERS] Index Onlys Scan for expressions

Hi, I've tried your indexonlypatch5.patch against REL9_6_BETA3. Here are some results. TL;DR: 1) <> does not support index-only scan for index (type, upper(vc) varchar_pattern_ops). 3) <<(... where type=42 offset 0) where upper_vc like '%ABC%'>> does trigger index-only scan. IOS reduces number

Re: [HACKERS] [RFC] Change the default of update_process_title to off

On Tue, Aug 23, 2016 at 1:44 PM, Bruce Momjian wrote: >> [Windows] >> #clients onoff >> 12 29793 38169 >> 24 31587 87237 >> 48 32588 83335 >> 96 34261 67668 > > This ranges from a 28% to a 97% speed improvement on Windows! Those are > not typos! This is

[HACKERS] dump/restore doesn't preserve row ordering?

I happened to notice, while experimenting with the data set used in the SPGIST-for-inet thread, that loading the supplied pg_dump script and immediately dumping it does not reproduce the row order appearing in the original dump script. I thought maybe this had something to do with the

Re: [HACKERS] pg_dump with tables created in schemas created by extensions

Hi Michael, 2016-08-23 5:02 GMT-03:00 Michael Paquier : > On Sat, Aug 13, 2016 at 6:58 AM, Martín Marqués > wrote: >> I believe the fix will be simple after the back and forth mails with >> Michael, Stephen and Tom. I will work on that later,

Re: [HACKERS] [RFC] Change the default of update_process_title to off

On Tue, Aug 23, 2016 at 01:58:02PM -0700, Peter Geoghegan wrote: > On Tue, Aug 23, 2016 at 1:44 PM, Bruce Momjian wrote: > >> [Windows] > >> #clients onoff > >> 12 29793 38169 > >> 24 31587 87237 > >> 48 32588 83335 > >> 96 34261 67668 > > > > This ranges

Re: [HACKERS] pg_dump with tables created in schemas created by extensions

Hi, 2016-08-23 16:46 GMT-03:00 Martín Marqués : > > I will add tests for sequence and functions as you mention and test again. > > Then I'll check if other tests should be added as well. I found quite some other objects we should be checking as well, but this will add

Re: [HACKERS] Write Ahead Logging for Hash Indexes

Hi Amit, Thanks for working on this. When building with --enable-cassert, I get compiler warning: hash.c: In function 'hashbucketcleanup': hash.c:722: warning: 'new_bucket' may be used uninitialized in this function After an intentionally created crash, I get an Assert triggering: TRAP:

[HACKERS] Remove superuser() checks from pgstattuple

Greetings, Attached is an rebased and updated patch to remove the explicit superuser() checks from the contrib extension pgstattuple, in favor of using the GRANT system to control access, and give the admin flexibility to GRANT access to this function without having to write wrapper functions,

Re: [HACKERS] [RFC] Change the default of update_process_title to off

On Tue, Aug 16, 2016 at 11:53:25AM +0200, Magnus Hagander wrote: > On Fri, Aug 5, 2016 at 12:25 PM, Tsunakawa, Takayuki < > tsunakawa.ta...@jp.fujitsu.com> wrote: > > > From: Tom Lane [mailto:t...@sss.pgh.pa.us] > > Yeah, I think I agree.  It would be bad to disable it by default on >

Re: [HACKERS] dump/restore doesn't preserve row ordering?

On 2016-08-23 17:22:03 -0400, Tom Lane wrote: > I happened to notice, while experimenting with the data set used > in the SPGIST-for-inet thread, that loading the supplied pg_dump > script and immediately dumping it does not reproduce the row order > appearing in the original dump script. I

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On Tue, Aug 23, 2016 at 7:11 PM, Tomas Vondra wrote: > On 08/22/2016 10:32 PM, Robert Haas wrote: >> >> >> ... >> >> 1. The number of tables for which we would need to add a duplicate, >> unlogged table is formidable. You need pg_attribute, pg_attrdef, >>

Re: [HACKERS] pg_dump with tables created in schemas created by extensions

On 8/23/16 3:34 PM, Martín Marqués wrote: I found quite some other objects we should be checking as well, but this will add some duplication to the tests, as I'd just copy (with minor changes) what's in src/bin/pg_dump/t/002_pg_dump.pl I can't think of a way to avoid this duplication, not that

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On 08/22/2016 10:32 PM, Robert Haas wrote: ... 1. The number of tables for which we would need to add a duplicate, unlogged table is formidable. You need pg_attribute, pg_attrdef, pg_constraint, pg_description, pg_type, pg_trigger, pg_rewrite, etc. And the backend changes needed so that we

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On 2016-08-23 19:18:04 -0300, Claudio Freire wrote: > On Tue, Aug 23, 2016 at 7:11 PM, Tomas Vondra > wrote: > > Could someone please explain how the unlogged tables are supposed to fix the > > catalog bloat problem, as stated in the initial patch submission? We'd

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On 08/24/2016 12:18 AM, Claudio Freire wrote: On Tue, Aug 23, 2016 at 7:11 PM, Tomas Vondra wrote: On 08/22/2016 10:32 PM, Robert Haas wrote: ... 1. The number of tables for which we would need to add a duplicate, unlogged table is formidable. You need

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On Tue, Aug 23, 2016 at 7:20 PM, Andres Freund wrote: >> Wouldn't more aggressive vacuuming of catalog tables fix the bloat? > > Not really in my experience, at least not without more drastic vacuum > changes. The issue is that if you have a single "long running" > transaction

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On 2016-08-23 19:33:33 -0300, Claudio Freire wrote: > On Tue, Aug 23, 2016 at 7:20 PM, Andres Freund wrote: > >> Wouldn't more aggressive vacuuming of catalog tables fix the bloat? > > > > Not really in my experience, at least not without more drastic vacuum > > changes. The

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On Tue, Aug 23, 2016 at 7:25 PM, Tomas Vondra wrote: >>> Could someone please explain how the unlogged tables are supposed to fix >>> the >>> catalog bloat problem, as stated in the initial patch submission? We'd >>> still >>> need to insert/delete the catalog rows

Re: [HACKERS] Block level parallel vacuum WIP

On Tue, Aug 23, 2016 at 10:50 PM, Amit Kapila wrote: > On Tue, Aug 23, 2016 at 6:11 PM, Michael Paquier > wrote: >> On Tue, Aug 23, 2016 at 8:02 PM, Masahiko Sawada >> wrote: >>> As for PoC, I implemented parallel

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On Tue, Aug 23, 2016 at 9:12 PM, Tomas Vondra wrote: > On 08/24/2016 12:38 AM, Claudio Freire wrote: >> >> On Tue, Aug 23, 2016 at 7:25 PM, Tomas Vondra >> wrote: > > Could someone please explain how the unlogged tables are

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

On Wed, Aug 24, 2016 at 10:07 AM, Gavin Flower < gavinflo...@archidevsys.co.nz> wrote: > On 24/08/16 12:02, neha khatri wrote: > >> >Andres Freund > writes: >> >> On 2016-08-22 13:54:43 -0400, Robert Haas wrote: >> >> On Sat, Aug 20, 2016 at 11:17

Re: [HACKERS] [RFC] Change the default of update_process_title to off

From: Peter Geoghegan [mailto:p...@heroku.com] > On Tue, Aug 23, 2016 at 1:44 PM, Bruce Momjian wrote: > >> [Windows] > >> #clients onoff > >> 12 29793 38169 > >> 24 31587 87237 > >> 48 32588 83335 > >> 96 34261 67668 > > > > This ranges from a 28% to a

Re: [HACKERS] recent compiler warnings

On 2016-08-23 19:54:39 -0700, Jeff Janes wrote: > Sorry for starting a new thread, I can't find the correct one to reply to. > > Using: gcc version 4.8.3 20140627 [gcc-4_8-branch revision 212064] (SUSE > Linux) > > commit ed0097e4f9e6b1 has introduced two compiler warnings: > > gistutil.c: In

Re: [HACKERS] Oddity in EXPLAIN for foreign/custom join pushdown plans

On 2016/08/10 5:19, Robert Haas wrote: On Mon, Aug 8, 2016 at 12:22 AM, Etsuro Fujita wrote: One thing we need to do to leave that as is would be to fix a bug that I pointed out upthred. Let me explain about that again. The EXPLAIN command selects relation

Re: [HACKERS] Logical decoding of sequence advances, part II

On Tue, Aug 23, 2016 at 9:07 AM, Kevin Grittner wrote: > On Tue, Aug 23, 2016 at 7:40 AM, Craig Ringer wrote: >> On 23 Aug 2016 20:10, "Kevin Grittner" wrote: >>> >>> On Mon, Aug 22, 2016 at 6:39 PM, Craig Ringer

Re: [HACKERS] Block level parallel vacuum WIP

On Tue, Aug 23, 2016 at 9:40 PM, Alexander Korotkov wrote: > On Tue, Aug 23, 2016 at 3:32 PM, Tom Lane wrote: >> >> Claudio Freire writes: >> > Not only that, but from your description (I haven't read the patch, >> > sorry),

[HACKERS] pgbench - fix stats when using \sleep

Hello devs, When \sleep is used within a pgbench script it resets txn_scheduled which is used for computing stats about the transaction, resulting in absurd statistics: latency average = 0.649 ms *** ??? *** ... script statistics: - statement latencies in milliseconds: 0.235

Re: [HACKERS] UTF-8 docs?

On Mon, 22 Aug 2016 10:53:25 -0400 Peter Eisentraut wrote: > On 8/22/16 9:32 AM, Tatsuo Ishii wrote: > > I don't know what kind of problem you are seeing with encoding > > handling, but at least UTF-8 is working for Japanese, French and > > Russian. > > Those

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On 24/08/16 15:36, Amit Kapila wrote: On Wed, Aug 24, 2016 at 8:54 AM, Mark Kirkwood wrote: On 24/08/16 12:09, Mark Kirkwood wrote: On 23/08/16 15:24, Amit Kapila wrote: Thoughts? Note - To use this patch, first apply latest version of concurrent hash index

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Wed, Aug 24, 2016 at 9:53 AM, Mark Kirkwood wrote: > On 24/08/16 15:36, Amit Kapila wrote: >> >> On Wed, Aug 24, 2016 at 8:54 AM, Mark Kirkwood >> wrote: >>> >> >> Can you get the call stacks? >> > > For every stuck backend? (just

Re: [HACKERS] LSN as a recovery target

On Tue, Aug 23, 2016 at 8:50 PM, Michael Paquier wrote: > On Tue, Aug 23, 2016 at 6:10 PM, Simon Riggs wrote: >> On 23 August 2016 at 09:39, Petr Jelinek wrote: >> >>> Looks very reasonable to me (both patches). Thanks for

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On 24/08/16 16:33, Amit Kapila wrote: On Wed, Aug 24, 2016 at 9:53 AM, Mark Kirkwood wrote: On 24/08/16 15:36, Amit Kapila wrote: On Wed, Aug 24, 2016 at 8:54 AM, Mark Kirkwood wrote: Can you get the call stacks? For every stuck

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

Claudio Freire wrote: > After looking at it from a birdseye view, I agree it's conceptually > complex (reading HeapTupleSatisfiesSelf already makes one dizzy). > > But other than that, the implementation seems rather simple. It seems > to me, if one figures out that it is safe to do so

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Wed, Aug 24, 2016 at 2:37 AM, Jeff Janes wrote: > Hi Amit, > > Thanks for working on this. > > When building with --enable-cassert, I get compiler warning: > > hash.c: In function 'hashbucketcleanup': > hash.c:722: warning: 'new_bucket' may be used uninitialized in this

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On 24/08/16 16:52, Mark Kirkwood wrote: On 24/08/16 16:33, Amit Kapila wrote: On Wed, Aug 24, 2016 at 9:53 AM, Mark Kirkwood wrote: On 24/08/16 15:36, Amit Kapila wrote: On Wed, Aug 24, 2016 at 8:54 AM, Mark Kirkwood wrote: Can

Re: [HACKERS] pg_dump with tables created in schemas created by extensions

On Wed, Aug 24, 2016 at 5:34 AM, Martín Marqués wrote: > Hi, > > 2016-08-23 16:46 GMT-03:00 Martín Marqués : >> >> I will add tests for sequence and functions as you mention and test again. >> >> Then I'll check if other tests should be added as

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On 08/24/2016 12:38 AM, Claudio Freire wrote: On Tue, Aug 23, 2016 at 7:25 PM, Tomas Vondra wrote: Could someone please explain how the unlogged tables are supposed to fix the catalog bloat problem, as stated in the initial patch submission? We'd still need to

Re: [HACKERS] Patch: initdb: "'" for QUOTE_PATH (non-windows)

On Wed, Aug 24, 2016 at 9:55 AM, Alvaro Herrera wrote: > Ryan Murphy wrote: >> Thanks for committing it Tom! Thank you all for your help. >> >> I really like the Postgres project! If there's anything that especially >> needs worked on let me know, I'd love to help. > >

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

>Andres Freund writes: >> On 2016-08-22 13:54:43 -0400, Robert Haas wrote: >> On Sat, Aug 20, 2016 at 11:17 AM, Tom Lane wrote: I'm inclined to suggest you forget this approach and propose a single counter for "SQL commands executed", which

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On 23/08/16 15:24, Amit Kapila wrote: Thoughts? Note - To use this patch, first apply latest version of concurrent hash index patch [2]. [1] - https://commitfest.postgresql.org/10/647/ [2] -

Re: [HACKERS] Patch: initdb: "'" for QUOTE_PATH (non-windows)

Ryan Murphy wrote: > Thanks for committing it Tom! Thank you all for your help. > > I really like the Postgres project! If there's anything that especially > needs worked on let me know, I'd love to help. https://wiki.postgresql.org/wiki/Todo -- Álvaro Herrera

Re: [HACKERS] Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On Tue, Aug 23, 2016 at 8:50 PM, Greg Stark wrote: > On Tue, Aug 23, 2016 at 4:15 PM, Aleksander Alekseev > wrote: >> Frankly I have much more faith in Tom's idea of using virtual part of the >> catalog for all temporary tables, i.e turning all temporary

[HACKERS] Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On Tue, Aug 23, 2016 at 4:15 PM, Aleksander Alekseev wrote: > Frankly I have much more faith in Tom's idea of using virtual part of the > catalog for all temporary tables, i.e turning all temporary tables into > "fast" temporary tables. Instead of introducing a new type

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

On 24/08/16 12:02, neha khatri wrote: >Andres Freund > writes: >> On 2016-08-22 13:54:43 -0400, Robert Haas wrote: >> On Sat, Aug 20, 2016 at 11:17 AM, Tom Lane > wrote: I'm inclined to suggest

Re: [HACKERS] Duplicate prototype for socket_set_nonblocking.

On Thu, Jul 28, 2016 at 9:12 PM, Kyotaro HORIGUCHI wrote: > Looking into pqcomm.c, I noticed that the prototype of > socket_set_nonblocking defined twice. Actually the prototype is > not necessary at all but one may remain as a convention. > > It doesn't no harm

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

On Tue, Aug 23, 2016 at 01:53:25PM -0400, Robert Haas wrote: > On Tue, Aug 23, 2016 at 1:47 PM, Bruce Momjian wrote: > >> I have already read the entire thread, and replied only after reading > >> all messages. > > > > Well, what are you replying to then? > > Your original

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On Tue, Aug 23, 2016 at 12:59 PM, Craig Ringer wrote: > Also fine by me. You're right, keep it simple. It means the potential set of > values isn't discoverable the same way, but ... meh. Using it usefully means > reading the docs anyway. > > The remaining 2 patches of

Re: [HACKERS] SP-GiST support for inet datatypes

I've pushed this patch with mostly (not entirely) cosmetic adjustments. I still think it'd be worth looking into why the produced index is larger than the GiST equivalent, and for that matter exactly why the GiST equivalent is so much slower to search. regards, tom lane

Re: [HACKERS] dump/restore doesn't preserve row ordering?

Andres Freund writes: > On 2016-08-23 17:22:03 -0400, Tom Lane wrote: >> I can't immediately think of a reason for this. In everyday >> updates you could theorize about effects like autovacuum >> asynchonously updating the FSM, but surely the FSM should have no >> impact on

[HACKERS] recent compiler warnings

Sorry for starting a new thread, I can't find the correct one to reply to. Using: gcc version 4.8.3 20140627 [gcc-4_8-branch revision 212064] (SUSE Linux) commit ed0097e4f9e6b1 has introduced two compiler warnings: gistutil.c: In function 'gistproperty': gistutil.c:855:16: warning: variable

Re: [HACKERS] recent compiler warnings

Andres Freund writes: > On 2016-08-23 19:54:39 -0700, Jeff Janes wrote: >> commit ed0097e4f9e6b1 has introduced two compiler warnings: > That's probably when compiling without assertions, right? rd_index is > only read from within Assert()'s Probably needs a >

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On 24/08/16 12:09, Mark Kirkwood wrote: On 23/08/16 15:24, Amit Kapila wrote: Thoughts? Note - To use this patch, first apply latest version of concurrent hash index patch [2]. [1] - https://commitfest.postgresql.org/10/647/ [2] -

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Wed, Aug 24, 2016 at 8:54 AM, Mark Kirkwood wrote: > On 24/08/16 12:09, Mark Kirkwood wrote: >> >> On 23/08/16 15:24, Amit Kapila wrote: >>> >>> >>> Thoughts? >>> >>> Note - To use this patch, first apply latest version of concurrent >>> hash index patch [2]. >>>

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

On Tue, Aug 23, 2016 at 2:33 PM, Bruce Momjian wrote: > Well, the patch was updated several times, and the final version was not > objected to until you objected. It is not clear what you mean by "the final version", because you posted two different final versions. I don't see

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On Wed, Aug 24, 2016 at 2:04 AM, Alvaro Herrera wrote: > Claudio Freire wrote: > >> After looking at it from a birdseye view, I agree it's conceptually >> complex (reading HeapTupleSatisfiesSelf already makes one dizzy). >> >> But other than that, the implementation

[HACKERS] Strange result with LATERAL query

Hi, While playing with LATERAL along with some aggregates in sub-query, I have observed somewhat unusual behavior. Consider following steps: create table tab1(c1 int, c2 int); insert into tab1 select id, 1 from generate_series(1, 3) id; create function sum_tab1(extra int) returns setof bigint

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On 23/08/16 11:27, Craig Ringer wrote: On 23 Aug 2016 16:02, "Petr Jelinek" > wrote: On 23/08/16 02:55, Craig Ringer wrote: On 23 August 2016 at 01:03, Robert Haas

Re: [HACKERS] LSN as a recovery target

On 23 August 2016 at 09:39, Petr Jelinek wrote: > Looks very reasonable to me (both patches). Thanks for doing that. > > I am inclined to mark this as ready for committer. Looking at it now. The messages for recovery_target_lsn don't mention after or before, as do other

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On 23 Aug 2016 16:02, "Petr Jelinek" wrote: > > On 23/08/16 02:55, Craig Ringer wrote: >> >> On 23 August 2016 at 01:03, Robert Haas > > wrote: >> >> >> >> I think you should use underscores to separate all of the

Re: [HACKERS] pg_receivexlog does not report flush position with --synchronous

On Tue, Aug 23, 2016 at 7:34 AM, Gabriele Bartolini wrote: > Looking up the code in more details I see that, unless replication slot > are enabled, pg_receivexlog does not report the flush position (this is a > precaution that's been taken when '--synchronous'

  1   2   >