Re: [HACKERS] mdnblocks() sabotages error checking in _mdfd_getseg()

On Tue, Dec 15, 2015 at 11:08 AM, Andres Freund wrote: >> However, I don't think this is exactly what you are proposing. I'm >> skeptical of the idea that _mdfd_getseg() should probe ahead to see >> whether we're dealing with a malformed relation where the intermediate >>

Re: [HACKERS] mdnblocks() sabotages error checking in _mdfd_getseg()

On 2015-12-15 11:28:10 -0500, Robert Haas wrote: > Hmm, yes it does. But now that I think about it, we're not otherwise > doing _mdnblocks() in that loop. So that would add a system call per > loop iteration. That doesn't seem like such a swell idea. We'd do that only when intially open the

Re: [HACKERS] _mdfd_getseg can be expensive

On 2014-11-01 18:23:47 +0100, Andres Freund wrote: > On 2014-11-01 12:57:40 -0400, Tom Lane wrote: > > Andres Freund writes: > > > On 2014-10-31 18:48:45 -0400, Tom Lane wrote: > > >> While the basic idea is sound, this particular implementation seems > > >> pretty

Re: [HACKERS] Fixing warnings in back branches?

On Tue, Dec 15, 2015 at 9:17 AM, Andres Freund wrote: > On 2015-12-15 09:09:39 -0500, Tom Lane wrote: >> In the end, if you're building an old branch, you should be doing it with >> old tools. > > That I don't buy for even one second. Old branches are used in up2date >

Re: [HACKERS] Comparing two PostgreSQL databases -- order of pg_dump output

Hi Joe, I have run into what seems to be a similar issue with pg_dump --schema-only in its trigger ordering. Did you ever find a satisfactory solution to this? I posted my specific problem on DBA.StackExchange

Re: [HACKERS] pam auth - add rhost item

Actually, one more thing - the patch should probably update the docs too, because client-auth.sgml currently says this in the "auth-pam" section: ... PAM is used only to validate user name/password pairs. ... I believe that's no longer true, because the patch adds PAM_RHOST

Re: [HACKERS] mdnblocks() sabotages error checking in _mdfd_getseg()

On 2015-12-15 10:53:58 -0500, Robert Haas wrote: > On Tue, Dec 15, 2015 at 9:51 AM, Andres Freund wrote: > > Unless in recovery in the startup process, or when EXTENSION_CREATE is > > passed to it. Depending on whether it or mdnblocks were called first, > > and depending on

Re: [HACKERS] pam auth - add rhost item

Hi, On 11/25/2015 01:45 PM, Grzegorz Sampolski wrote: Well, this is not matter since pam_set_item expect this argument as a string. Besides there is not always possible to get map from ip address to hostname. So hostname is just a synonim for whatever information you cat get about remote

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Sun, Dec 13, 2015 at 6:35 AM, and...@anarazel.de wrote: > On 2015-12-12 21:15:52 -0500, Robert Haas wrote: >> On Sat, Dec 12, 2015 at 1:17 PM, and...@anarazel.de >> wrote: >> > Here's two patches doing that. The first is an adaption of your >> >

Re: [HACKERS] [PATCH] Logical decoding support for sequence advances

On 2015-12-15 13:51, Andres Freund wrote: On 2015-12-15 13:46:29 +0100, Petr Jelinek wrote: I don't think that approach alone is good enough. It might be ok for selective replication where the replication is driven by tables anyway, but in general and especially for failover it's not good

Re: [HACKERS] Cube extension kNN support

Hi, On 12/07/2015 03:47 PM, Stas Kelvich wrote: Hello, fixed. I've looked at the patch today, seems mostly fine to me. Three comments though: 1) (nitpicking) There seem to be some minor whitespace issues, i.e. trailing spaces, empty lines being added/removed, etc. 2) one of the

[HACKERS] Check for interrupts in bf and xdes crypt()

