On May 29, 2019, at 8:23 PM, Paul Guo wrote:
> Have you used the correct libpq library? If yes, you might want to check the
> build logs and related files to see where is wrong. In my environment, it's
> ok with both gssapi enabled or disabled.
Thank you! Resetting libpq's path fixes it.
On 29/05/2019 18:47, Hamlin, Garick L wrote:
On Wed, May 29, 2019 at 11:01:05AM -0400, Tom Lane wrote:
At the same time, I'm not sure if we should just write this off as an
ignorable warning. If the C compiler concludes these are dead stores
it'll probably optimize them away, leading to not
Have you used the correct libpq library? If yes, you might want to check
the build logs and related files to see where is wrong. In my environment,
it's ok with both gssapi enabled or disabled.
On Thu, May 30, 2019 at 9:22 AM Donald Dong wrote:
> Hi,
>
> After I make temp-install on HEAD with a
Hi,
After I make temp-install on HEAD with a clean build, I fail to start
psql (tmp_install/usr/local/pgsql/bin/psql) and get an error message:
./psql: symbol lookup error: ./psql: undefined symbol: PQgssEncInUse
However, make check and other tests still work. For me, it is fine
until commit
Hi,
I noticed that debug_print_rel outputs "unknown expr" when the fields
in baserestrictinfo are typed as varchar.
create table tbl_a(id int, info varchar(32));
RELOPTINFO (tbl_a): rows=4 width=86
baserestrictinfo: unknown expr = pattern
My approach is to handle the RelabelType case
Alvaro Herrera writes:
> Tom pointed out that coverage for worker_spi is 0%. For a module that
> only exists to provide coverage, that's pretty stupid. This patch
> increases coverage to 90.9% line-wise and 100% function-wise, which
> seems like a sufficient starting point.
> How would people
Tom pointed out that coverage for worker_spi is 0%. For a module that
only exists to provide coverage, that's pretty stupid. This patch
increases coverage to 90.9% line-wise and 100% function-wise, which
seems like a sufficient starting point.
How would people feel about me getting this in
On 2018-Nov-22, Michael Paquier wrote:
> On Thu, Nov 22, 2018 at 10:56:39AM +0900, Masahiko Sawada wrote:
> > On Thu, Nov 22, 2018 at 10:43 AM Thomas Munro
> > wrote:
> >> Presumably you could add your own call to __gcov_flush() in
> >> quickdie(), so that we get GCOV data but no other
Jeff Davis writes:
> SPI_connect() changes the memory context to a newly-created one, and
> then SPI_finish() restores it. That seems a bit dangerous because the
> caller might not be expecting it. Is there a reason it doesn't just
> change to the new memory context as-needed?
Because the
Robert Haas writes:
> From my point of view, the DDL code doesn't do a great job separating
> parsing/parse analysis from optimization/execution. The ALTER TABLE
> stuff is actually pretty good in this regard.
Meh. I think a pretty fair characterization of the bug(s) I'm trying to
fix is "we
On Wed, May 29, 2019 at 6:02 PM Tom Lane wrote:
> Well, it *is* a problem. The whole point of this discussion I think is
> to try to get better information "by default" for routine bug reports.
> So if those come from production servers without debug symbols, which
> I believe will be the usual
On Wed, May 29, 2019 at 5:52 PM Tom Lane wrote:
> Hm ... I'm not exactly clear on why that would be a superior solution.
> It would imply that standalone CREATE INDEX etc would call into the
> ALTER TABLE framework --- how is that not equally a layering violation?
Well, the framework could be
Robert Haas writes:
> On Fri, May 24, 2019 at 12:09 PM Tom Lane wrote:
>> Is it actually better? The basic problem with backtrace() is that it
>> only knows about global functions, and so reports call sites in static
>> functions as if they were in whatever global function physically precedes
Robert Haas writes:
> On Sun, May 26, 2019 at 6:24 PM Tom Lane wrote:
>> Anybody have thoughts about a different way to approach it?
> I mean, in an ideal world, I think we'd never call back out to
> ProcessUtility() from within AlterTable(). That seems like a pretty
> clear layering
On Tue, May 28, 2019 at 11:27 AM Antonin Houska wrote:
> We thought that it's more convenient for administrator to enter password. To
> achieve that, we can instead tell the admin how to use the key derivation tool
> (pg_keysetup) and send its output to postgres. So yes, it's possible to always
>
On Mon, May 27, 2019 at 4:02 AM Michael Paquier wrote:
> On Mon, May 27, 2019 at 12:20:58AM -0400, Alvaro Herrera wrote:
> > I wonder if we really want to abolish all distinction between "cannot do
> > X" and "Y is not supported". I take the former to mean that the
> > operation is impossible to
While reading another thread that attempted to link to this email, I
discovered that this email never made it to the list archives. I am
trying again.
On Tue, Apr 30, 2019 at 12:05 PM Robert Haas wrote:
>
> On Tue, Apr 30, 2019 at 10:58 AM Alvaro Herrera
> wrote:
> > My problem here is not
On Mon, May 27, 2019 at 2:01 AM Alex wrote:
> I got some idea from the README under storage/lmgr and read some code of
> LockAcquireExtended , but I still have some questions now.
>
> LWLockAcquire(>backendLock, LW_EXCLUSIVE);
> if (FastPathStrongRelationLocks->count[fasthashcode] != 0)
>
On Tue, May 28, 2019 at 12:35 AM Sascha Kuhl wrote:
> Are there teams behind the names or does everybody write with their personal
> name?
I think if you spend some time reading the mailing list, you'll be
able to figure out the answer to this question and many others you
might have. People
SPI_connect() changes the memory context to a newly-created one, and
then SPI_finish() restores it. That seems a bit dangerous because the
caller might not be expecting it. Is there a reason it doesn't just
change to the new memory context as-needed?
spi.c:161:
/* ... and switch to
On Fri, May 24, 2019 at 12:09 PM Tom Lane wrote:
> Is it actually better? The basic problem with backtrace() is that it
> only knows about global functions, and so reports call sites in static
> functions as if they were in whatever global function physically precedes
> the static one. I think
On Sun, May 26, 2019 at 6:24 PM Tom Lane wrote:
> Anybody have thoughts about a different way to approach it?
I mean, in an ideal world, I think we'd never call back out to
ProcessUtility() from within AlterTable(). That seems like a pretty
clear layering violation. I assume the reason we've
On May 29, 2019, at 1:36 PM, Robert Haas wrote:
> Well, it's all there in the code. I believe the issue is that the
> final estimates are based on the number of rows that will be returned
> from the relation, which is often less, and occasionally more, than
> the total of the rows in the
On Sun, May 26, 2019 at 10:11 PM Michael Paquier wrote:
> If we should do something about such cases, then this brings us back
> to do (INIT | CLEANUP) at the end of recovery anyway?
I believe that could fix problems #1 and #2, but we'd have to think
about what new issues it would introduce.
#3
On Sun, May 26, 2019 at 1:00 PM Donald Dong wrote:
> I noticed the estimated rows of the base relations during the join
> searching is *very* different from the estimations in the final plan.
>
> Join search (rows of the initial_rels):
> RELOPTINFO (ct): rows=1 width=4
> RELOPTINFO (it): rows=1
On Mon, May 27, 2019 at 05:52:13PM +0300, Konstantin Knizhnik wrote:
> Postgres is opening file with FILE_SHARE_DELETE flag which makes it
> possible to unlink opened file.
> But unlike Unixes, the file is not actually deleted. You can see it using
> "dir" command.
> And stat() function also
> On 29 May 2019, at 15:03, Tom Lane wrote:
>
> Pursuant to today's discussion at PGCon about code coverage, I went
> nosing into some of the particularly under-covered subdirectories
> in our tree,
On a similar, but much less important/interesting note. I fat-fingered when
compiling
Pursuant to today's discussion at PGCon about code coverage, I went
nosing into some of the particularly under-covered subdirectories
in our tree, and immediately tripped over an interesting factoid:
the ASCII<->MIC and ASCII<->UTF8 encoding conversion functions are
untested ... not because the
Le mer. 29 mai 2019 19:52, Michael Paquier a écrit :
> On Wed, May 29, 2019 at 07:47:12PM +0200, Guillaume Lelarge wrote:
> > Yeah, I still have quite a lot to process. That might be better to do it
> > all in once.
>
> OK, thanks! Could you ping me on this thread once you think you are
> done?
On Wed, May 29, 2019 at 07:47:12PM +0200, Guillaume Lelarge wrote:
> Yeah, I still have quite a lot to process. That might be better to do it
> all in once.
OK, thanks! Could you ping me on this thread once you think you are
done?
--
Michael
signature.asc
Description: PGP signature
On Tue, May 28, 2019 at 11:37:54AM -0700, Andres Freund wrote:
> 1) Please respect the list style of properly quoting responses inline,
>and only responding to messages that are somewhat related to the
>previous content
> 2) You ask a lot of question, without actually responding to
Le mer. 29 mai 2019 19:45, Michael Paquier a écrit :
> On Wed, May 29, 2019 at 05:30:33PM +0200, Guillaume Lelarge wrote:
> > And here is another one. See patch attached.
>
> Are you still going through some parts of the documentation? Perhaps
> you may notice something else? I am wondering if
On Wed, May 29, 2019 at 05:30:33PM +0200, Guillaume Lelarge wrote:
> And here is another one. See patch attached.
Are you still going through some parts of the documentation? Perhaps
you may notice something else? I am wondering if it would be better
to wait a bit more so as we can group all
Reviving this thread.
On Tue, 26 Sep 2017 at 13:57, Henry wrote:
> It seems test_decoding.c could be easily changed to support JSON by using
> the built in PostgreSQL functions (json.c composite_to_json) to convert a
> Datum into SQL. It's use of OidOutputFunctionCall could be modified to
st 29. 5. 2019 v 17:49 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> Rebase after pg_indent. Besides, off the list there was a suggestion that
> this
> could be useful to accept more than one data type as a key for
> subscripting.
> E.g. for jsonb it probably makes sense to
> On Sat, May 11, 2019 at 6:35 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> Here is the updated version with the changes I was talking about (mostly about
> readability and code cleanup). I've also added few tests for a cursor
> behaviour.
And one more cosmetic rebase after pg_indent.
On Wed, May 29, 2019 at 11:01:05AM -0400, Tom Lane wrote:
> Michael Paquier writes:
> > On Wed, May 29, 2019 at 01:24:19PM +, Hamlin, Garick L wrote:
> >> I ran clang checker and noticed these. It looks like the
> >> sha2 implementation is trying to zero out state on exit, but
> >> clang
On Tue, May 28, 2019 at 09:46:48PM +0200, Guillaume Lelarge wrote:
> Hehe, that was the first thing I wrote :) but went with "table and index"
> as it was also used a bit later in the chapter. Both are fine with me.
Okay, done this way. Thanks for the report.
--
Michael
signature.asc
Le mar. 28 mai 2019 à 21:46, Guillaume Lelarge a
écrit :
> Le mar. 28 mai 2019 à 21:28, Michael Paquier a
> écrit :
>
>> On Tue, May 28, 2019 at 05:05:10PM +0200, Guillaume Lelarge wrote:
>> >
>> >> linkend="catalog-pg-am">pg_am
>> > - index access methods
>> > + table
On Wed, May 29, 2019 at 02:33:26PM +0900, Amit Langote wrote:
> But couple of other points mentioned in 5.11.3.3. Caveats (of 5.11. Table
> Partitioning) are already repeated in 5.10.1. Caveats; for example, note
> the point about VACUUM, ANALYZE, INSERT ON CONFLICT, etc. applying to
> single
On Tue, May 28, 2019 at 03:40:01PM +0800, Hubert Zhang wrote:
On Sat, May 4, 2019 at 8:34 AM Tomas Vondra
wrote:
Hi Tomas
I read your second patch which uses overflow buf files to reduce the total
number of batches.
It would solve the hash join OOM problem what you discussed above: 8K per
Michael Paquier writes:
> On Wed, May 29, 2019 at 01:24:19PM +, Hamlin, Garick L wrote:
>> I ran clang checker and noticed these. It looks like the
>> sha2 implementation is trying to zero out state on exit, but
>> clang checker finds at least 'a' is a dead store.
>>
>> Should we fix
On Wed, May 29, 2019 at 01:24:19PM +, Hamlin, Garick L wrote:
> I ran clang checker and noticed these. It looks like the
> sha2 implementation is trying to zero out state on exit, but
> clang checker finds at least 'a' is a dead store.
>
> Should we fix this?
> Is something like the
I ran clang checker and noticed these. It looks like the
sha2 implementation is trying to zero out state on exit, but
clang checker finds at least 'a' is a dead store.
Should we fix this?
Is something like the attached sensible?
Is there a common/better approach to zero-out in PG ?
Garick
Hi,
Seems that per the documentation on information_schema.views [1] we do
not support check_options ("Applies to a feature not available in
PostgreSQL").
Attached is a patch that fix this description. As CHECK OPTION is
supported since 9.4, the patch might be applied on all versions
Hi All,
I'm getting a server crash when executing the following test-case:
create table t1(a int primary key, b text);
insert into t1 values (1, 'aa'), (2, 'bb'), (3, 'aa'), (4, 'bb');
select a, b, array_agg(a order by a) from t1 group by grouping sets ((a),
(b));
*Backtrace:*
#0
On Wed, May 29, 2019 at 4:51 PM Kohei KaiGai wrote:
> Hi Amit,
>
> 2019年5月29日(水) 13:26 Amit Langote :
> >
> > Kaigai-san,
> >
> > On 2019/05/29 12:13, Kohei KaiGai wrote:
> > > One interesting data type in Apache Arrow is "Struct" data type. It is
> > > equivalent to composite
> > > type in
On Mon, May 27, 2019 at 8:14 PM Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> wrote:
>
> On Thu, May 23, 2019 at 3:44 AM Haribabu Kommi
> wrote:
>
>>
>> Updated patches are attached for all branches.
>>
>>
> I have gone through all patches and there are a couple of typos:
>
Thanks
On Tue, 28 May 2019 at 4:36 PM, Andres Freund wrote:
> Hi,
>
> On 2019-04-07 18:04:27 -0700, Andres Freund wrote:
> > Here's a *prototype* patch for this. It only implements what I
> > described for heap_multi_insert, not for plain inserts. I wanted to see
> > what others think before investing
Hi Amit,
2019年5月29日(水) 13:26 Amit Langote :
>
> Kaigai-san,
>
> On 2019/05/29 12:13, Kohei KaiGai wrote:
> > One interesting data type in Apache Arrow is "Struct" data type. It is
> > equivalent to composite
> > type in PostgreSQL. The "Struct" type has sub-fields, and individual
> > sub-fields
50 matches
Mail list logo
