On Sat, Dec 15, 2018 at 12:14 AM Robert Haas wrote:
>
> On Wed, Nov 28, 2018 at 1:43 PM Alvaro Herrera
> wrote:
> > Right, I think option 4 is a clear improvement over option 1. I can get
> > behind that one. Since not many people care to vote, I think this tips
> > the scales enough to that
On 2018/12/19 14:27, Michael Paquier wrote:
On Tue, Dec 04, 2018 at 02:31:51PM +0900, Tatsuro Yamada wrote:
- For now, there is no column_number column on "\d index_name" result.
So, if tab-completion suggested column_numbers, user can't match
these easily.
Well, it depends how many
Hi Alvaro,
On 2018/12/19 2:23, Alvaro Herrera wrote:
Hello Yamada-san,
On 2018-Dec-03, Tatsuro Yamada wrote:
Thank you for managing the CF and Sorry for the late reply.
I'll rebase it for the next CF and also I'll clear my head because the patch
needs design change to address the feedbacks,
út 18. 12. 2018 v 8:49 odesílatel Amit Langote <
langote_amit...@lab.ntt.co.jp> napsal:
> Hi,
>
> Thank you for updating the patch.
>
> On 2018/12/17 17:48, Pavel Stehule wrote:
> > new update of this patch
>
> Documentation portion of this patch still contains some typos that I
> mentioned
st 19. 12. 2018 v 6:45 odesílatel Michael Paquier
napsal:
> On Sun, Dec 16, 2018 at 10:33:38AM +0100, Pavel Stehule wrote:
> > Now, the statement's hook is not called for every plpgsql_stmt_block
> > statement. It is not big issue, but it is not consistent - and this
> > inconsistency should be
On Sun, Dec 16, 2018 at 10:33:38AM +0100, Pavel Stehule wrote:
> Now, the statement's hook is not called for every plpgsql_stmt_block
> statement. It is not big issue, but it is not consistent - and this
> inconsistency should be repaired inside extension. Better to be consistent
> and every
On Tue, Dec 04, 2018 at 02:31:51PM +0900, Tatsuro Yamada wrote:
> - For now, there is no column_number column on "\d index_name" result.
>So, if tab-completion suggested column_numbers, user can't match
>these easily.
Well, it depends how many columns an index definition has. If that's
On Fri, Nov 30, 2018 at 03:44:38PM +, Dagfinn Ilmari Mannsåker wrote:
> ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
>> Please find attached a patch that adds the following tab completions for
>> CREATE TABLE:
>
> Added to the 2019-01 commitfest:
On Fri, Nov 30, 2018 at 04:26:41PM -0500, Andrew Dunstan wrote:
> On 11/18/18 1:41 PM, Andrew Dunstan wrote:
>> On 11/17/18 9:55 AM, Alvaro Herrera wrote:
>>> In the long run, I think we should add an option to processSQLNamePattern
>>> to use OR instead of AND, which would fix both this problem
Hi,
On 2018-12-18 23:17:54 -0500, Tom Lane wrote:
> Andres Freund writes:
> > It'd be nice if there were an easy way to write a switch() where the
> > compiler enforces that all enum values are checked, but still had the
> > possibility to have a 'default:' block for error checking... I can't
>
Andres Freund writes:
> It'd be nice if there were an easy way to write a switch() where the
> compiler enforces that all enum values are checked, but still had the
> possibility to have a 'default:' block for error checking... I can't
> quite come up with a good approach to emulate that though.
Hi,
The current pluggable table storage patchset [1] introduces the ability
to specify the access method of a table (CREATE TABLE ... USING
"ident"). The patchset currently names the current storage method
(i.e. heapam.c et al) "heap" (whereas e.g. zheap's in named, drumroll,
zheap).
I'm
Hi,
On 2018-12-18 22:50:57 -0500, Tom Lane wrote:
> Kyotaro HORIGUCHI writes:
> > At Tue, 18 Dec 2018 17:13:08 -0800, Andres Freund
> > wrote in <20181219011308.mopzyvc73nwjz...@alap3.anarazel.de>
> >> Right now there's no easy way to use the compiler to ensure that all
> >> places that need
Kyotaro HORIGUCHI writes:
> At Tue, 18 Dec 2018 17:13:08 -0800, Andres Freund wrote
> in <20181219011308.mopzyvc73nwjz...@alap3.anarazel.de>
>> Right now there's no easy way to use the compiler to ensure that all
>> places that need to deal with all kinds of relkinds check a new
>> relkind. I
Hello.
At Tue, 18 Dec 2018 17:13:08 -0800, Andres Freund wrote in
<20181219011308.mopzyvc73nwjz...@alap3.anarazel.de>
> Hi,
>
> Right now there's no easy way to use the compiler to ensure that all
> places that need to deal with all kinds of relkinds check a new
> relkind. I think we should
Hi,
Right now there's no easy way to use the compiler to ensure that all
places that need to deal with all kinds of relkinds check a new
relkind. I think we should make that easier by moving RELKIND_* to an
enum, with the existing letters as the value.
Obviously we cannot really do that for
On Wed, Dec 19, 2018 at 8:08 AM Peter Eisentraut
wrote:
> On 18/12/2018 19:50, Robbie Harwood wrote:
> > Second, since the project does have a defined style checker, do you
> > think it would be possible to run it as part of cfbot and report errors?
>
> pgindent is a code formatter, not a style
On Tue, Dec 18, 2018 at 10:08:33PM +0100, Peter Eisentraut wrote:
> What cfbot could do is spit out a diff at the end between the current
> code and the pgindent'ed version. That might be useful in some cases.
Yes, that part would be useful. Another thing is that some structures
need to be
On Tue, Dec 18, 2018 at 11:40:49AM -0500, Tom Lane wrote:
> Agreed, done.
Thanks Tom for stepping in!
--
Michael
signature.asc
Description: PGP signature
On Tue, Dec 18, 2018 at 01:41:06PM -0500, Robert Haas wrote:
> OK. I'll post what I have by the end of the week.
Thanks, Robert.
--
Michael
signature.asc
Description: PGP signature
>> I'd move the comma not remove it; and I think "the pg_read_file()" is
>> pretty bad English too. So perhaps
>>
>> Note that granting users the EXECUTE privilege on
>> pg_read_file(), or related functions, allows them
>> the
>> ability to read any file on the server which the
>> It seems there's an extra comma between "related" and "functions". Am I
>> correct?
>
> I'd move the comma not remove it; and I think "the pg_read_file()" is
> pretty bad English too. So perhaps
>
> Note that granting users the EXECUTE privilege on
> pg_read_file(), or related
Hi Alexey,
Attached is an updated version of the patches, with all the fixes I've
done in the past. I believe it should fix at least some of the issues
you reported - certainly the problem with stream_cleanup_files, but
perhaps some of the other issues too.
I'm a bit confused by the changes to
David Fetter writes:
> Is there a useful distinction to be drawn between the files readable
> by the system user who owns the database and those the database itself
> can read?
Probably not. It's possible to create such a distinction with SELinux
or other security tools, but not in plain Unix,
On Tue, Dec 18, 2018 at 06:16:14PM -0500, Tom Lane wrote:
> Tatsuo Ishii writes:
> > While translating the manual into Japanese, I had a hard time to
> > parse following sentence in func.sgml:
>
> > Note that granting users the EXECUTE privilege on the
> > pg_read_file(), or related,
On Tue, Dec 18, 2018 at 2:47 PM Alvaro Herrera wrote:
> Well, if you think about individual blocks in terms of storage space,
> maybe that's true, but I meant in an Heraclitus way of men never
> stepping into the same river -- the second time you write the block,
> it's not the same block you
Tatsuo Ishii writes:
> While translating the manual into Japanese, I had a hard time to
> parse following sentence in func.sgml:
> Note that granting users the EXECUTE privilege on the
> pg_read_file(), or related, functions allows them the
> ability to read any file on the server
While translating the manual into Japanese, I had a hard time to
parse following sentence in func.sgml:
Note that granting users the EXECUTE privilege on the
pg_read_file(), or related, functions allows them the
ability to read any file on the server which the database can read and
On 2018-Dec-18, Peter Geoghegan wrote:
> On Tue, Dec 18, 2018 at 1:02 PM Alvaro Herrera
> wrote:
> > If we see this in terms of tapes and merges, we can report the total
> > number of each of those that we have completed. As far as I understand,
> > we write one tape to completion, and only
On Tue, Dec 18, 2018 at 2:26 PM Tom Lane wrote:
> Hm, that definitely leads me to feel that we've got bug(s) in
> dependency.c. I'll take a look sometime soon.
Thanks!
I'm greatly relieved that I probably won't have to become an expert on
dependency.c after all. :-)
--
Peter Geoghegan
Peter Geoghegan writes:
> On Tue, Dec 18, 2018 at 2:11 PM Tom Lane wrote:
>> Do you mean "same" output, or "sane" output? I'd certainly expect
>> the latter.
> I meant sane.
> --ignore-system-indexes leads to slightly wrong answers in a number of
> the diagnostic messages run by the
On Tue, Dec 18, 2018 at 1:02 PM Alvaro Herrera wrote:
> If we see this in terms of tapes and merges, we can report the total
> number of each of those that we have completed. As far as I understand,
> we write one tape to completion, and only then start another one, right?
> Since there's no way
On Tue, Dec 18, 2018 at 2:11 PM Tom Lane wrote:
> > Interesting.
> > Note that if the standard that we're going to hold a solution to here
> > is "must produce sane output with --ignore-system-indexes", then my
> > solution will not meet that standard.
>
> Do you mean "same" output, or "sane"
Peter Geoghegan writes:
> On Tue, Dec 18, 2018 at 1:20 PM Alvaro Herrera
> wrote:
>> I can reproduce the
>> reported problem without your patch by using that flag. Here's a
>> recipe:
> Interesting.
> Note that if the standard that we're going to hold a solution to here
> is "must produce
Peter Eisentraut writes:
> In another patch discussion it was brought up why the patch doesn't use
> the IndexIsValid() etc. macros.
> They are defined thus:
> /*
> * Use of these macros is recommended over direct examination of the state
> * flag columns where possible; this allows source
On Tue, Dec 18, 2018 at 1:20 PM Alvaro Herrera wrote:
>
> On 2018-Dec-18, Peter Geoghegan wrote:
> Hmm, interesting. I wonder if this is just a case of never testing this
> code under "postgres --ignore-system-indexes".
I suppose that you could say that. The regression tests will fail at
many
In another patch discussion it was brought up why the patch doesn't use
the IndexIsValid() etc. macros.
They are defined thus:
/*
* Use of these macros is recommended over direct examination of the state
* flag columns where possible; this allows source code compatibility with
* the hacky
With various patches and discussions around collations going on, I
figured I'd send in my in-progress patch for insensitive collations.
This adds a flag "insensitive" to collations. Such a collation disables
various optimizations that assume that strings are equal only if they
are byte-wise
On 2018-Dec-18, Peter Geoghegan wrote:
> Well, you also have cases like this:
>
> --- a/contrib/earthdistance/expected/earthdistance.out
> +++ b/contrib/earthdistance/expected/earthdistance.out
> @@ -972,7 +972,7 @@ SELECT abs(cube_distance(ll_to_earth(-30,-90),
> '(0)'::cube) / earth() - 1) <
>
In readfuncs.c, we have READ_ATTRNUMBER_ARRAY, READ_OID_ARRAY,
READ_INT_ARRAY, READ_BOOL_ARRAY, but the writing side in outfuncs.c is
coded by hand in each case. Any reason for this?
Here is a patch that adds WRITE_ATTRNUMBER_ARRAY, WRITE_OID_ARRAY,
WRITE_INT_ARRAY, WRITE_BOOL_ARRAY. That seems
On 2017-Nov-21, Peter Geoghegan wrote:
> On Mon, Oct 2, 2017 at 6:04 AM, Robert Haas wrote:
> > Progress reporting on sorts seems like a tricky problem to me, as I
> > said before. In most cases, a sort is going to involve an initial
> > stage where it reads all the input tuples and writes out
Hello friends,
Attached please find version 20 of the GSSAPI encryption support. This
has been rebased onto master (thanks Stephen for calling out ab69ea9).
Other changes since v19 from Stephen's review:
- About 100 lines of new comments
- pgindent run over code (only the stuff I'm changing;
Hi friends,
First, I've found cfbot really useful as tool for improving code
correctness. So thanks for that.
Second, since the project does have a defined style checker, do you
think it would be possible to run it as part of cfbot and report errors?
Thanks,
--Robbie
signature.asc
On Tue, Dec 18, 2018 at 10:26 AM Tom Lane wrote:
> Yeah, I've been wondering about that as well. The original intention
> for dependency traversal was that it'd work independently of the ordering
> of entries in pg_depend. If it's not doing so, I'd call that a bug in
> dependency traversal
On Mon, Dec 17, 2018 at 6:44 PM Michael Paquier wrote:
> Agreed. This patch has value, and somebody else could always take it
> from the point where you were.
OK. I'll post what I have by the end of the week.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
On Tue, Dec 18, 2018 at 10:07 AM Alvaro Herrera
wrote:
> Is there any case of this that doesn't involve DEPENDENCY_INTERNAL_AUTO
> entries? I wonder if I just haven't broken the algorithm when
> introducing that, and I worry that we're adding a complicated kludge to
> paper over that problem.
Alvaro Herrera writes:
> On 2018-Nov-05, Peter Geoghegan wrote:
>> I've realized that my patch to make nbtree keys unique by treating
>> heap TID as a tie-breaker attribute must use ASC ordering, for reasons
>> that I won't go into here. Now that I'm not using DESC ordering, there
>> are changes
On 2018-Nov-05, Peter Geoghegan wrote:
> I've realized that my patch to make nbtree keys unique by treating
> heap TID as a tie-breaker attribute must use ASC ordering, for reasons
> that I won't go into here. Now that I'm not using DESC ordering, there
> are changes to a small number of
Hello Yamada-san,
On 2018-Dec-03, Tatsuro Yamada wrote:
> Thank you for managing the CF and Sorry for the late reply.
> I'll rebase it for the next CF and also I'll clear my head because the patch
> needs design change to address the feedbacks, I guess. Therefore, the status
> is
>
Michael Paquier writes:
> On Mon, Dec 17, 2018 at 10:13:42PM -0300, Alvaro Herrera wrote:
>> I think we need to accept the new output. It is saying that previously
>> we would not invoke the hook on SET TABLESPACE for a partitioned table,
>> which makes sense, and now we do invoke it, which also
Marti Raudsepp writes:
> I think Filip's approach of setting pg_database.datallowconn='false'
> is pretty clever to avoid the synchronization problem.
Some bull-in-a-china-shop has recently added logic that allows ignoring
datallowconn and connecting anyway, so I'm not sure that that'd provide
a
On Tue, Dec 18, 2018 at 05:13:40PM +0900, Kyotaro HORIGUCHI wrote:
> $ psql postgres -v ON_ERROR_STOP=0 -f ~/work/y.txt ; echo $?
> $ psql postgres -v ON_ERROR_STOP=0 < ~/work/y.txt ; echo $?
> c) psql postgres -v ON_ERROR_STOP=0 -c foo -c 'select 1'; echo $?
> d) psql postgres -v
On Tue, Dec 18, 2018 at 01:25:32PM +0100, Filip Rembiałkowski wrote:
> Hi,
>
> I propose a simple patch (works-for-me), which adds --force (-f)
> option to dropdb utility.
Nice!
I did something like this in user space back in 2010.
John Naylor writes:
> On 12/17/18, Tom Lane wrote:
>> Also, wouldn't we also adopt this technology for its unreserved keywords,
>> too?
> We wouldn't be forced to, but there might be other reasons to do so.
> Were you thinking of code consistency (within pl_scanner.c or
> globally)? Or
Hi
> út 18. 12. 2018 v 16:11 odesílatel Filip Rembiałkowski
> napsal:
>> Please share opinions if this makes sense at all, and has any chance
>> going upstream.
Clearly since Pavel has another implementation of the same concept,
there is some interest in this feature. :)
On Tue, Dec 18, 2018
On 12/17/18, Tom Lane wrote:
> John Naylor writes:
>> Since PL/pgSQL uses the core scanner, we'd need to use offsets in its
>> reserved_keywords[], too. Those don't change much, so we can probably
>> get away with hard-coding the offsets and the giant string in that
>> case. (If that's not
David Rowley writes:
> I recently stumbled upon the following code in ginfast.c:
> while (collector->ntuples + nentries > collector->lentuples)
> {
> collector->lentuples *= 2;
> collector->tuples = (IndexTuple *) repalloc(collector->tuples,
> sizeof(IndexTuple) *
Hi
út 18. 12. 2018 v 16:11 odesílatel Filip Rembiałkowski <
filip.rembialkow...@gmail.com> napsal:
> Hi,
>
> I propose a simple patch (works-for-me), which adds --force (-f)
> option to dropdb utility.
>
> Pros: This seems to be a desired option for many sysadmins, as this
> thread proves:
>
Hi Thomas,
Here is the patch we are using now on AIX for enabling SysV shm for AIX, which
improves greatly the performance on AIX.
It is compile time.
It seems to me that you'd like this to become a shared_memory_type GUC.
Correct? However, I do not know how to do.
Even as-is, this patch
Hi,
I propose a simple patch (works-for-me), which adds --force (-f)
option to dropdb utility.
Pros: This seems to be a desired option for many sysadmins, as this
thread proves:
https://dba.stackexchange.com/questions/11893/force-drop-db-while-others-may-be-connected
Cons: another possible
On 12/18/18 12:43 AM, Andres Freund wrote:
> Hi,
>
> On 2018-12-18 00:38:16 +0100, Tomas Vondra wrote:
>> On 12/17/18 11:16 PM, Tom Lane wrote:
>>> Tomas Vondra writes:
Yeah, I've been thinking about that too. Currently it gets filtered out
because it's in the CLIENT_CONN_STATEMENT
On 18.12.2018 1:28, Tomas Vondra wrote:
4) There was a problem with marking top-level transaction as having
catalog changes if one of its subtransactions has. It was causing a
problem with DDL statements just after subtransaction start (savepoint),
so data from new columns is not replicated.
5)
I recently stumbled upon the following code in ginfast.c:
while (collector->ntuples + nentries > collector->lentuples)
{
collector->lentuples *= 2;
collector->tuples = (IndexTuple *) repalloc(collector->tuples,
sizeof(IndexTuple) * collector->lentuples);
}
it does not seem very
út 18. 12. 2018 v 9:14 odesílatel Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> napsal:
> Hello.
>
> At Mon, 17 Dec 2018 11:58:41 -0600, Justin Pryzby
> wrote in <20181217175841.gs13...@telsasoft.com>
> > Our deployment script failed to notice dozens of commands failed in a
> >
Thank you for review and commit.
On Tue, Dec 18, 2018 at 1:12 PM Michael Paquier wrote:
> On Mon, Dec 17, 2018 at 11:01:59AM +0900, Michael Paquier wrote:
> > On Mon, Dec 17, 2018 at 10:22:28AM +0900, Amit Langote wrote:
> >> On 2018/12/15 8:00, Michael Paquier wrote:
> >>> I tend to agree with
Hello.
We can create a database named "replication".
$ createdb replication
A pg_hba.conf entry with DATABASE="all" is described as 'does not
match "replication"' in the comment there, but actually it
matches and we can connect to the database
"replication". (Documentation doesn't mention the
Tomas Vondra writes:
> Hi Nikhil,
>
> Thanks for the updated patch - I've started working on a review, with
> the hope of getting it committed sometime in 2019-01. But the patch
> bit-rotted again a bit (probably due to d3c09b9b), which broke the last
> part. Can you post a fixed version?
Hello.
At Mon, 17 Dec 2018 11:58:41 -0600, Justin Pryzby wrote
in <20181217175841.gs13...@telsasoft.com>
> Our deployment script failed to notice dozens of commands failed in a
> transaction block and I only noticed due to keeping full logs and monitoring
> for error_severity>'LOG'. I would
On Tue, Nov 27, 2018 at 11:26 AM Amit Kapila wrote:
>
> On Mon, Nov 26, 2018 at 2:08 PM Masahiko Sawada wrote:
> >
> > On Sun, Nov 25, 2018 at 2:35 PM Amit Kapila wrote:
> > >
> > > On Sat, Nov 24, 2018 at 5:47 PM Amit Kapila
> > > wrote:
> > > > On Tue, Oct 30, 2018 at 2:04 PM Masahiko
69 matches
Mail list logo
