Re: [HACKERS] Anyone want to update our Windows timezone map?

On Thu, Aug 18, 2016 at 3:30 PM, Tom Lane wrote: > Magnus Hagander writes: > > On Thu, Aug 18, 2016 at 3:26 PM, Tom Lane wrote: > >> If we got this done in the next couple weeks, any resulting changes > >> could go out in 9.6rc1.

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

On 08/17/2016 11:50 AM, Aleksander Alekseev wrote: That doesn't really solve the problem, because OTHER backends won't be able to see them. So, if I create a fast temporary table in one session that depends on a permanent object, some other session can drop the permanent object. If there were

Re: [HACKERS] Pluggable storage

On Tue, Aug 16, 2016 at 9:46 PM, Andres Freund wrote: > On 2016-08-15 12:02:18 -0400, Robert Haas wrote: >> I am somewhat inclined to >> believe that we need to restructure the executor in a bigger way so >> that it passes around datums instead of tuples; I'm inclined to >>

Re: [HACKERS] regexp_match() returning text

Emre Hasegeli writes: >> I did *not* push the hunk in citext.sgml, since that was alleging support >> that doesn't actually exist in this patch. To make this work for citext, >> we need to add wrapper functions similar to citext's wrappers for >> regexp_matches. And that in

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

On 08/15/2016 12:23 PM, Pavel Stehule wrote: 2016-08-15 12:18 GMT+02:00 Aleksander Alekseev >: > The global temporary tables has persistent rows in the catalogue. The > mapping to files can be marked as special and real

Re: [HACKERS] [WIP] [B-Tree] Keep indexes sorted by heap physical location

On Thu, Aug 18, 2016 at 6:27 PM, Tom Lane wrote: > Claudio Freire writes: >> On Thu, Aug 18, 2016 at 6:04 PM, Kevin Grittner wrote: >>> Speaking of performance side effects, does this avoid O(N^2) >>> performance on index tuple

Re: [HACKERS] [WIP] [B-Tree] Keep indexes sorted by heap physical location

On Thu, Aug 18, 2016 at 6:38 PM, Peter Geoghegan wrote: > On Thu, Aug 18, 2016 at 2:26 PM, Claudio Freire > wrote: >> I see that. I could try to measure average depth to measure the impact >> this had on fan-in. >> >> While it should cut it in half for

Re: [HACKERS] _mdfd_getseg can be expensive

On 2016-08-18 17:27:59 -0700, Peter Geoghegan wrote: > On Thu, Aug 18, 2016 at 5:26 PM, Andres Freund wrote: > > Rebased version attached. A review would be welcome. Plan to push this > > forward otherwise in the not too far away future. > > I can review this next week.

Re: [HACKERS] [WIP] [B-Tree] Keep indexes sorted by heap physical location

On Thu, Aug 18, 2016 at 2:26 PM, Claudio Freire wrote: > I see that. I could try to measure average depth to measure the impact > this had on fan-in. > > While it should cut it in half for narrow indexes, half of very high > is still high. Wide indexes, which are are the

[HACKERS] errno clobbering in reorderbuffer

While researching a customer issue with BDR I noticed that one ereport() call happens after clobbering errno, leading to the wrong strerror being reported. This patch fixes it by saving before calling CloseTransientFile and restoring afterwards. I also threw in a missing errcode I noticed while

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Thu, Aug 18, 2016 at 5:06 PM, Michael Paquier wrote: > Cool. I have been honestly wondering about deploying this tool as well > to allow some of the QE tests to perform live checks of btree indexes > as we use a bunch of them. I'd certainly welcome that. There are

Re: [HACKERS] _mdfd_getseg can be expensive

On Thu, Aug 18, 2016 at 5:28 PM, Andres Freund wrote: >> I can review this next week. > > Thanks Given the time frame that you have in mind, I won't revisit the question the parallel CLUSTER CPU bottleneck issue until this is committed. The patch might change things enough

Re: [HACKERS] WIP: About CMake v2

On Fri, Aug 19, 2016 at 4:25 AM, Tom Lane wrote: > BTW, I just noticed that cmake doesn't seem to be supplied as part of > Apple's dev tools, at least not up to current (El Capitan) releases. > That's going to be a rather large minus to be taken into account > whenever we make

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