Hi, Here is a patch which makes it possible to cancel a query which runs the crypt() function with the bf or xdes hashing algorithm, e.g. crypt('foo', gen_salt('bf', 13)). The md5 algorithm does not run for multiple rounds so there is no reason to patch it. I noticed this problem when I

Re: [HACKERS] pgbench stats per script & other stuff

"sum" is a double so count is converted to 0.0, 0.0/0.0 == NaN, hence the comment. PG code usually avoids that, and I recall static analyze tools type coverity complaining that this may lead to undefined behavior. While I agree that this would lead to NaN... Hmmm. In this case that is what

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

On 2015-12-11 17:00:01 +0300, Aleksander Alekseev wrote: > The problem is that code between LWLockAcquire (lock.c:881) and > LWLockRelease (lock.c:1020) can _sometimes_ run up to 3-5 ms. Using > old-good gettimeofday and logging method I managed to find a bottleneck: > > -- proclock =

Re: [HACKERS] [PATCH] Logical decoding support for sequence advances

On 2015-12-14 16:19:33 +0800, Craig Ringer wrote: > On 14 December 2015 at 11:28, Craig Ringer wrote: > > > Hi all > > > > Attached is a patch against 9.6 to add support for informing logical > > decoding plugins of the new sequence last_value when sequence advance WAL > >

Re: [HACKERS] Allow replication roles to use file access functions

On 03.09.2015 05:40, Michael Paquier wrote: Ah, OK. I thought that you were referring to a protocol where caller sends a single LSN from which it gets a differential backup that needs to scan all the relation files of the source cluster to get the data blocks with an LSN newer than the one

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

Hello, Tom. I was exploring this issue further and discovered something strange. "PROCLOCK hash" and "LOCK hash" are hash tables in shared memory. All memory for these tables is in fact pre-allocated. But for some reason these two tables are created (lock.c:394) with init_size =/= max_size. It

Re: [HACKERS] extend pgbench expressions with functions

On Mon, Dec 14, 2015 at 7:25 AM, Michael Paquier wrote: > On Mon, Nov 9, 2015 at 6:46 AM, Robert Haas wrote: >> On Sat, Nov 7, 2015 at 2:45 AM, Fabien COELHO wrote: >>> After looking at the generated html version, I find

Re: [HACKERS] pg_hba_lookup function to get all matching pg_hba.conf entries

Hi, I've reviewed the patch today, after re-reading the whole discussion. Overall I'm quite happy with the design - a function is certainly better for the use-case. Not just because of the keyword handling issues, but because the checks happen in a particular order and terminate once a match

Re: [HACKERS] [PoC] Asynchronous execution again (which is not parallel)

On Fri, Dec 11, 2015 at 11:49 PM, Amit Kapila wrote: >> But is it important enough to be worthwhile? Maybe, maybe not. I >> think we should be working toward a world where the Gather is at the >> top of the plan tree as often as possible, in which case >> asynchronously

Re: [HACKERS] [PATCH] Equivalence Class Filters

On 7 December 2015 at 16:44, Simon Riggs wrote: > On 6 December 2015 at 16:38, Tom Lane wrote: > > >> Lastly, in most cases knowing that t2.id <= 10 is just not worth all >> >> that much; it's certainly far less useful than an equality condition. >> >>

Re: [HACKERS] Performance improvement for joins where outer side is unique

On 25 August 2015 at 17:25, David Rowley wrote: > On 24 August 2015 at 14:29, Tom Lane wrote: > >> David Rowley writes: >> > I have to admit I don't much like it either, originally I had this as an >> > extra

Re: [HACKERS] extend pgbench expressions with functions

On Wed, Dec 16, 2015 at 6:10 AM, Robert Haas wrote: > On Mon, Dec 14, 2015 at 7:25 AM, Michael Paquier > wrote: >> I have looked for now at the first patch and finished with the >> attached while looking at it. Perhaps a committer could look

