Re: [HACKERS] to_date_valid()

El 2/7/2016 20:33, "Euler Taveira" escribió: > > On 02-07-2016 22:04, Andreas 'ads' Scherbaum wrote: > > The attached patch adds a new function "to_date_valid()" which will > > validate the date and return an error if the input and output date do > > not match. Tests

Re: [HACKERS] Bug in batch tuplesort memory CLUSTER case (9.6 only)

On Sat, Jul 2, 2016 at 3:17 PM, Robert Haas wrote: > In the interest of clarity, I was not intending to say that there > should be a regression test in the patch. I was intending to say that > there should be a test case with the bug report. I'm not opposed to > adding a

Re: [HACKERS] Column COMMENTs in CREATE TABLE?

On Sat, Jul 2, 2016 at 8:31 PM, Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: > > > Em sábado, 2 de julho de 2016, David G. Johnston < > david.g.johns...@gmail.com> escreveu: > >> On Sat, Jul 2, 2016 at 12:55 PM, Marko Tiikkaja wrote: >> >>> >>> What I would prefer is

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

On 7/2/16 6:32 PM, Michael Paquier wrote: > On Sun, Jul 3, 2016 at 4:54 AM, Heikki Linnakangas wrote: > >> Michael, do you plan to submit a new version of this patch set for the next >> commitfest? I'd like to get this committed early in the 9.7 release cycle, >> so that we have

Re: [HACKERS] Column COMMENTs in CREATE TABLE?

