Hi,
On 2018-09-26 22:36:03 +0200, Laurenz Albe wrote:
> 2. There already are functions "pg_ls_logdir" and "pg_ls_waldir",
>and I can imagine new requests, e.g. pg_ls_datafiles() to list the
>data files in a database directory.
>
>It may make sense to have a generic function like
>
>
On Wed, Sep 26, 2018 at 10:36:03PM +0200, Laurenz Albe wrote:
> Bossart, Nathan wrote:
> > Attached is a patch to add a pg_ls_tmpdir() function that lists the
> > contents of a specified tablespace's pgsql_tmp directory. This is
> > very similar to the existing pg_ls_logdir() and pg_ls_waldir()
>
On 9/27/18, 2:52 AM, "Michael Paquier" wrote:
> Thanks for the new patches. So I have begun looking at the full set,
> beginning by 0001 which introduces a new common routine to get the
> elevel associated to a skipped relation. I have been chewing on this
> one, and I think that the patch
Jaime Casanova writes:
> sqlsmith made it again, attached is the query (run against regression
> database) that makes the assert fail and the backtrace.
> this happens in head only (or at least 11 is fine).
Ah. Looks like the has_column_privilege stuff is incautious about whether
it's handed a
On 01/10/2018 05:34, Alvaro Herrera wrote:
> I don't see it as clear cut as all that ... particularly considering
> that a useful event trigger runs *after* the DDL command in question has
> already written all its WAL, so such a restore point would be completely
> useless. (Or are
Amit Langote writes:
> On 2018/10/01 2:18, Tom Lane wrote:
>> I think that the call sites should ultimately look like
>> Assert(CheckRelationLockedByMe(...));
>> but for hunting down the places where the assertion currently fails,
>> it's more convenient if it's just an elog(WARNING).
> Should
Amit Langote writes:
> On 2018/09/30 5:04, Tom Lane wrote:
>> 3. There remain some cases where the RTE says RowExclusiveLock but
>> the executor calculation indicates we only need AccessShareLock.
>> AFAICT, this happens only when we have a DO ALSO rule that results
>> in an added query that
Amit Langote writes:
> On 2018/10/01 4:20, Tom Lane wrote:
>> Running the regression tests with the patch I showed in
>> https://www.postgresql.org/message-id/16565.1538327...@sss.pgh.pa.us
> Maybe you've noticed but the relation_open calls coming from bootstrap.c
> all pass NoLock which trigger
Hi,
On 29/09/18 03:35, Andres Freund wrote:
>
> How come those two functions return oids, even though, as far as I
> understand, the underlying relation is BKI_WITHOUT_OIDS. I assume
> that's just an oversight?
>
Yeah, it's copy-pasto that managed to get through, those functions
should return
On 9/30/18, Michael Paquier wrote:
> It would be nice to add this patch to the next commit fest:
> https://commitfest.postgresql.org/20/
Done, thanks.
-John Naylor
On 07/27/2018 10:10 AM, David Fetter wrote:
On Fri, Jul 27, 2018 at 02:55:26PM +1200, Thomas Munro wrote:
On Thu, Jul 26, 2018 at 7:14 AM, David Fetter wrote:
Please find attached the next version, which passes 'make check'.
... but not 'make check-world' (contrib/postgres_fdw's EXPLAIN is
(2018/10/01 19:42), Michael Paquier wrote:
On Mon, Jul 23, 2018 at 02:17:38PM +0530, Ashutosh Bapat wrote:
I used perform instead of execute since the later is usually
associated with local operation. I added "foreign" in the name of the
function to indicate that it's executed on foreign
01.10.2018 15:15, Peter Eisentraut wrote:
On 24/09/2018 14:50, Peter Eisentraut wrote:
On 11/09/2018 17:10, Peter Eisentraut wrote:
On 07/09/2018 17:59, Maksim Milyutin wrote:
those directories was that user). The error message "could not set
permissions on directory ..." disoriented that
> On 1 Oct 2018, at 01:19, Michael Paquier wrote:
>
> On Sun, Sep 30, 2018 at 10:51:44PM +0900, Michael Paquier wrote:
>> You could have chosen something less complicated, like "ホゲ", which is
>> the equivalent of "foo" in English. Anyway, non-ASCII characters should
>> not be included in the
On 09/28/2018 08:29 PM, Peter Eisentraut wrote:
On 28/06/2018 01:36, Nikita Glukhov wrote:
Attached patch with draft of SQL/JSON documentation written by
Liudmila Mantrova, Oleg Bartunov and me.
Also it can be found in our sqljson repository on sqljson_doc branch:
At Tue, 25 Sep 2018 14:26:42 +0900, Michael Paquier wrote
in <20180925052642.gj1...@paquier.xyz>
> On Tue, Sep 25, 2018 at 12:48:57PM +0900, Kyotaro HORIGUCHI wrote:
> > Do you mean that cert/key files are generated on-the-fly while
> > running 'make check'? It sounds reasonable as long as just
On 24/09/2018 14:50, Peter Eisentraut wrote:
> On 11/09/2018 17:10, Peter Eisentraut wrote:
>> On 07/09/2018 17:59, Maksim Milyutin wrote:
>>> those directories was that user). The error message "could not set
>>> permissions on directory ..." disoriented that user. The need to change
>>> the
On Wed, Sep 26, 2018 at 9:54 AM Chris Travers
wrote:
>
>
> On Tue, Sep 25, 2018 at 3:23 PM Tom Lane wrote:
>
>> Chris Travers writes:
>> > However, what I think one could do is use a struct of volatile
>> > sig_atomic_t members and macros for checking/setting. Simply writing a
>> > value is
## Michael Paquier (mich...@paquier.xyz):
> Okay, could you add this patch to the next commit fest? Here it is:
> https://commitfest.postgresql.org/20/
And here's the patch: https://commitfest.postgresql.org/20/1813/
Regards,
Christoph
--
Spare Space
PostgreSQL Hackers
Subject: Re: pgbench - add pseudo-random permutation function
On Wed, Sep 26, 2018 at 01:20:49PM +0200, Fabien COELHO wrote:
So, am I right to deducing that you are satisfied with the current status of
the patch, with the nbits implementation either based on popcount
On 10/01/2018 09:15 AM, Michael Paquier wrote:
On Thu, Mar 01, 2018 at 07:04:41PM -0500, David Steele wrote:
After reviewing the thread I also agree that this should be pushed to
2018-09, so I have done so.
I'm very excited by this patch, though. In general I agree with Peter that
a higher
On Mon, Jul 23, 2018 at 02:17:38PM +0530, Ashutosh Bapat wrote:
> I used perform instead of execute since the later is usually
> associated with local operation. I added "foreign" in the name of the
> function to indicate that it's executed on foreign server. I am happy
> with "remote" as well. I
Hi,
Attached patch adds a new option FREEZE_ONLY to VACUUM command. This
option is same as FREEZE option except for it disables reclaiming dead
tuples. That is, with this option vacuum does pruning HOT chain,
freezing live tuples and maintaining both visibility map and freespace
map but does not
On 2018/10/01 2:18, Tom Lane wrote:
> I wrote:
>> 1. You set up transformRuleStmt to insert AccessExclusiveLock into
>> the "OLD" and "NEW" RTEs for a view. This is surely wrong; we do
>> not want to take exclusive lock on a view just to run a query using
>> the view. It should (usually, anyway)
On Thu, Jun 14, 2018 at 11:40:17AM +0300, Arthur Zakirov wrote:
> I attached new version of the patch.
The patch still applies to HEAD. I moved it to the next commitfest.
--
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
Hi, Hackers
# This is my first post.
I will try to implement a new data type 'bytea' for ECPG.
I think that the implementation is not complicated.
Does anyone need it ?
* Why do I need bytea ?
Currently, ECPG program can treat binary data for bytea column with 'char' type
of C language, but
On Tue, Sep 25, 2018 at 1:17 PM, Andres Freund wrote:
>
> I've pushed the change without that bit - it's just a few additional
> lines if we want to change that.
>
It seems that since this commit, JIT statistics are now only being printed
for parallel query plans. This is due to ExplainPrintJIT
On 2018/10/01 15:27, Michael Paquier wrote:
> On Mon, Oct 01, 2018 at 03:16:32PM +0900, Amit Langote wrote:
>> I wasn't able to respond to some of issues that Jesper brought up with the
>> approach taken by the latest patch whereby there is no separate
>> pg_partition_level function. He said that
On 2018/10/01 4:20, Tom Lane wrote:
> Running the regression tests with the patch I showed in
> https://www.postgresql.org/message-id/16565.1538327...@sss.pgh.pa.us
> exposes two places where HEAD is opening relations without having
> any lock at all on them:
Maybe you've noticed but the
On Wed, Sep 19, 2018 at 04:50:40PM -0500, Kevin Grittner wrote:
> I will spend a few more days in testing and review, but figured I
> should pass along "first impressions" now.
Kevin, it seems that this patch is pending on your input. I have moved
this patch to next CF for now.
--
Michael
On Thu, Mar 01, 2018 at 07:04:41PM -0500, David Steele wrote:
> After reviewing the thread I also agree that this should be pushed to
> 2018-09, so I have done so.
>
> I'm very excited by this patch, though. In general I agree with Peter that
> a higher rate of false positives is acceptable to
On Wed, Sep 19, 2018 at 02:26:53PM +0200, Ildar Musin wrote:
> Another approach would be to leave `pg_conn->connhost` as it is now (i.e.
> not to create global addresses array) and just apply random permutations to
> it if `hostorder=random` is specified. And probably apply permutations to
>
On Wed, Jun 06, 2018 at 07:03:47PM +0530, Amit Kapila wrote:
> I think Robert's chash stuff [1] might be helpful to reduce the contention
> you are seeing.
Latest patch available does not apply, so I moved it to next CF. The
thread has died a bit as well...
--
Michael
signature.asc
On Mon, Aug 20, 2018 at 06:00:39PM +0300, Konstantin Knizhnik wrote:
> New version of the patch is attached: I removed -Z options form pgbench and
> psql and add checking that server and client are implementing the same
> compression algorithm.
The patch had no reviews, and does not apply
On Wed, Sep 12, 2018 at 06:12:29PM +0300, Marina Polyakova wrote:
> The discussion about this has become entangled from the beginning, because
> as I wrote in [1] at first I misread your original proposal...
The last emails are about the last reviews of Fabien, which has remained
unanswered for
On Wed, Sep 26, 2018 at 01:20:49PM +0200, Fabien COELHO wrote:
> So, am I right to deducing that you are satisfied with the current status of
> the patch, with the nbits implementation either based on popcount (v4) or
> clz (v5) compiler intrinsics? I think that the clz option is better.
Fabien,
On 2018/09/30 5:04, Tom Lane wrote:
> David Rowley writes:
>> I've attached v10 which fixes this and aligns the WARNING text in
>> ExecInitRangeTable() and addRangeTableEntryForRelation().
>
> I started poking at this.
Thanks a lot for looking at this.
> I thought that it would be a good
On Tue, Sep 18, 2018 at 11:20 AM amul sul wrote:
> On Mon, Sep 17, 2018 at 9:06 PM amul sul wrote:
> >
> > Nice catch Rajkumar.
> >
> > In index_check_primary_key(), relationHasPrimaryKey() called only for
> the an
> > alter command but I think we need to call in this case as well, like
> this:
On Fri, Sep 28, 2018 at 08:16:46PM +0200, Peter Eisentraut wrote:
> Yeah, I don't see why we need to document it three times in the same
> chapter.
>
> Also, that chapter is specifically about version 3.0 of the protocol, so
> documenting version 2.0 is out of scope.
This has been marked as
On Fri, Mar 23, 2018 at 02:18:09PM +0100, Daniel Verite wrote:
> There's a batch mode for pgbench in a patch posted in [1],
> with \beginbatch and \endbatch commands, but nothing
> for psql AFAICS.
> psql is more complicated because currently it uses a
> blocking PQexec() call at its core. Craig
On Tue, Apr 17, 2018 at 05:58:44PM +0200, Vik Fearing wrote:
> I think I handle that well enough with permission checking, but I'm open
> to more debate on it.
The recent version bump in pg_stat_statements (Sorry my fault!) is
causing this patch to not apply anymore. I have moved it to next CF
On Mon, Oct 01, 2018 at 03:16:32PM +0900, Amit Langote wrote:
> I wasn't able to respond to some of issues that Jesper brought up with the
> approach taken by the latest patch whereby there is no separate
> pg_partition_level function. He said that such a function would be useful
> to get the
On Tue, Aug 14, 2018 at 02:17:09PM +0200, Fabien COELHO wrote:
> I think that people would survive having the ip spelled out on localhost
> errors when there are several ips associated to the name.
>
> You could also create an exception for "localhost" if you see it as a large
> problem, but if
Hi,
On 2018/10/01 15:03, Michael Paquier wrote:
> On Thu, Aug 09, 2018 at 01:05:56PM +0900, Amit Langote wrote:
>> Attached updated patch.
>
> So, except if I am missing something, what we have here is a patch which
> has been debatted quite a bit and has semantics which look nice.
Thanks.
>
On Thu, Aug 09, 2018 at 01:05:56PM +0900, Amit Langote wrote:
> Attached updated patch.
So, except if I am missing something, what we have here is a patch which
has been debatted quite a bit and has semantics which look nice. Any
objections if we move forward with this patch?
+-- all tables in
101 - 145 of 145 matches
Mail list logo