Re: [HACKERS] mdnblocks() sabotages error checking in _mdfd_getseg()

On Tue, Dec 15, 2015 at 9:51 AM, Andres Freund wrote: > On 2015-12-09 16:50:06 -0500, Robert Haas wrote: >> Now, if subsequent to this an index scan happens to sweep through and >> try to fetch a block in 123456.2, it will work! This happens because >> _mdfd_getseg() doesn't

Re: [HACKERS] Logical replication and multimaster

On 12/13/15 7:37 AM, David Fetter wrote: As I understand it, pushing these into a library has been proposed but not rejected. That it hasn't happened yet is mostly about the lack of tuits (the round ones) to rewrite the functionality as libraries and refactor pg_dump/pg_restore to use only

Re: [HACKERS] Parallel Aggregate

On Tue, Dec 15, 2015 at 8:04 AM, Paul Ramsey wrote: > But the run dies. > > NOTICE: SRID value -32897 converted to the officially unknown SRID value 0 > ERROR: Unknown geometry type: 2139062143 - Invalid type > > From the message it looks like geometry gets corrupted

Re: [HACKERS] Logical replication and multimaster

On Tue, 15 Dec 2015 21:48:52 -0600 Jim Nasby wrote: > On 12/13/15 7:37 AM, David Fetter wrote: > > As I understand it, pushing these into a library has been proposed but > > not rejected. That it hasn't happened yet is mostly about the lack of > > tuits (the round

Re: [HACKERS] extend pgbench expressions with functions

On Wed, Dec 16, 2015 at 6:10 AM, Robert Haas wrote: It looks fine to me except that I think we should spell out "param" as "parameter" throughout, instead of abbreviating. Fine for me. I have updated the first patch as attached (still looking at the second). This

Re: [HACKERS] [PATCH] Logical decoding support for sequence advances

On 2015-12-15 13:46:29 +0100, Petr Jelinek wrote: > I don't think that approach alone is good enough. It might be ok for > selective replication where the replication is driven by tables anyway, but > in general and especially for failover it's not good enough to tell user > that we handle some

Re: [HACKERS] Fixing warnings in back branches?

On Tue, Dec 15, 2015 at 7:59 AM, Andres Freund wrote: > On 2015-12-14 11:00:32 -0500, Robert Haas wrote: >> On Mon, Dec 14, 2015 at 10:06 AM, Andres Freund wrote: >> > to compile 9.1 without warnings. -Wincompatible-pointer-types is quite >> > useful to

[HACKERS] 9.5RC1 wraps *today*

A lot got done over the last couple of days to close out open issues for 9.5, and we're now at a point where we could realistically produce an RC package. However, we're also staring the holiday season in the face. If we were to do a wrap per normal schedule next week, we'd be announcing on

Re: [HACKERS] Fixing warnings in back branches?

On Tue, Dec 15, 2015 at 8:17 AM, Andres Freund wrote: > On 2015-12-15 08:13:06 -0500, Robert Haas wrote: >> On Tue, Dec 15, 2015 at 7:59 AM, Andres Freund wrote: >> > On 2015-12-14 11:00:32 -0500, Robert Haas wrote: >> >> IIUC, the main thing that causes

Re: [HACKERS] Fixing warnings in back branches?

On 2015-12-15 08:53:25 -0500, Robert Haas wrote: > So... that means we can't really get rid of these warnings on 9.1, > IIUC. Well, we could fix them. Or, as proposed here, just silence that category. > I agree it would be nice to do if this were no issue, but as it > is I'm inclined to think

Re: [HACKERS] parallel joins, and better parallel explain

On Mon, Dec 14, 2015 at 8:38 AM, Amit Kapila wrote: > set enable_hashjoin=off; > set enable_mergejoin=off; [ ... ] > Now here the point to observe is that non-parallel case uses both less > Execution time and Planning time to complete the statement. There > is a