Jeff Janes writes: > So even though it knows that 6952 values have been shoved in the bottom, it > thinks only 200 are going to come out of the aggregation. This seems like > a really lousy estimate. In more complex queries than the example one > given it leads to poor

Re: [HACKERS] [WIP] [B-Tree] Keep indexes sorted by heap physical location

Claudio Freire wrote: > Unique indexes still need to scan all duplicates to check visibility > and will become O(N^2) there. That scenario doesn't matter, because on unique indexes there aren't many duplicate values anyway -- only one can be a live tuple. -- Álvaro Herrera

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

On 7/25/16 1:50 PM, Tom Lane wrote: There's a glibc-dependent hack in aset.c that reports any plpgsql-driven palloc or pfree against a context named "SPI Proc", as well as changes in pl_comp.c so that transient junk created during initial parsing of a plpgsql function body doesn't end up in the

Re: [HACKERS] anyelement -> anyrange

I'd be happy to roll your code into the extension, and make it marked more stable. On Thu, Aug 18, 2016 at 2:49 PM, Jim Nasby wrote: > On 8/18/16 1:06 PM, Corey Huinker wrote: > >> You might also find some gleanable gems in: >>

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Thu, Aug 18, 2016 at 5:35 PM, Michael Paquier wrote: > This would be packaged from source in my case, but that's no big deal > :) At least I can see that it is added in the next CF, and that's > marked as ready for committer for a couple of months now... If you

Re: [HACKERS] [PATCH] bigint txids vs 'xid' type, new txid_recent(bigint) => xid

On 19 August 2016 at 02:35, Jim Nasby wrote: > On 8/18/16 5:46 AM, Amit Kapila wrote: > >> I think there is a value in exposing such a variant which takes bigint >> and internally converts it to xid. I am not sure the semantics for >> > > I think that's a bad idea

Re: [HACKERS] [WIP] [B-Tree] Keep indexes sorted by heap physical location

On Thu, Aug 18, 2016 at 6:15 PM, Peter Geoghegan wrote: > On Thu, Aug 18, 2016 at 1:41 PM, Claudio Freire > wrote: >> In fact, that's why non-leaf index tuples need a different format, >> because while leaf index tuples contain the heap pointer already,

Re: [HACKERS] [WIP] [B-Tree] Keep indexes sorted by heap physical location

Claudio Freire writes: > On Thu, Aug 18, 2016 at 6:04 PM, Kevin Grittner wrote: >> Speaking of performance side effects, does this avoid O(N^2) >> performance on index tuple insertion with duplicate values, for all >> insertion orderings? For example,

Re: [HACKERS] [PATCH] add option to pg_dumpall to exclude tables from the dump

Jim Nasby writes: > On 8/18/16 2:40 PM, Tom Lane wrote: >> This seems pretty dubious to me, in particular that the identical -T >> option will be passed willy-nilly into the pg_dump runs for every >> database. That seems more likely to be a foot-gun than something

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Fri, Aug 19, 2016 at 9:14 AM, Peter Geoghegan wrote: > On Thu, Aug 18, 2016 at 5:06 PM, Michael Paquier > wrote: >> Cool. I have been honestly wondering about deploying this tool as well >> to allow some of the QE tests to perform live checks of

Re: [HACKERS] _mdfd_getseg can be expensive

On Thu, Aug 18, 2016 at 5:42 PM, Andres Freund wrote: > How large was the index & table in question? I mean this really only > comes into effect at 100+ segments. Not that big, but I see no reason to take the chance, I suppose. -- Peter Geoghegan -- Sent via

Re: [HACKERS] Most efficient way for libPQ .. PGresult serialization

On 19 August 2016 at 03:08, Joshua Bay wrote: > Thanks, > But I don't think my question was clear enough. > > I already managed the connection pooling, and what I need is to serialize > the result. > > If PGresult was a contiguous block, I could have just create buffer and

Re: [HACKERS] pg_basebackup wish list

On 7/12/16 9:55 PM, Masahiko Sawada wrote: > And what I think is pg_baseback never remove the directory specified > by -D option even if execution is failed. initdb command behaves so. > I think it's helpful for backup operation. This has been bothering me as well. How about the attached patch