On Sat, Jul 02, 2016 at 01:06:49PM -0400, David G. Johnston wrote: > On Sat, Jul 2, 2016 at 12:55 PM, Marko Tiikkaja wrote: > > > > > What I would prefer is something like this: > > > > CREATE TABLE foo( > > f1 int NOT NULL COMMENT > > 'the first field', > > f2 int NOT NULL

Re: [HACKERS] to_date_valid()

On 02-07-2016 22:04, Andreas 'ads' Scherbaum wrote: > The attached patch adds a new function "to_date_valid()" which will > validate the date and return an error if the input and output date do > not match. Tests included, documentation update as well. > Why don't you add a third parameter (say,

Re: [HACKERS] Docs, backups, and MS VSS

On 2 July 2016 at 22:42, Bruce Momjian wrote: > > > I suspect, but cannot prove, that it is also safe to snapshot pg_xlog on > a > > separate filesystem if and only if you take the datadir snapshot before > the > > pg_xlog snapshot and you have wal_keep_segments high enough to

[HACKERS] to_date_valid()

Hello, we have customers complaining that to_date() accepts invalid dates, and returns a different date instead. This is a known issue: http://sql-info.de/postgresql/notes/to_date-to_timestamp-gotchas.html On the other hand this leads to wrong dates when loading dates into the database,

Re: [HACKERS] Column COMMENTs in CREATE TABLE?

Em sábado, 2 de julho de 2016, David G. Johnston escreveu: > On Sat, Jul 2, 2016 at 12:55 PM, Marko Tiikkaja > wrote: > >> >> What I would prefer is something like this: >> >> CREATE TABLE foo( >> f1 int

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

On Sun, Jul 3, 2016 at 4:54 AM, Heikki Linnakangas wrote: > I took a quick look at the patch set now again, and except that it needs to > have the multiple password verifier support refactored out, I think it's in > a pretty good shape. I don't like the pg_upgrade changes and its

Re: [HACKERS] Bug in batch tuplesort memory CLUSTER case (9.6 only)

On Fri, Jul 1, 2016 at 11:37 PM, Noah Misch wrote: > I don't know, either. You read both Robert and me indicating that this bug > fix will be better with a test, and nobody has said that a test-free fix is > optimal. Here's your chance to obliterate that no-tests precedent.

[HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Sat, Jul 2, 2016 at 3:20 PM, Kevin Grittner wrote: > On Sat, Jul 2, 2016 at 1:29 PM, Noah Misch wrote: >> On Fri, Jul 01, 2016 at 09:00:45AM -0500, Kevin Grittner wrote: > >>> I have been looking at several possible fixes, and weighing the >>> pros and

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

So, the consensus so far seems to be: We don't want the support for multiple password verifiers per user. At least not yet. Let's get SCRAM working first, in a way that a user can only have SCRAM or an MD5 hash stored in the database, not both. We can add support for multiple verifiers per

[HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Sat, Jul 2, 2016 at 1:29 PM, Noah Misch wrote: > On Fri, Jul 01, 2016 at 09:00:45AM -0500, Kevin Grittner wrote: >> I have been looking at several possible fixes, and weighing the >> pros and cons of each. I expect to post a patch later today. > > This PostgreSQL 9.6 open

Re: [HACKERS] dumping database privileges broken in 9.6

Noah, all, On Saturday, July 2, 2016, Noah Misch wrote: > On Wed, Jun 29, 2016 at 11:50:17AM -0400, Stephen Frost wrote: > > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com ) > wrote: > > > Do this: > > > > > > CREATE DATABASE test1; > > > REVOKE CONNECT ON

[HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Fri, Jul 01, 2016 at 09:00:45AM -0500, Kevin Grittner wrote: > On Fri, Jul 1, 2016 at 7:17 AM, Robert Haas wrote: > > On Fri, Jul 1, 2016 at 2:48 AM, Andres Freund wrote: > >>> This PostgreSQL 9.6 open item is past due for your status update. Kindly

Re: [HACKERS] dumping database privileges broken in 9.6

On Wed, Jun 29, 2016 at 11:50:17AM -0400, Stephen Frost wrote: > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > > Do this: > > > > CREATE DATABASE test1; > > REVOKE CONNECT ON DATABASE test1 FROM PUBLIC; > > > > Run pg_dumpall. > > > > In 9.5, this produces > > > > CREATE

Re: [HACKERS] Statistics Injection

> The problem is that, even if I set the reltuples and relpages of my choice, when I run the EXPLAIN clause for a query in which the 'newTable'  is involved in (e.g. EXPLAIN SELECT * FROM newTable), I get the

Re: [HACKERS] Column COMMENTs in CREATE TABLE?

On Sat, Jul 2, 2016 at 12:55 PM, Marko Tiikkaja wrote: > > What I would prefer is something like this: > > CREATE TABLE foo( > f1 int NOT NULL COMMENT > 'the first field', > f2 int NOT NULL COMMENT > 'the second field', > ... > ); > > which would ensure the comments are

[HACKERS] Column COMMENTs in CREATE TABLE?

Hi, Currently we have CREATE TABLE statements in a git repository that look roughly like this: CREATE TABLE foo( -- the first field f1 int NOT NULL, -- the second field f2 int NOT NULL, ... ); But the problem is that those comments don't obviously make it all the way to the

[HACKERS] Typo Patch

Hi, I fixed typos. and attached patch for this. Thanks. I only changed comments only in src/backend/utils/adt/tsvector_op.c typos.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] 9.6beta2: query failure with 'cache lookup failed for type 0'

Stefan Huehner writes: > On Sat, Jul 02, 2016 at 11:35:52AM -0400, Tom Lane wrote: >> Hmm, I can't reproduce this on HEAD, but it doesn't seem to look like >> anything we've fixed post-beta2. Do you need to put any particular data >> into the tables? Are you running with any

Re: [HACKERS] 9.6beta2: query failure with 'cache lookup failed for type 0'

Re: Stefan Huehner 2016-07-02 <20160702160042.ga11...@huehner.biz> > No data at all needed in table. > In fact just create database + create 3 those objects is enough to reproduce > it. Confirmed here on Debian unstable amd64, beta2. FEHLER: XX000: cache lookup failed for type 0 ORT:

Re: [HACKERS] 9.6beta2: query failure with 'cache lookup failed for type 0'

On Sat, Jul 02, 2016 at 11:35:52AM -0400, Tom Lane wrote: > Stefan Huehner writes: > > re-testing our application Openbravo on 9.6beta2 i found the following > > query failing to run with > > ERROR: cache lookup failed for type 0 > > Hmm, I can't reproduce this on HEAD, but

Re: [HACKERS] 9.6beta2: query failure with 'cache lookup failed for type 0'

Stefan Huehner writes: > re-testing our application Openbravo on 9.6beta2 i found the following query > failing to run with > ERROR: cache lookup failed for type 0 Hmm, I can't reproduce this on HEAD, but it doesn't seem to look like anything we've fixed post-beta2. Do you

[HACKERS] 9.6beta2: query failure with 'cache lookup failed for type 0'

Hello, re-testing our application Openbravo on 9.6beta2 i found the following query failing to run with ERROR: cache lookup failed for type 0 Tested on 9.6beta2 Specifically debian package version '9.6~beta2-1.pgdg+1' from apt.postgresql.org SELECT

Re: [HACKERS] Leaking memory in text_overlay function

Well that's good to know. It was just curious that, in my case, I only saw this in this particular function. Anyway. I will consider to handle the memory the same way, if this is the recommendation. Many thanks. /Closed On Sat, Jul 2, 2016 at 4:45 PM, Tom Lane wrote: >

Re: [HACKERS] Forthcoming SQL standards about JSON and Multi-Dimensional Arrays (FYI)

Andreas Karlsson writes: > Has any of the major PostgreSQL companies looked into sending members to > the ISO committee? It would be nice if we could be represented. Peter E. had observer status at one point, don't know if he still does. regards, tom

Re: [HACKERS] Bug in batch tuplesort memory CLUSTER case (9.6 only)

Peter Geoghegan writes: > On Fri, Jul 1, 2016 at 8:37 PM, Noah Misch wrote: >> PostgreSQL is open to moving features from zero test coverage to nonzero test >> coverage. The last several releases have each done so. Does that >> sufficiently clarify the

Re: [HACKERS] Leaking memory in text_overlay function

Dirk Rudolph writes: > while implementing my own C function, I mentioned that some memory is not > freed by the text_overlay function in varlena.c By and large, that's intentional. SQL-called functions normally run in short-lived memory contexts, so that any memory

Re: [HACKERS] Docs, backups, and MS VSS

On Sat, Jul 2, 2016 at 10:31:32PM +0800, Craig Ringer wrote: > - Microsoft VSS is NOT safe, as it fails point 2. It is atomic only on a > per-file level. You MUST use pg_start_backup() and pg_stop_backup() with WAL > archiving or automated copy of the extra WAL if you use MS VSS. Most Windows >

Re: [HACKERS] Statistics Injection

Victor Giannakouris - Salalidis writes: > For some research purposes, I am trying to modify the existing statistics > of some tables in the catalogs in order to change the execution plan, > experiment with the EXPLAIN call etc. > Concretely, what I'd like to do is to create

[HACKERS] Docs, backups, and MS VSS

Hi all I just noticed that the Pg docs on backups don't discuss what kind of snapshots are safe for use without a pg_start_backup() and pg_stop_backup() then copying the extra WAL. I'd like to remedy that. My understanding is that it's safe to use a filesystem or block device level snapshot

[HACKERS] Leaking memory in text_overlay function

Hi,while implementing my own C function, I mentioned that some memory is not freed by the text_overlay function in varlena.cParticularly I mean the both substrings allocated by text_substring (according to the documentation of text_substring "The result is always a freshly palloc'd datum.") and

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

Re: Andreas Karlsson 2016-07-02 > On 07/01/2016 11:41 AM, Christoph Berg wrote: > > thanks for the patches. I applied all there patches on top of HEAD > > (10c0558f). The server builds and passes "make check", pgcrypto still > > needs work, though:

Re: [HACKERS] Broken handling of lwlocknames.h

Re: Tom Lane 2016-07-01 <26357.1467400...@sss.pgh.pa.us> > I made some mostly-cosmetic changes to this and pushed it. I confirm that Debian's out-of-tree python3 build works now when invoked directly in the relevant plpython/hstore_plpython subdirectories. Thanks! Christoph -- Sent via

Re: [HACKERS] Bug in batch tuplesort memory CLUSTER case (9.6 only)

On 7/2/16 12:40 AM, Peter Geoghegan wrote: We should be more ambitious about adding test coverage to tuplesort.c. IMHO, s/ to tuplesort.c//, at least for the buildfarm. TAP tests don't run by default, so maybe that's the place to start "going crazy" with adding more testing. Though I do

[HACKERS] Statistics Injection

Hello, For some research purposes, I am trying to modify the existing statistics of some tables in the catalogs in order to change the execution plan, experiment with the EXPLAIN call etc. Concretely, what I'd like to do is to create a "fake" table with a schema of my choice (that's the easy

Re: [HACKERS] Re: [ADMIN] problems using pg_start_backup/pg_stop_backup and pg_basebackup at same time

On Fri, Jul 1, 2016 at 5:00 PM, Magnus Hagander wrote: > > > On Mon, Jun 27, 2016 at 8:27 PM, Alex Malek wrote: >> >> Should I file a bug? > > > Oh, sorry. I did not spot that this was posted to pgsql-admin, which has a > lot fewer readers. I've moved