Re: [HACKERS] [PATCH] Logical decoding support for sequence advances

On 2015-12-15 13:17, Andres Freund wrote: On 2015-12-14 16:19:33 +0800, Craig Ringer wrote: Needed to make logical replication based failover possible. While it'll make it easier, I think it's certainly quite possible to do so without this feature if you accept some sane restrictions. If you

Re: [HACKERS] Fixing warnings in back branches?

On 2015-12-14 11:00:32 -0500, Robert Haas wrote: > On Mon, Dec 14, 2015 at 10:06 AM, Andres Freund wrote: > > to compile 9.1 without warnings. -Wincompatible-pointer-types is quite > > useful to detect problems. The rest indeed is pretty 'Meh'. > > IIUC, the main thing that

Re: [HACKERS] Fixing warnings in back branches?

On 2015-12-15 08:13:06 -0500, Robert Haas wrote: > On Tue, Dec 15, 2015 at 7:59 AM, Andres Freund wrote: > > On 2015-12-14 11:00:32 -0500, Robert Haas wrote: > >> IIUC, the main thing that causes incompatible pointer type warnings on > >> 9.1 is the conflation of FILE with

Re: [HACKERS] small query, about skipping dump in dumpAttrDef

amul sul writes: > In dumpAttrDef() function we are skipping dump if table definition is not > dumped(i.e. by checking > tbinfo->dobj.dump), its absolutely alright to do this. > But, in dumpConstraint() we doing same by checking constraint dump > flag(coninfo->dobj.dump)

[HACKERS] "pg_upgrade" cannot write to log file pg_upgrade_internal.log

I run "pg_upgrade -xx" fromPostgreSQL8.3 to PostgreSQL9.4.5 on window server 2008. It will show some wrong information: cannot write to log file pg_upgrade_internal.log Failure, exiting. It seems that the upgrade can be successful on window 7. It seems to be a permissions problem. I get some

Re: [HACKERS] [PATCH] Equivalence Class Filters

On 12/16/2015 01:26 AM, Simon Riggs wrote: There is an interesting real world case where we might get some use of these thoughts. If we have Orders and OrderItems (FK->Orders) and we also know (and can Assert) Order.order_date <= OrderItems.ship_date then a restriction on Orders.order_date > X

[HACKERS] Clarify vacuum verbose message

VACUUM VERBOSE spits out two different messages for the heap, one of which is rather confusing: INFO: "trades": removed 625664 row versions in 20967 pages ... INFO: "trades": found 3282 removable, 56891627 nonremovable row versions in 1986034 out of 1986034 pages After discussion with

Re: [HACKERS] 9.5RC1 wraps *today*

On 12/15/15 7:31 AM, Tom Lane wrote: Accordingly, the release team has decided to wrap 9.5RC1 today, Tuesday, for announcement Friday the 18th. I'll start making the tarballs around 5PM (2200 UTC). Sorry for the short notice, but there's no better way. Since the 18th is my birthday, I think

Re: [HACKERS] Disabling an index temporarily

On 12/13/15 9:27 PM, Tom Lane wrote: Corey Huinker writes: >So, I'd propose we following syntax: >ALTER INDEX foo SET DISABLED >-- does the SET indisvalid = false shown earlier. This is exactly*not* what Tatsuo-san was after, though; he was asking for a session-local

Re: [HACKERS] Fixing warnings in back branches?

Andres Freund writes: > I think that's an ok one-off policy. But looking back it was pretty much > always the case that the release -3 or so started to look pretty > horrible, warning wise. I think that's a condition of life. The compilers are moving targets, no matter that

Re: [HACKERS] Fixing warnings in back branches?

On 2015-12-15 09:09:39 -0500, Tom Lane wrote: > In the end, if you're building an old branch, you should be doing it with > old tools. That I don't buy for even one second. Old branches are used in up2date environments in production. Absolutely regularly. apt.pg.o, yum.pg.o et al do provide them