Re: [HACKERS] errno clobbering in reorderbuffer

Hi, On 2016-08-18 19:06:02 -0300, Alvaro Herrera wrote: > if (write(fd, rb->outbuf, ondisk->size) != ondisk->size) > { > + int save_errno = errno; > + > CloseTransientFile(fd); > + errno = save_errno; > ereport(ERROR, >

Re: [HACKERS] _mdfd_getseg can be expensive

On Thu, Aug 18, 2016 at 5:26 PM, Andres Freund wrote: > Rebased version attached. A review would be welcome. Plan to push this > forward otherwise in the not too far away future. I can review this next week. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list

Re: [HACKERS] [PATCH] add option to pg_dumpall to exclude tables from the dump

On 8/18/16 2:40 PM, Tom Lane wrote: This seems pretty dubious to me, in particular that the identical -T option will be passed willy-nilly into the pg_dump runs for every database. That seems more likely to be a foot-gun than something useful. I agree, but I think mandating a database name

Re: [HACKERS] drop src/backend/port/darwin/system.c ?

On 8/17/16 12:29 PM, Tom Lane wrote: > Also, the early releases of OS X were rough enough that it's pretty hard > to believe anyone is still using them anywhere (certainly the buildfarm > isn't). So the odds of anyone caring if we remove this file seem > negligible. Let's nuke it. done --

Re: [HACKERS] errno clobbering in reorderbuffer

On 2016-08-18 19:06:02 -0300, Alvaro Herrera wrote: > While researching a customer issue with BDR I noticed that one ereport() > call happens after clobbering errno, leading to the wrong strerror being > reported. This patch fixes it by saving before calling > CloseTransientFile and restoring

Re: [HACKERS] _mdfd_getseg can be expensive

On 2016-06-30 18:14:15 -0700, Peter Geoghegan wrote: > On Tue, Dec 15, 2015 at 10:04 AM, Andres Freund wrote: > > Took a while. But here we go. The attached version is a significantly > > revised version of my earlier patch. Notably I've pretty much entirely > > revised the

Re: [HACKERS] Fix comment in ATExecValidateConstraint

On 2016/08/19 5:35, Robert Haas wrote: > On Thu, Aug 18, 2016 at 5:15 AM, Amit Langote > wrote: >> On 2016/07/25 17:18, Amit Langote wrote: >>> The comment seems to have been copied from ATExecAddColumn, which says: >>> >>> /* >>> * If we are told not to recurse,

Re: [HACKERS] errno clobbering in reorderbuffer

Alvaro Herrera writes: > While researching a customer issue with BDR I noticed that one ereport() > call happens after clobbering errno, leading to the wrong strerror being > reported. This patch fixes it by saving before calling > CloseTransientFile and restoring

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Fri, Aug 19, 2016 at 2:40 AM, Peter Geoghegan wrote: > Heroku began a selective roll-out of amcheck yesterday. amcheck > already found a bug in the PostGiS Geography B-Tree opclass: > [...] > I'll go report this to the PostGiS people. Cool. I have been honestly wondering

Re: [HACKERS] errno clobbering in reorderbuffer

On August 18, 2016 7:21:03 PM PDT, Alvaro Herrera wrote: >Andres Freund wrote: >> On 2016-08-18 19:06:02 -0300, Alvaro Herrera wrote: >> > While researching a customer issue with BDR I noticed that one >ereport() >> > call happens after clobbering errno, leading to

Re: [HACKERS] errno clobbering in reorderbuffer

Andres Freund wrote: > On 2016-08-18 19:06:02 -0300, Alvaro Herrera wrote: > > While researching a customer issue with BDR I noticed that one ereport() > > call happens after clobbering errno, leading to the wrong strerror being > > reported. This patch fixes it by saving before calling > >

Re: [HACKERS] pg_basebackup wish list

On Fri, Aug 19, 2016 at 7:06 AM, Peter Eisentraut wrote: > On 7/12/16 9:55 PM, Masahiko Sawada wrote: >> And what I think is pg_baseback never remove the directory specified >> by -D option even if execution is failed. initdb command behaves so. >> I think it's

Re: [HACKERS] Missing checks when malloc returns NULL...

On Thu, Aug 18, 2016 at 6:12 PM, Heikki Linnakangas wrote: > On 06/22/2016 04:41 AM, Michael Paquier wrote: >> make s >> OK, there is not much that we can do here then. What about the rest? >> Those seem like legit concerns to me. > > > There's also a realloc() and an strdup()

Re: [HACKERS] Bug in to_timestamp().

On Friday, August 19, 2016 12:42 AM, Robert Haas wrote: >On Wed, Aug 17, 2016 at 10:35 AM, amul sul wrote: > > >> Hmm. I haven't really looked into the code, but with applying both patches >> it looks precisely imitate Oracle's behaviour. Thanks. >

Re: [HACKERS] _mdfd_getseg can be expensive

On 2016-08-18 17:35:47 -0700, Peter Geoghegan wrote: > On Thu, Aug 18, 2016 at 5:28 PM, Andres Freund wrote: > >> I can review this next week. > > > > Thanks > > Given the time frame that you have in mind, I won't revisit the > question the parallel CLUSTER CPU bottleneck

[HACKERS] Marginal cleanup in regex code: remove typedef "celt"

The regex library used to have a notion of a "collating element" that was distinct from a "character", but Henry Spencer never actually implemented support for multi-character collating elements, and the Tcl crew ripped out most of the stubs for it years ago. The only thing left that distinguished

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Sat, Mar 12, 2016 at 12:38 PM, Peter Geoghegan wrote: > Only insofar as it helps diagnose the underlying issue, when it is a > more subtle issue. Actually fixing the index is almost certainly a > REINDEX. Once you're into the messy business of diagnosing a > problematic

Re: [HACKERS] WIP: About CMake v2

Hi Yury, I'm interested in helping with your CMake effort. I don't have any experience contributing to PG, but I do have some free time at the moment. Please let me know if I can help. I have an intermediate level of experience with CMake, Python, and Bash scripting. My native environment is

[HACKERS] Re: PROPOSAL: make PostgreSQL sanitizers-friendly (and prevent information disclosure)

On 03/22/2016 03:27 PM, Aleksander Alekseev wrote: diff --git a/src/backend/commands/tablespace.c b/src/backend/commands/tablespace.c index 1ff5728..a10c078 100644 --- a/src/backend/commands/tablespace.c +++ b/src/backend/commands/tablespace.c @@ -669,6 +669,11 @@

[HACKERS] Making pg_hba.conf case-insensitive

I was looking at this TODO item from 2009: https://www.postgresql.org/message-id/4AA7B197.70002%40usit.uio.no I have implemented this in the attached patch. It does two things: o compares words in columns that can only support keywords as case-insensitive, double-quoted or not o

Re: [HACKERS] Making pg_hba.conf case-insensitive

Bruce Momjian writes: > I was looking at this TODO item from 2009: > https://www.postgresql.org/message-id/4AA7B197.70002%40usit.uio.no > I have implemented this in the attached patch. It does two things: Is there really enough demand for this to justify subtle breakage

Re: [HACKERS] anyelement -> anyrange

On Tue, Aug 16, 2016 at 9:29 PM, Tom Lane wrote: > Jim Nasby writes: > > I can't think of any reason you'd want two different range types on a > > single element type. > > We would not have built it that way if there were not clear use-cases. > An

Re: [HACKERS] Add -c to rsync commands on SR tutorial wiki page

On 8/17/16 9:46 PM, Stephen Frost wrote: * Jim Nasby (jim.na...@bluetreble.com) wrote: > https://wiki.postgresql.org/wiki/Binary_Replication_Tutorial does > not specify -c for any of the rsync commands. That's maybe safe for > WAL, but I don't think it's safe for any of the other uses, right? >

Re: [HACKERS] Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]

Thank you for your corrections. Here is the patch with suggestions taken into account, except 6th. >6) I'd rather use alignednewsize here. > +ItemIdSetNormal(tupid, offset + size_diff, newsize); This behavior is accroding to ubiquitous PageAddItem. Best regards, Andrey Borodin, Octonica &

Re: [HACKERS] patch proposal

On Thu, Aug 18, 2016 at 3:37 PM, Michael Paquier wrote: > On Tue, Aug 16, 2016 at 11:06 PM, Stephen Frost > wrote: > > I could see supporting an additional "pause" option that means "pause at > > the end of WAL if you don't reach the recovery

Re: [HACKERS] Pluggable storage

On 16 August 2016 at 19:46, Andres Freund wrote: > On 2016-08-15 12:02:18 -0400, Robert Haas wrote: >> Thanks for taking a stab at this. I'd like to throw out a few concerns. >> >> One, I'm worried that adding an additional layer of pointer-jumping is >> going to slow things

Re: [HACKERS] Missing checks when malloc returns NULL...

On 06/22/2016 04:41 AM, Michael Paquier wrote: On Tue, Jun 21, 2016 at 10:46 PM, Tom Lane wrote: Michael Paquier writes: - mcxt.c uses that, which is surprising: @@ -704,7 +704,8 @@ MemoryContextCreate(NodeTag tag, Size size, { /*

Re: [HACKERS] patch proposal

* Venkata B Nagothi (nag1...@gmail.com) wrote: > On Wed, Aug 17, 2016 at 11:27 PM, Stephen Frost wrote: > > * Venkata B Nagothi (nag1...@gmail.com) wrote: > > > Agreed. Additional option like "pause" would. As long as there is an > > option > > > to ensure following happens if

Re: [HACKERS] Fix comment in ATExecValidateConstraint

On 2016/07/25 17:18, Amit Langote wrote: > The comment seems to have been copied from ATExecAddColumn, which says: > > /* > * If we are told not to recurse, there had better not be any > - * child tables; else the addition would put them out of step. > > For ATExecValidateConstraint, it

Re: [HACKERS] [PATCH] bigint txids vs 'xid' type, new txid_recent(bigint) => xid

On 16 August 2016 at 21:44, Craig Ringer wrote: > On 16 August 2016 at 20:58, Greg Stark wrote: > >> On Tue, Aug 16, 2016 at 10:15 AM, Craig Ringer >> wrote: >> > I'm surprised the 32-bit xid was ever exposed to the user, rather than

Re: [HACKERS] [PATCH] bigint txids vs 'xid' type, new txid_recent(bigint) => xid

On Tue, Aug 16, 2016 at 2:45 PM, Craig Ringer wrote: > Hi all > > While implementing support for traceable transactions (finding out after the > fact whether an xact committed or aborted), I've found that Pg is very > inconsistent with what it considers a transaction ID

Re: [HACKERS] Anyone want to update our Windows timezone map?

On Thu, Aug 18, 2016 at 7:38 PM, Magnus Hagander wrote: > Thanks, pushed for master and 9.6. Cool. Thanks for the commit. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Pluggable storage

On Wed, Aug 17, 2016 at 10:33 PM, Alvaro Herrera wrote: > Anastasia Lubennikova wrote: >> >> Except these, there are some pretty strange and unrelated functions in >> src/backend/catalog. >> I'm willing to fix them, but I'd like to synchronize our efforts. > > I very

Re: [HACKERS] [Patch] New psql prompt substitution %r (m = master, r = replica)

Aleksander Alekseev wrote: > $ cat ~/.psqlrc > select (case when pg_is_in_recovery() then 'r' else 'm' end) as mor > \gset > > \set PROMPT1 '%p (%:mor:) =# ' Okay, this seems moderately reasonable, but ... > Besides I figured out that replica promotion case could also be properly > handled

Re: [HACKERS] regexp_match() returning text

> I did *not* push the hunk in citext.sgml, since that was alleging support > that doesn't actually exist in this patch. To make this work for citext, > we need to add wrapper functions similar to citext's wrappers for > regexp_matches. And that in turn means a citext extension version bump, >

Re: [HACKERS] Anyone want to update our Windows timezone map?

On Thu, Aug 18, 2016 at 7:06 AM, Michael Paquier wrote: > On Tue, Aug 16, 2016 at 6:22 PM, Magnus Hagander > wrote: > > I think what we want is basically the UNION ALL of all the different > active > > versions. If we just use the definitions from

Re: [HACKERS] [PATCH] Alter or rename enum value

> Emre, I noticed you modified the commitfest entry > (https://commitfest.postgresql.org/10/588/) to be for Andrew's > transactional enum addition patch instead, but didn't change the title. > I'll revert that as soon as it picks up this latest patch. Do you wish > to remain a reviewer for this

Re: [HACKERS] Pluggable storage

On Thu, Aug 18, 2016 at 10:58 AM, Simon Riggs wrote: > On 16 August 2016 at 19:46, Andres Freund wrote: > > On 2016-08-15 12:02:18 -0400, Robert Haas wrote: > >> Thanks for taking a stab at this. I'd like to throw out a few concerns. > >> > >> One,

Re: [HACKERS] [PATCH] Alter or rename enum value

ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes: > ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes: > >> I was bored and thought "how hard could it be?", and a few hours' >> hacking later, I have something that seems to work. It doesn't do IF >> NOT EXISTS yet, and the error messaging

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Thu, Aug 18, 2016 at 9:28 PM, Heikki Linnakangas wrote: >> # This makefile generates two outputs: >> # >> # libpgcommon.a - contains object files with FRONTEND defined, >> # for use by client application and libraries >> # >> # libpgcommon_srv.a -

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On 07/22/2016 03:02 AM, Tom Lane wrote: Michael Paquier writes: On Fri, Jul 22, 2016 at 8:48 AM, Tom Lane wrote: I'm confused. We need that code in both libpq and backend, no? src/common is the place for stuff of that description. Not

Re: [HACKERS] Anyone want to update our Windows timezone map?

Magnus Hagander writes: > On Thu, Aug 18, 2016 at 7:06 AM, Michael Paquier > wrote: >> OK, so after re-running that on my Win10 station and a newly updated >> Win7 station I am finishing with the attached that combines all the >> changes. >

Re: [HACKERS] Anyone want to update our Windows timezone map?

On Thu, Aug 18, 2016 at 3:26 PM, Tom Lane wrote: > Magnus Hagander writes: > > On Thu, Aug 18, 2016 at 7:06 AM, Michael Paquier < > michael.paqu...@gmail.com> > > wrote: > >> OK, so after re-running that on my Win10 station and a newly updated > >> Win7

Re: [HACKERS] Anyone want to update our Windows timezone map?

Magnus Hagander writes: > Done. I skipped 9.1 given it's status and that the backpatch didn't apply > cleanly there (we moved code around). I think the same code exists in a different file in 9.1, but I concur that it's probably not worth a lot of effort.

Re: [HACKERS] [Patch] New psql prompt substitution %r (m = master, r = replica)

Hello, Alvaro. > ... this is terrible. Not only because it's a lot of code dependent > on an external tool which will be rather heavyhanded for something > that should probably be very lightweight, but also because the code > itself is (no offense) an unreadable mess. > > I think your general

Re: [HACKERS] PATCH: Exclude additional directories in pg_basebackup

On 8/17/16 7:56 PM, Michael Paquier wrote: > On Thu, Aug 18, 2016 at 1:35 AM, Alvaro Herrera > wrote: >> I don't remember how pg_snapshot works, but it's probably fine >> to start with an empty subdir (is it possible to export a snapshot from >> a prepared transaction?)

Re: [HACKERS] Anyone want to update our Windows timezone map?

Magnus Hagander writes: > On Thu, Aug 18, 2016 at 3:26 PM, Tom Lane wrote: >> If we got this done in the next couple weeks, any resulting changes >> could go out in 9.6rc1. Given that we've not done this routinely, >> that seems like a better plan than

Re: [HACKERS] Anyone want to update our Windows timezone map?

On Thu, Aug 18, 2016 at 3:34 PM, Magnus Hagander wrote: > > > On Thu, Aug 18, 2016 at 3:30 PM, Tom Lane wrote: > >> Magnus Hagander writes: >> > On Thu, Aug 18, 2016 at 3:26 PM, Tom Lane wrote: >> >> If we got

Re: [HACKERS] [Patch] New psql prompt substitution %r (m = master, r = replica)

Aleksander Alekseev wrote: > Peter has a good point that in general case it's more complicated than > just master or replica. I also agree with David that what actually > would be nice to have is a some syntax that allows user to execute > arbitrary commands before displaying a prompt. This way

Re: [HACKERS] tab completion for alter extension

Gerdan Santos writes: > I did some tests and found nothing special. The stated resource is > implemented correctly. > He passes all regression tests and enables the use of the new features > specified. > The new status of this patch is: Ready for Committer Pushed, thanks.

Re: [HACKERS] psql: tab completion for \l

Gerdan Santos writes: > I did some tests and found nothing special. The stated resource is > implemented correctly. > He passes all regression tests and enables the use of the new features > specified. > The new status of this patch is: Ready for Committer Pushed, thanks.

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

2016-08-18 16:33 GMT+02:00 Tomas Vondra : > On 08/15/2016 12:23 PM, Pavel Stehule wrote: > >> >> >> 2016-08-15 12:18 GMT+02:00 Aleksander Alekseev >> >: >> >> > The global temporary tables has

Re: [HACKERS] Pluggable storage

On August 18, 2016 7:44:50 AM PDT, Ants Aasma wrote: >On Tue, Aug 16, 2016 at 9:46 PM, Andres Freund >wrote: >> On 2016-08-15 12:02:18 -0400, Robert Haas wrote: >>> I am somewhat inclined to >>> believe that we need to restructure the executor in a

[HACKERS] Improving planner's checks for parallel-unsafety

Attached is a patch I'd fooled around with back in July but not submitted. The idea is that, if our initial scan of the query tree found only parallel-safe functions, there is no need to rescan subsets of the tree looking for parallel-restricted functions. We can mechanize that by saving the

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On 08/18/2016 03:45 PM, Michael Paquier wrote: On Thu, Aug 18, 2016 at 9:28 PM, Heikki Linnakangas wrote: Let's take the opportunity and also move src/backend/libpq/ip.c and md5.c into src/common. It would be weird to have sha.c in src/common, but md5.c in src/backend/libpq.

Re: [HACKERS] Pluggable storage

On 2016-08-18 08:58:11 +0100, Simon Riggs wrote: > On 16 August 2016 at 19:46, Andres Freund wrote: > > On 2016-08-15 12:02:18 -0400, Robert Haas wrote: > >> Thanks for taking a stab at this. I'd like to throw out a few concerns. > >> > >> One, I'm worried that adding an

Re: [HACKERS] synchronous_commit = remote_flush

On 8/17/16 11:22 PM, Thomas Munro wrote: Hi hackers, To do something about the confusion I keep seeing about what exactly "on" means, I've often wished we had "remote_flush". But it's not obvious how the backwards compatibility could work, ie how to keep the people happy who use "local" vs

Re: [HACKERS] [PATCH] bigint txids vs 'xid' type, new txid_recent(bigint) => xid

On 8/18/16 5:46 AM, Amit Kapila wrote: I think there is a value in exposing such a variant which takes bigint and internally converts it to xid. I am not sure the semantics for I think that's a bad idea because you have the exact same problems we have now: bigint is signed, epoch is not.

Re: [HACKERS] WIP: About CMake v2

On 06/29/2016 06:23 PM, Yury Zhuravlev wrote: > Hello Hackers. > > I decided to talk about the current state of the project: > 1. Merge with 9.6 master. 2. plpython2, plpython3, plperl, pltcl, plsql > all work correctly (all tests pass). > 3. Works done for all contrib modules. 4. You can use

Re: [HACKERS] Making pg_hba.conf case-insensitive

On Thu, Aug 18, 2016 at 02:06:39PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > I was looking at this TODO item from 2009: > > https://www.postgresql.org/message-id/4AA7B197.70002%40usit.uio.no > > I have implemented this in the attached patch. It does two things: >

Re: [HACKERS] Add -c to rsync commands on SR tutorial wiki page

On 8/18/16 1:31 PM, Stephen Frost wrote: To have proper incremental backups done requires a lot more than just throwing "-c" into the rsyncs. For my 2c, I'm at the point where I'd prefer we discourage people from using rsync, cp, or generally try to set up their own hand-rolled backup system

Re: [HACKERS] Making pg_hba.conf case-insensitive

On 8/18/16 1:59 PM, Bruce Momjian wrote: > o compares words in columns that can only support keywords as > case-insensitive, double-quoted or not > > o compares words in columns that can contain user/db names or keywords > as case-sensitive if double-quoted, case-insensitive if not I can maybe

Re: [HACKERS] Add -c to rsync commands on SR tutorial wiki page

* Jim Nasby (jim.na...@bluetreble.com) wrote: > On 8/17/16 9:46 PM, Stephen Frost wrote: > >* Jim Nasby (jim.na...@bluetreble.com) wrote: > >>> https://wiki.postgresql.org/wiki/Binary_Replication_Tutorial does > >>> not specify -c for any of the rsync commands. That's maybe safe for > >>> WAL, but

Re: [HACKERS] Bug in to_timestamp().

On Wed, Aug 17, 2016 at 10:35 AM, amul sul wrote: > Hmm. I haven't really looked into the code, but with applying both patches it > looks precisely imitate Oracle's behaviour. Thanks. This is good to hear, but for us to consider applying something like this, somebody would

Re: [HACKERS] Use pread and pwrite instead of lseek + write and read

On Wed, Aug 17, 2016 at 3:11 PM, Tom Lane wrote: > Robert Haas writes: >> I don't understand why you think this would create non-trivial >> portability issues. > > The patch as submitted breaks entirely on platforms without pread/pwrite. > Yes, we can

Re: [HACKERS] [Patch] New psql prompt substitution %r (m = master, r = replica)

On 8/18/16 10:05 AM, Alvaro Herrera wrote: Bash has PROMPT_COMMAND, which is executed prior to issuing each prompt. What about introducing such a feature into psql? Then the \gset command you had in your first post could be used to set the variable correctly just before each prompt. As

Re: [HACKERS] anyelement -> anyrange

On 8/18/16 1:06 PM, Corey Huinker wrote: You might also find some gleanable gems in: https://github.com/moat/range_type_functions/blob/master/doc/range_type_functions.md Well crap, I searched for range stuff on PGXN before creating http://pgxn.org/dist/range_tools/ and the only thing that

Re: [HACKERS] Making pg_hba.conf case-insensitive

Bruce Momjian writes: > On Thu, Aug 18, 2016 at 02:06:39PM -0400, Tom Lane wrote: >> Is there really enough demand for this to justify subtle breakage >> of existing pg_hba.conf entries? It'd probably have been fine if >> we did it like that originally, but I think it's a bit

Re: [HACKERS] WIP: About CMake v2

Hi Stefan, I think I've seen similar errors when a project's CMake files assumed a newer version of CMake than the one being run. Which version of CMake gave you those errors? (Sorry if you provided that detail and I'm just missing it.) Kind regards, Christian On Thu, Aug 18, 2016 at 2:45 PM,

Re: [HACKERS] WIP: About CMake v2

On 08/18/2016 08:57 PM, Christian Convey wrote: > Hi Stefan, > > I think I've seen similar errors when a project's CMake files assumed > a newer version of CMake than the one being run. > > Which version of CMake gave you those errors? (Sorry if you provided > that detail and I'm just missing

Re: [HACKERS] Most efficient way for libPQ .. PGresult serialization

Thanks, But I don't think my question was clear enough. I already managed the connection pooling, and what I need is to serialize the result. If PGresult was a contiguous block, I could have just create buffer and call memcpy for serialization, but structure of result seems much more

Re: [HACKERS] Use pread and pwrite instead of lseek + write and read

Robert Haas writes: > Well, I think you're pointing out some things that need to be figured > out, but I hardly think that's a good enough reason to pour cold water > on the whole approach. If somebody feels like doing the legwork to find out if those performance hazards

Re: [HACKERS] WIP: About CMake v2

Stefan Kaltenbrunner writes: > On 08/18/2016 08:57 PM, Christian Convey wrote: >> Which version of CMake gave you those errors? (Sorry if you provided >> that detail and I'm just missing it.) > % cmake --version > cmake version 2.8.10.2 > a quick look in the docs does

Re: [HACKERS] WIP: About CMake v2

Hi Karl, I'll need to let Yury answer your original question regarding the best way to report CMake-related bugs. Regarding the errors you're getting... I just looked at CMake's online documentation regarding your "target_compile_definitions" error. >From what I can tell, the

  1   2   >