Re: [HACKERS] Tracking wait event for latches

On Mon, Aug 22, 2016 at 6:46 PM, Alexander Korotkov wrote: > On Mon, Aug 22, 2016 at 12:09 PM, Alexander Korotkov > wrote: >> >> I took a look at your patch. Couple of notes from me. >> >>> const char * >>> GetEventIdentifier(uint16 eventId) >>> { >>> const char *res; >>> switch (eventId) >>> { >

Re: [HACKERS] LSN as a recovery target

On Tue, Aug 23, 2016 at 12:49 AM, Robert Haas wrote: > On Mon, Aug 22, 2016 at 8:28 AM, Michael Paquier > wrote: >> On Mon, Aug 22, 2016 at 7:12 PM, Adrien Nayrat >> wrote: >>> As Julien said, there is nothing to notice that error comes from >>> recovery.conf. >>> My fear would be that an user

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' was probably not around). > Please

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

On 23/08/16 02:55, Craig Ringer wrote: On 23 August 2016 at 01:03, Robert Haas mailto:robertmh...@gmail.com>> wrote: I think you should use underscores to separate all of the words instead of only some of them. ifassigned => if_assigned ifrecent=> if_recent Updated patch series att

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

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, but preferred to > have the tests the show the problem which will also make testing the fix > easier. > > Thoughts?

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

On 23 August 2016 at 08:56, Michael Paquier wrote: > On Tue, Aug 23, 2016 at 7:34 AM, Gabriele Bartolini > wrote: I'd suggest rewording it a bit instead, please see attached. > And of course this needs a backpatch. Agreed, but I'd move all the comments above the block. -- Simon Riggs

Re: [HACKERS] LSN as a recovery target

On 23/08/16 09:33, Michael Paquier wrote: On Tue, Aug 23, 2016 at 12:49 AM, Robert Haas wrote: On Mon, Aug 22, 2016 at 8:28 AM, Michael Paquier wrote: On Mon, Aug 22, 2016 at 7:12 PM, Adrien Nayrat wrote: As Julien said, there is nothing to notice that error comes from recovery.conf. My fea

Re: [HACKERS] LSN as a recovery target

On 08/23/2016 10:39 AM, Petr Jelinek wrote: > On 23/08/16 09:33, Michael Paquier wrote: >> On Tue, Aug 23, 2016 at 12:49 AM, Robert Haas >> wrote: >>> On Mon, Aug 22, 2016 at 8:28 AM, Michael Paquier >>> wrote: On Mon, Aug 22, 2016 at 7:12 PM, Adrien Nayrat wrote: > As Julien said,

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 targets... e.g. rec

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 words >> instead of only some of them. >> >> >

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" mailto:p...@2ndquadrant.com>> wrote: On 23/08/16 02:55, Craig Ringer wrote: On 23 August 2016 at 01:03, Robert Haas >> wrote

[HACKERS] Block level parallel vacuum WIP

Hi all, I'd like to propose block level parallel VACUUM. This feature makes VACUUM possible to use multiple CPU cores. Vacuum Processing Logic === PostgreSQL VACUUM processing logic consists of 2 phases, 1. Collecting dead tuple locations on heap. 2. Reclaiming dead tuples from h

Re: [HACKERS] LSN as a recovery target

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 doing that. >> >> I am inclined to mark this as ready for committer. > > Looking at it now. > > The messages for recovery_target_lsn do

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

On Mon, Aug 22, 2016 at 6:39 PM, Craig Ringer wrote: > On 23 Aug 2016 05:43, "Kevin Grittner" wrote: >> On Mon, Aug 22, 2016 at 3:29 PM, Robert Haas wrote: >> >>> it seems to me that >>> this is just one facet of a much more general problem: given two >>> transactions T1 and T2, the order of rep

[HACKERS] comment typo lmgr.c

comment typo in src/backend/storage/lmgr.c attached Erik Rijkers--- src/backend/storage/lmgr/lmgr.c.orig 2016-08-23 14:04:33.0 +0200 +++ src/backend/storage/lmgr/lmgr.c 2016-08-23 14:05:41.0 +0200 @@ -33,7 +33,7 @@ * constraint violations. It's theoretically possible that a b

Re: [HACKERS] Block level parallel vacuum WIP

On Tue, Aug 23, 2016 at 8:02 AM, Masahiko Sawada wrote: > > 2. Vacuum table and index (after 1 transaction executed) > 1 worker : 12 sec > 2 workers : 49 sec > 3 workers : 54 sec > 4 workers : 53 sec > > As a result of my test, since multiple process could frequently try to > acquire

Re: [HACKERS] Block level parallel vacuum WIP

I repeat your test on ProLiant DL580 Gen9 with Xeon E7-8890 v3. pgbench -s 100 and command vacuum pgbench_acounts after 10_000 transactions: with: alter system set vacuum_cost_delay to DEFAULT; parallel_vacuum_workers | time 1 | 138.703,263 ms 2 | 83.

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

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 will produce incorrect results? > > https://wiki.postgresql.org/wiki/SSI#Deposit_Report > > ... where T3

Re: [HACKERS] distinct estimate of a hard-coded VALUES list

Tomas Vondra writes: > On 08/22/2016 07:42 PM, Alvaro Herrera wrote: >> Also, if we patch it this way and somebody has a slow query because of a >> lot of duplicate values, it's easy to solve the problem by >> de-duplicating. But with the current code, people that have the >> opposite problem has

Re: [HACKERS] Block level parallel vacuum WIP

Claudio Freire writes: > Not only that, but from your description (I haven't read the patch, > sorry), you'd be scanning the whole index multiple times (one per > worker). What about pointing each worker at a separate index? Obviously the degree of concurrency during index cleanup is then limite

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

On 23 Aug 2016 20:10, "Kevin Grittner" wrote: > > On Mon, Aug 22, 2016 at 6:39 PM, Craig Ringer wrote: > > On 23 Aug 2016 05:43, "Kevin Grittner" wrote: > >> On Mon, Aug 22, 2016 at 3:29 PM, Robert Haas wrote: > >> > >>> it seems to me that > >>> this is just one facet of a much more general pr

Re: [HACKERS] Block level parallel vacuum WIP

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), you'd be scanning the whole index multiple times (one per > > worker). > > What about pointing each worker at a separate index? Obviously

Re: [HACKERS] Block level parallel vacuum WIP

On Tue, Aug 23, 2016 at 8:02 PM, Masahiko Sawada wrote: > As for PoC, I implemented parallel vacuum so that each worker > processes both 1 and 2 phases for particular block range. > Suppose we vacuum 1000 blocks table with 4 workers, each worker > processes 250 consecutive blocks in phase 1 and th

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

Hi Simon and Michael, 2016-08-23 10:39 GMT+02:00 Simon Riggs : > > Agreed, but I'd move all the comments above the block. > That's fine with me. Thanks, Gabriele -- Gabriele Bartolini - 2ndQuadrant Italia - Director PostgreSQL Training, Services and Support gabriele.bartol...@2ndquadrant.it |

Re: [HACKERS] Block level parallel vacuum WIP

On 23.08.2016 15:41, Michael Paquier wrote: On Tue, Aug 23, 2016 at 8:02 PM, Masahiko Sawada wrote: As for PoC, I implemented parallel vacuum so that each worker processes both 1 and 2 phases for particular block range. Suppose we vacuum 1000 blocks table with 4 workers, each worker processes

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

On Tue, Aug 23, 2016 at 9:48 PM, Gabriele Bartolini wrote: > Hi Simon and Michael, > > 2016-08-23 10:39 GMT+02:00 Simon Riggs : >> >> Agreed, but I'd move all the comments above the block. > > > That's fine with me. +1. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgres

Re: [HACKERS] Re: [BUGS] Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5)

On 8/22/16 7:36 PM, Peter Geoghegan wrote: For some reason, both cases involved strings with code points from the Arabic alphabet, even though each case was from a totally unrelated customer database. Do those code points read right to left? Maybe that had an effect? -- Jim Nasby, Data Architec

Re: [HACKERS] Proposal for CSN based snapshots

On Mon, Aug 22, 2016 at 11:11 PM, Robert Haas wrote: > On Mon, Aug 22, 2016 at 1:32 PM, Heikki Linnakangas wrote: >>> But what about the best case? If we create a scenario where there are >>> no open read-write transactions at all and (somehow) lots and lots of >>> ProcArrayLock contention, how

Re: [HACKERS] Block level parallel vacuum WIP

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 vacuum so that each worker >> processes both 1 and 2 phases for particular block range. >> Suppose we vacuum 1000 blocks table with 4 workers,

Re: [HACKERS] Block level parallel vacuum WIP

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 something that I have thought about, too. Andres and Heikki recommended it as a project to me a few PGCons ag

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

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 that >> this is just one facet of a much more general pro

Re: [HACKERS] comment typo lmgr.c

On Tue, Aug 23, 2016 at 8:13 AM, Erik Rijkers wrote: > comment typo in src/backend/storage/lmgr.c attached Committed, thanks. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

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

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 >>> Could you provide an example of a case where xacts replayed in >>> commit order will produce incorrect results? >> >> https://wiki.postgre

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

On Tue, Aug 23, 2016 at 2:17 AM, Ashutosh Sharma wrote: > I have also removed the warning message that we used to get for hash index > like 'WARNING: hash indexes are not WAL-logged and their use is discouraged' > as this message is now no more visible w.r.t hash index after the WAL patch > for

[HACKERS] Question about MVCC-unsafe commands

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 (typically because isolation level is at least REPEATABLE READ) and transaction B man

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

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 wraparound related > testing. > > Again, thanks for taking a look. /me reviews a bit more deeply. In 0001, it

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

On Tue, Aug 23, 2016 at 10:18 AM, 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 wraparound related >> testing. >> >> Again, thanks for

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 > Could you provide an example of a case where xacts replayed in commit

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), you'd be scanning the whole index multiple times (one per >> > worker).