Re: [HACKERS] mdnblocks() sabotages error checking in _mdfd_getseg()

On 2015-12-09 16:50:06 -0500, Robert Haas wrote: > Now, if subsequent to this an index scan happens to sweep through and > try to fetch a block in 123456.2, it will work! This happens because > _mdfd_getseg() doesn't care about the length of the segments; it only > cares whether or not they

Re: [HACKERS] Fixing warnings in back branches?

On Tue, Dec 15, 2015 at 11:04:07AM -0500, Robert Haas wrote: > On Tue, Dec 15, 2015 at 9:17 AM, Andres Freund wrote: > > On 2015-12-15 09:09:39 -0500, Tom Lane wrote: > >> In the end, if you're building an old branch, you should be doing it with > >> old tools. I grant that's

Re: [HACKERS] [PoC] Asynchronous execution again (which is not parallel)

On Mon, Dec 14, 2015 at 3:34 AM, Kyotaro HORIGUCHI wrote: > Yes, the most significant and obvious (but hard to estimate the > benefit) target of async execution is (Merge)Append-ForeignScan, > which is narrow but freuquently used. And this patch has started >

Re: [HACKERS] "pg_upgrade" cannot write to log file pg_upgrade_internal.log

On Wed, Dec 16, 2015 at 3:28 PM, Michael Paquier wrote: > On Tue, Dec 15, 2015 at 6:54 PM, Yang, Leo wrote: >> I run “pg_upgrade -xx” fromPostgreSQL8.3 to PostgreSQL9.4.5 on window server >> 2008. It will show some wrong information: >> >> cannot

Re: [HACKERS] "pg_upgrade" cannot write to log file pg_upgrade_internal.log

On Tue, Dec 15, 2015 at 6:54 PM, Yang, Leo wrote: > I run “pg_upgrade -xx” fromPostgreSQL8.3 to PostgreSQL9.4.5 on window server > 2008. It will show some wrong information: > > cannot write to log file pg_upgrade_internal.log > > Failure, exiting. > It seems that the upgrade

Re: [HACKERS] [PoC] Asynchronous execution again (which is not parallel)

On Wed, Dec 16, 2015 at 4:54 AM, Robert Haas wrote: > > On Fri, Dec 11, 2015 at 11:49 PM, Amit Kapila wrote: > >> But is it important enough to be worthwhile? Maybe, maybe not. I > >> think we should be working toward a world where the Gather is

Re: [HACKERS] pgbench stats per script & other stuff

On Tue, Dec 15, 2015 at 8:41 PM, Fabien COELHO wrote: >> PG code usually avoids that, and I recall static analyze tools type >> coverity complaining that this may lead to undefined behavior. While I >> agree that this would lead to NaN... > > > Hmmm. In this case that is what

Re: [HACKERS] pg_stat_replication log positions vs base backups

On Mon, Dec 14, 2015 at 8:59 AM, Michael Paquier wrote: > On Mon, Dec 14, 2015 at 1:01 AM, Magnus Hagander wrote: >> I've applied these two patches now. >> >> The one that fixes the initialization backpatched to 9.3 which is the oldest >> one that

[HACKERS] Bug in TupleQueueReaderNext() ?

Hi All, TupleQueueReaderNext() always pass true for the nowait into shm_mq_receive() call. I think here it need to pass the nowait which is passed by the caller of TupleQueueReaderNext. This is usefull if the caller want TupleQueueReaderNext() to wait until it gets the tuple from the particular

Re: [HACKERS] Disabling an index temporarily

On Tue, Dec 15, 2015 at 7:56 PM, Jim Nasby wrote: > On 12/13/15 9:27 PM, Tom Lane wrote: >> >> Corey Huinker writes: >>> >>> >So, I'd propose we following syntax: >>> >ALTER INDEX foo SET DISABLED >>> >-- does the SET indisvalid = false shown