On Sun, 19 May 2019 at 07:37, Andres Freund wrote:
> David, anyone, any comments?
Looking at this now.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On Sun, May 19, 2019 at 8:31 AM Andres Freund wrote:
> While looking at fixing [1] on master, I noticed the following
> codeblock:
>
> static HeapScanDesc
> heap_beginscan_internal(Relation relation, Snapshot snapshot,
> int nkeys, ScanKey key,
>
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Tomas Vondra writes:
> > On Sat, May 18, 2019 at 03:45:11PM -0400, Tom Lane wrote:
> >> Tomas Vondra writes:
> >>> But that's not an issue intruduced by PG12, it works like that even for
> >>> the extended statistics introduced in PG10.
>
>
Tomas Vondra writes:
> On Sat, May 18, 2019 at 03:45:11PM -0400, Tom Lane wrote:
>> Tomas Vondra writes:
>>> But that's not an issue intruduced by PG12, it works like that even for
>>> the extended statistics introduced in PG10.
>> Yeah, but no time like the present to fix it if it's wrong ...
On Sat, May 18, 2019 at 03:45:11PM -0400, Tom Lane wrote:
Tomas Vondra writes:
On Sat, May 18, 2019 at 11:49:06AM -0700, Andres Freund wrote:
On Sat, 18 May 2019 at 16:13, Tom Lane wrote:
It seems like what we need here is to have a separation between the
*definition* of a stats object
Hi,
While looking at fixing [1] on master, I noticed the following
codeblock:
static HeapScanDesc
heap_beginscan_internal(Relation relation, Snapshot snapshot,
int nkeys, ScanKey key,
On Wed, Apr 17, 2019 at 4:22 PM Tom Lane wrote:
> As for the general usability argument, I'm not sure --- as we start
> to look at alternate AMs, we might have more use for them. When I first
> saw the functions, I thought maybe they were part of sort acceleration
> for TIDs; evidently they're
Hi,
On 2019-05-18 15:48:47 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Not quite - that was about the DML callbacks, this is about the scan
> > itself. And while we have a snapshot allocated, the analyze version of the
> > beginscan intentionally doesn't take a snapshot.
>
> Uh, what?
Andres Freund writes:
> Not quite - that was about the DML callbacks, this is about the scan itself.
> And while we have a snapshot allocated, the analyze version of the beginscan
> intentionally doesn't take a snapshot.
Uh, what? That's a *huge* regression. See, eg, 7170268ef. We
really
Tomas Vondra writes:
> On Sat, May 18, 2019 at 11:49:06AM -0700, Andres Freund wrote:
>>> On Sat, 18 May 2019 at 16:13, Tom Lane wrote:
It seems like what we need here is to have a separation between the
*definition* of a stats object (which is what pg_dump needs access
to) and
Hi,
David, anyone, any comments?
On 2019-05-16 20:04:04 -0700, Andres Freund wrote:
> On 2019-05-08 13:06:36 +0900, Kyotaro HORIGUCHI wrote:
> > This behavior is introduced by 69c3936a14 (in v11). At that time
> > FunctionCallInfoData is pallioc0'ed and has fixed length members
> > arg[6] and
When bitmap-only heap scans were introduced in v11 (7c70996ebf0949b142a99)
no changes were made to "EXPLAIN". This makes the feature rather opaque.
You can sometimes figure out what is going by the output of EXPLAIN
(ANALYZE, BUFFERS), but that is unintuitive and fragile.
Looking at the
On Sat, May 18, 2019 at 11:49:06AM -0700, Andres Freund wrote:
Hi,
On May 18, 2019 8:43:29 AM PDT, Dean Rasheed wrote:
On Sat, 18 May 2019 at 16:13, Tom Lane wrote:
Dean Rasheed writes:
> On the other hand, pg_dump relies on pg_statistic_ext to work out
> which extended statistics objects
Hi,
On May 18, 2019 11:55:01 AM PDT, Tom Lane wrote:
>I wrote:
>> Sergei Kornilov writes:
>>> I can reproduce with:
>>> set default_transaction_isolation TO serializable ;
>>> analyze ;
>
>> So the problem is that something is passing a null snapshot to
>something
>> that isn't expecting that.
I wrote:
> Sergei Kornilov writes:
>> I can reproduce with:
>> set default_transaction_isolation TO serializable ;
>> analyze ;
> So the problem is that something is passing a null snapshot to something
> that isn't expecting that. This seems closely related to the tableam
> API issue that was
Hi,
On May 18, 2019 8:43:29 AM PDT, Dean Rasheed wrote:
>On Sat, 18 May 2019 at 16:13, Tom Lane wrote:
>>
>> Dean Rasheed writes:
>> > On the other hand, pg_dump relies on pg_statistic_ext to work out
>> > which extended statistics objects to dump. If we were to change
>that
>> > to use
On Wed, May 15, 2019 at 09:32:31AM -0400, Tom Lane wrote:
> David Fetter writes:
> > I hope the patch is a little easier to digest as now attached.
>
> To be blunt, I find 500K worth of changes in the regression test
> outputs to be absolutely unacceptable, especially when said changes
> are
On 5/14/19 8:34 AM, Joe Conway wrote:
> On 5/13/19 8:32 PM, Michael Paquier wrote:
>> On Mon, May 13, 2019 at 01:06:10PM -0700, legrand legrand wrote:
>>> that finished commited
>>> "pgsql: Add hooks for session start and session end"
>>>
On Sat, 18 May 2019 at 16:13, Tom Lane wrote:
>
> Dean Rasheed writes:
> > On the other hand, pg_dump relies on pg_statistic_ext to work out
> > which extended statistics objects to dump. If we were to change that
> > to use pg_stats_ext, then a user dumping a table with RLS using the
> >
Hello hackers,
I've stumbled upon a misspelled HAVE_ZLIB in a comment and decided to
check all the unique identifiers/entities in the source tree. Using the
balleyeing technique I've processed questionable A* and HAVE_* unicums
(for now). The patches for every one are attached.
1. AExprConst ->
Sergei Kornilov writes:
> I can reproduce with:
> set default_transaction_isolation TO serializable ;
> analyze ;
> Here is backtrace:
> #0 SerializationNeededForRead (snapshot=0x0, relation=0x7f53e9a525f8) at
> predicate.c:530
> #1 PredicateLockRelation
Dean Rasheed writes:
> On the other hand, pg_dump relies on pg_statistic_ext to work out
> which extended statistics objects to dump. If we were to change that
> to use pg_stats_ext, then a user dumping a table with RLS using the
> --enable-row-security flag wouldn't get any extended statistics
>
Hello
Seems table_beginscan_analyze (src/include/access/tableam.h) should not pass
second argument as NULL.
CC'ing Andres Freund
PS: also I noticed in src/include/utils/snapshot.h exactly same comment for
both SNAPSHOT_SELF and SNAPSHOT_DIRTY - they have no difference?
regards, Sergei
Hi
I can reproduce with:
set default_transaction_isolation TO serializable ;
analyze ;
Here is backtrace:
#0 SerializationNeededForRead (snapshot=0x0, relation=0x7f53e9a525f8) at
predicate.c:530
#1 PredicateLockRelation (relation=relation@entry=0x7f53e9a525f8,
snapshot=snapshot@entry=0x0)
Hackers,
Head of master is giving me a segfault on running ANALYZE when isolation mode
is SERIALIZABLE.
My configure:
export CFLAGS="-g"
export LDFLAGS="-L/usr/local/opt/readline/lib"
export CPPFLAGS="-I/usr/local/opt/readline/include"
./configure \
--prefix=/Users/joe/Development/tmp/pg \
On Sat, 18 May 2019 at 10:11, Dean Rasheed wrote:
>
> On Fri, 17 May 2019 at 21:29, Andres Freund wrote:
> >
> > On 2019-05-16 14:28:03 +0100, Dean Rasheed wrote:
> > > 5). Some columns from pg_statistic_ext have to be made visible for
> > > psql \d to work. Basically, it needs to be able to
On Fri, May 17, 2019 at 01:11:53PM -0700, Andres Freund wrote:
> My impression is that these are better treated as feature work, to be
> tackled in v13. I see no urgency to push this for v12. There's still
> some disagreements on how parts of this are implemented, and we've beta1
> coming up.
It
On Fri, 17 May 2019 at 21:29, Andres Freund wrote:
>
> On 2019-05-16 14:28:03 +0100, Dean Rasheed wrote:
> > 5). Some columns from pg_statistic_ext have to be made visible for
> > psql \d to work. Basically, it needs to be able to query for the
> > existence of extended statistics, but it doesn't
Hello,
This is in context with the previous mail I created dated April 30, 2019 in
regard to GSoD'19.
I am really interested to work on building a "Mumbo-Jumbo PostgreSQL
dictionary".
I am looking forward to a reply.
Thanking You
Manish Devgan
https://github.com/gabru-md
manish.ns...@gmail.com
Hello
No, this is not bug. This is expected beharior of search_path setting:
https://www.postgresql.org/docs/current/runtime-config-client.html
> Likewise, the current session's temporary-table schema, pg_temp_nnn, is
> always searched if it exists. It can be explicitly listed in the path by
> 17 мая 2019 г., в 18:40, Gasper Zejn написал(а):
>
> I've tested according to instructions at the test repo
> https://github.com/x4m/test_pglz
>
> Test_pglz is at a97f63b and postgres at 6ba500.
>
> Hardware is desktop AMD Ryzen 5 2600, 32GB RAM
>
> Decompressor score (summ of all
31 matches
Mail list logo