[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 translations are using DocBook XML

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 expensive. > > Here are some numbers from a Xeon E7-8830 @ 2.13G

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 that this is just one f

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 catalo

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

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 > blocking), optimize it by ha

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 something that I have thought about, too. And

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 index; extra workers just >>

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 each worker process a separat

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" wrote: On Mon, Aug 22, 2016 at 6:39 PM, Craig Ringer >> > Could you p

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 (typically because

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 > wrote: > >>> On 23 Aug 2016 20:10, "Kevin Grittner" wrote: > >

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 vacuuming. > >> For now, have

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 will produce incorrect results? > > > > ht

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 TC

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] 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 this reason. s/few/many/ > Al

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 wraparound related > > testing. > > > > Again, thanks f

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 significant problem > for logical rep,

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 it's not really ready for seriou

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 > pg_size_pretty and pg_size_b

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 SI system is power

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 >> > units are based on the International Syst

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 so backpatching seems unnecessary.

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 units were copied when pg_size_pretty() w

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 to do. > There is n

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 message. I'm arguing t

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: >> >> >> Could you provide an example of a case where xacts repla

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 to be an improvement

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 what you are asking.

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 10 soon. > > > > Oh

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 comment on the fin

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 didn't understand tha

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 probably

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 a clear vote from

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; >>> ... >>> + if (control_slot == -1) >>> + elog(ERROR, "cannot unpin unknown segment handle"); >

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'; CO

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 nodes is much more correct

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 interest are attached - txid

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] 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. Thanks for answer. -- Antonin Houska Cybe

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, but preferred to >> have the tests the show the probl

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 some duplication to the test

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 of

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

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 a game-changer for

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 from a 28% to a 97%

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

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

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

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 though

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 i

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 vacuum so that each worker >>> processes both 1 and 2 phases for particular block

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 u

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, >> pg_constraint, pg_description, pg_type, p

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 still > > need to insert/delete t

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 pg_attribute, pg_attrdef, pg_constr

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 (in some workloads t

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 issue is that if you h

  1   2   >