Wow.. This is embarrassing.. *^^*.
At Thu, 21 Nov 2019 16:01:07 +0900 (JST), Kyotaro Horiguchi
wrote in
> I should have replied this first.
>
> At Sun, 17 Nov 2019 20:54:34 -0800, Noah Misch wrote in
> > On Tue, Nov 05, 2019 at 02:53:35PM -0800, Noah Misch wrote:
> > > I started pre-commit
I should have replied this first.
At Sun, 17 Nov 2019 20:54:34 -0800, Noah Misch wrote in
> On Tue, Nov 05, 2019 at 02:53:35PM -0800, Noah Misch wrote:
> > I started pre-commit editing on 2019-10-28, and comment+README updates have
> > been the largest part of that. I'll check my edits against
On Thu, 21 Nov 2019 at 13:25, Dilip Kumar wrote:
>
> On Thu, Nov 21, 2019 at 9:15 AM Amit Kapila wrote:
> >
> > On Thu, Nov 21, 2019 at 6:53 AM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, 20 Nov 2019 at 20:36, Amit Kapila wrote:
> > > >
> > > > On Wed, Nov 20, 2019 at 4:04 PM Masahiko
At Wed, 20 Nov 2019 20:44:18 -0800, Peter Geoghegan wrote in
> It is still within the discretion of committers to use the
> non-reserved/development OID ranges directly. For example, a committer
That happens at feature freeze. Understood.
At Wed, 20 Nov 2019 23:45:21 -0500, Tom Lane wrote
On Mon, Nov 18, 2019 at 6:30 PM Pavel Stehule wrote:
>>
>> I'll send this test today
>
>
> here is it
>
Thanks for adding the test.
Few comments:
This function is same as in test/recovery/t/013_crash_restart.pl, we
can add to a common file and use in both places:
+# Pump until string is matched,
On Thu, Nov 21, 2019 at 10:46 AM Dilip Kumar wrote:
>
> On Wed, Nov 20, 2019 at 11:01 AM Masahiko Sawada
> wrote:
> >
> > On Mon, 18 Nov 2019 at 15:38, Masahiko Sawada
> > wrote:
> > >
> > > On Mon, 18 Nov 2019 at 15:34, Amit Kapila wrote:
> > > >
> > > > On Mon, Nov 18, 2019 at 11:37 AM
On Wed, Nov 20, 2019 at 04:44:18PM +0900, Michael Paquier wrote:
> We can do something similar for GIN and BRIN on top of the rest, so
> updated the patch with that. Nikolay, I would be fine to commit this
> patch as-is. Thanks for your patience on this stuff.
So, I have reviewed the full
On Wed, Nov 20, 2019 at 11:01 AM Masahiko Sawada
wrote:
>
> On Mon, 18 Nov 2019 at 15:38, Masahiko Sawada
> wrote:
> >
> > On Mon, 18 Nov 2019 at 15:34, Amit Kapila wrote:
> > >
> > > On Mon, Nov 18, 2019 at 11:37 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Wed, 13 Nov 2019 at 14:31,
On Wed, Nov 20, 2019 at 2:18 PM Amit Khandekar wrote:
>
> On Wed, 20 Nov 2019 at 13:10, Amit Kapila wrote:
> > See comment in pgunlink() "We need to loop because even though
> > PostgreSQL uses flags that allow unlink while the file is open, other
> > applications might have the file
> > open
Hi Hackers.
This submission seems to have stalled.
Please forgive this post - I am unsure if the submission process expects me to
come to defence of my own patch for one last gasp, or if I am supposed to just
sit back and watch it die a slow death of a thousand cuts.
I thought this
Kyotaro Horiguchi writes:
> At Wed, 20 Nov 2019 18:10:09 -0800, Peter Geoghegan wrote in
>> On Wed, Nov 20, 2019 at 6:07 PM Michael Paquier wrote:
>>> Yep, agreed. This looks like an oversight. Peter?
>> It's not an oversight. See the commit message of a6417078, and the
>> additions that
On Wed, Nov 20, 2019 at 8:33 PM Kyotaro Horiguchi
wrote:
> So, still any ongoing patch can stamp on another when it is committed
> by certain probability (even if it's rather low)). And consecutive
> high-OID "hole"s are going to be shortened and decrease throgh a year.
Right.
> By the way even
At Wed, 20 Nov 2019 18:10:09 -0800, Peter Geoghegan wrote in
> On Wed, Nov 20, 2019 at 6:07 PM Michael Paquier wrote:
> > Yep, agreed. This looks like an oversight. Peter?
>
> It's not an oversight. See the commit message of a6417078, and the
> additions that were made to the RELEASE_CHANGES
Hi all,
After working on dc816e58, I have noticed that what we are doing with
attribute mappings is not that good. In a couple of code paths of the
rewriter, the executor, and more particularly ALTER TABLE, when
working on the creation of inherited relations or partitions an
attribute mapping
On Thu, Nov 21, 2019 at 9:15 AM Amit Kapila wrote:
>
> On Thu, Nov 21, 2019 at 6:53 AM Masahiko Sawada
> wrote:
> >
> > On Wed, 20 Nov 2019 at 20:36, Amit Kapila wrote:
> > >
> > > On Wed, Nov 20, 2019 at 4:04 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Wed, 20 Nov 2019 at 17:02, Amit
On Wed, Nov 20, 2019 at 5:41 PM Juan José Santamaría Flecha
wrote:
>
> On Wed, Nov 20, 2019 at 9:48 AM Amit Khandekar wrote:
>>
>> On Wed, 20 Nov 2019 at 13:10, Amit Kapila wrote:
>> > See comment in pgunlink() "We need to loop because even though
>> > PostgreSQL uses flags that allow unlink
On Thu, Nov 21, 2019 at 6:53 AM Masahiko Sawada
wrote:
>
> On Wed, 20 Nov 2019 at 20:36, Amit Kapila wrote:
> >
> > On Wed, Nov 20, 2019 at 4:04 PM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, 20 Nov 2019 at 17:02, Amit Kapila wrote:
> > > >
> > > > On Wed, Nov 20, 2019 at 11:01 AM Masahiko
At Wed, 20 Nov 2019 11:26:16 +0100, Pavel Stehule
wrote in
> Hi
>
> st 20. 11. 2019 v 10:59 odesílatel Konstantin Knizhnik <
> k.knizh...@postgrespro.ru> napsal:
>
> > Hi hackers,
> >
> > Working on global temporary table I need to define function which
> > returns set of pg_statistic
On Wed, Nov 20, 2019 at 8:22 PM Dilip Kumar wrote:
>
> On Wed, Nov 20, 2019 at 11:15 AM Dilip Kumar wrote:
> >
> > On Tue, Nov 19, 2019 at 5:23 PM Amit Kapila wrote:
> > >
> > > On Mon, Nov 18, 2019 at 5:02 PM Dilip Kumar wrote:
> > > >
> > > > On Fri, Nov 15, 2019 at 4:19 PM Amit Kapila
> >
On Wed, 20 Nov 2019 at 19:24, Alvaro Herrera wrote:
>
> On 2019-Nov-20, Juan José Santamaría Flecha wrote:
>
> > I was not able to reproduce the Permission denied error with current HEAD,
> > until I opened another CMD inside the "pg_replslot/regression_slot" folder.
> > This will be problematic,
On Wed, Nov 20, 2019 at 6:07 PM Michael Paquier wrote:
> Yep, agreed. This looks like an oversight. Peter?
It's not an oversight. See the commit message of a6417078, and the
additions that were made to the RELEASE_CHANGES file.
--
Peter Geoghegan
On Wed, Nov 20, 2019 at 5:44 PM Kyotaro Horiguchi
wrote:
> I happened to find that the commit 71dcd74 added the function
> "network_sortsupport" with OID = 8190. Is it right? Otherwise we
> should we move it to, say, 4035.
>
> (I understand that OID [8000, ] are development-use.)
I
On Thu, Nov 21, 2019 at 10:44:30AM +0900, Kyotaro Horiguchi wrote:
> I happened to find that the commit 71dcd74 added the function
> "network_sortsupport" with OID = 8190. Is it right? Otherwise we
> should we move it to, say, 4035.
>
> (I understand that OID [8000, ] are development-use.)
Hello.
I happened to find that the commit 71dcd74 added the function
"network_sortsupport" with OID = 8190. Is it right? Otherwise we
should we move it to, say, 4035.
(I understand that OID [8000, ] are development-use.)
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From
Hello, pgsql-hackers
I'm gathering information about the following error.
FATAL: could not access status of transaction ..
DETAIL: Could not read from file (pg_clog/ or pg_xact/) ...: Success.
This error has caused the server to fail to start with recovery.
I got a report that it
On Tue, Nov 19, 2019 at 09:48:59PM +0900, Michael Paquier wrote:
> Re-reading the thread. Any design change should IMO just happen on
> master so as we don't take any risks with potential ABI breakages.
> Even if there is not much field demand for it, that's not worth the
> risk. Thinking
On Wed, 20 Nov 2019 at 20:36, Amit Kapila wrote:
>
> On Wed, Nov 20, 2019 at 4:04 PM Masahiko Sawada
> wrote:
> >
> > On Wed, 20 Nov 2019 at 17:02, Amit Kapila wrote:
> > >
> > > On Wed, Nov 20, 2019 at 11:01 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > I've attached the latest version
On Tue, Nov 19, 2019 at 07:22:26PM -0600, Justin Pryzby wrote:
> I was trying to reproduce what was happening:
> set -x; psql postgres -txc "DROP TABLE IF EXISTS t" -c "CREATE TABLE t(i int
> unique); INSERT INTO t SELECT generate_series(1,99)"; echo "begin;SELECT
> pg_export_snapshot();
On Thu, Oct 31, 2019 at 11:07 PM Tom Lane wrote:
>
>
> Possibly this could be finessed by only trying to find duplicates of
> functions that have high cost estimates. Not sure how high is high
> enough.
can we just add a flag on pg_proc to show if the cost is high or not, if
user are not
>
>
> Hm. That actually raises the stakes a great deal, because if that's
> what you're expecting, it would require planning out both the transformed
> and untransformed versions of the query before you could make a cost
> comparison.
I don't know an official name, let's call it as "bloom
Thomas Munro writes:
> As noted by Amit Khandhekar yesterday[1], BufFileLoad() silently eats
> pread()'s error and makes them indistinguishable from EOF.
That's definitely bad.
> I think the choices are: (1) switch to ssize_t and return -1, (2) add
> at least one of BufFileEof(),
On Thu, Nov 21, 2019 at 10:50 AM Thomas Munro wrote:
> As noted by Amit Khandhekar yesterday[1], BufFileLoad() silently eats
Erm, Khandekar, sorry for the extra h!
Hi,
As noted by Amit Khandhekar yesterday[1], BufFileLoad() silently eats
pread()'s error and makes them indistinguishable from EOF.
Some observations:
1. BufFileRead() returns size_t (not ssize_t), so it's an
fread()-style interface, not a read()-style interface that could use
-1 to signal
I noticed that the nbtree README has an obsolete reference to the
former design of get_actual_variable_range() in the "Scans during
Recovery" section. It used to use a dirty snapshot, but doesn't
anymore. These days, get_actual_variable_range() uses
SnapshotNonVacuumable -- see commits 3ca930fc
Amit Langote writes:
> [ v6-0001-Use-root-parent-s-permissions-when-reading-child-.patch ]
I started to review this, and discovered that the new regression test
passes just fine without applying any of the rest of the patch.
Usually we try to design regression test additions so that they
On Wed, Nov 20, 2019 at 12:34:25PM -0800, Xun Cheng wrote:
On Wed, Nov 20, 2019 at 11:18 AM Tomas Vondra
wrote:
On Wed, Nov 20, 2019 at 12:36:50PM -0500, Tom Lane wrote:
>Tomas Vondra writes:
>> On Wed, Nov 20, 2019 at 11:12:56AM -0500, Tom Lane wrote:
>>> I'm content to say that the
On 11/20/19 2:30 PM, Joe Conway wrote:
> On 11/8/19 9:16 AM, Joe Conway wrote:
>> On 11/8/19 9:02 AM, Yuli Khodorkovskiy wrote:
>>> On Thu, Nov 7, 2019 at 7:46 PM Michael Paquier wrote:
On Mon, Sep 30, 2019 at 11:38:05AM -0300, Alvaro Herrera wrote:
> On 2019-Sep-30, Joe Conway
On Wed, Aug 07, 2019 at 04:51:54PM -0700, Andres Freund wrote:
https://www.postgresql.org/message-id/20190807235154.erbmr4o4bo6vgnjv%40alap3.anarazel.de
| Ugh :(
|
| We really need to add a error context to vacuumlazy that shows which
| block is being processed.
I eeked out a minimal patch.
I
On Fri, Nov 8, 2019 at 3:41 AM Andrew Dunstan
wrote:
> On 11/7/19 9:12 AM, Alvaro Herrera wrote:
> >>
> >> The patch says:
> >>
> >> +require Win32::API;
> >> +Win32::API->import;
> > Oh, you're right, it does. I wonder why, though:
> >
>
> On further inspection I think those
On Wed, Nov 20, 2019 at 11:18 AM Tomas Vondra
wrote:
> On Wed, Nov 20, 2019 at 12:36:50PM -0500, Tom Lane wrote:
> >Tomas Vondra writes:
> >> On Wed, Nov 20, 2019 at 11:12:56AM -0500, Tom Lane wrote:
> >>> I'm content to say that the application should have written the query
> >>> with a GROUP
Kyotaro Horiguchi writes:
> At Tue, 12 Nov 2019 11:27:24 +0300, Konstantin Knizhnik
> wrote in
>> In my opinion contain_mutable_functions() is the best solution.
>> But if it is not acceptable, I will rewrite the patch in white-list
>> fashion.
> I agree for just relying on
On 11/8/19 9:16 AM, Joe Conway wrote:
> On 11/8/19 9:02 AM, Yuli Khodorkovskiy wrote:
>> On Thu, Nov 7, 2019 at 7:46 PM Michael Paquier wrote:
>>>
>>> On Mon, Sep 30, 2019 at 11:38:05AM -0300, Alvaro Herrera wrote:
>>> > On 2019-Sep-30, Joe Conway wrote:
>>> >
>>> > > I am not sure I will get to
On Wed, Nov 20, 2019 at 12:36:50PM -0500, Tom Lane wrote:
Tomas Vondra writes:
On Wed, Nov 20, 2019 at 11:12:56AM -0500, Tom Lane wrote:
I'm content to say that the application should have written the query
with a GROUP BY to begin with.
I'm not sure I agree with that. The problem is this
Hi Steve,
Thank you for review.
On 17.11.2019 3:53, Steve Singer wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, failed
Spec compliant: not tested
Documentation:
Tomas Vondra writes:
> On Wed, Nov 20, 2019 at 11:12:56AM -0500, Tom Lane wrote:
>> I'm content to say that the application should have written the query
>> with a GROUP BY to begin with.
> I'm not sure I agree with that. The problem is this really depends on
> the number of rows that will need
Laurenz Albe writes:
> On Tue, 2019-11-19 at 13:21 -0500, Tom Lane wrote:
>> Looking at the page again, I notice that there's a para a little further
>> down that overlaps quite a bit with what we're discussing here, but it's
>> about implicit grant options rather than the right to DROP. In the
On Wed, Nov 20, 2019 at 11:12:56AM -0500, Tom Lane wrote:
Daniel Gustafsson writes:
On 20 Nov 2019, at 13:15, Andy Fan wrote:
2. why pg can't do it, while greenplum can?
It's worth noting that Greenplum, the example you're referring to, is using a
completely different query planner, and
On Wed, Nov 20, 2019 at 08:15:19PM +0800, Andy Fan wrote:
Hi Hackers:
First I found the following queries running bad on pg.
select count(*) from part2 p1 where p_size > 40 and p_retailprice >
(select avg(p_retailprice) from part2 p2 where p2.p_brand=p1.p_brand);
the plan is
On Wed, Nov 20, 2019 at 2:06 AM imai.yoshik...@fujitsu.com
wrote:
>
> On Tue, Nov 19, 2019 at 2:27 PM, Julien Rouhaud wrote:
> > On Fri, Nov 15, 2019 at 2:00 AM imai.yoshik...@fujitsu.com
> > wrote:
> > >
> > > Actually I also don't have strong opinion but I thought someone would
> > >
Now pg_gtt_statistic view is provided for global temp tables.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/src/backend/access/brin/brin.c b/src/backend/access/brin/brin.c
index ae7b729..485c068 100644
---
Daniel Gustafsson writes:
>> On 20 Nov 2019, at 13:15, Andy Fan wrote:
>> 2. why pg can't do it, while greenplum can?
> It's worth noting that Greenplum, the example you're referring to, is using a
> completely different query planner, and different planners have different
> characteristics
Peter Eisentraut writes:
> On 2019-11-15 19:23, Tom Lane wrote:
>> If we add a GUC-check-hook test, then the problem of misconfiguration
>> is reduced to the previously unsolved problem that we have crappy
>> feedback for erroneous on-the-fly configuration changes. So it's
>> still unsolved, but
Alvaro Herrera wrote:
> On 2019-Nov-12, Antonin Houska wrote:
>
> > ok, the next version uses explicit lseek(). Maybe the fact that XLOG is
> > mostly
> > read sequentially (i.e. without frequent seeks) is the reason pread() has't
> > been adopted so far.
>
> I don't quite understand why you
On 2019-Nov-20, Juan José Santamaría Flecha wrote:
> I was not able to reproduce the Permission denied error with current HEAD,
> until I opened another CMD inside the "pg_replslot/regression_slot" folder.
> This will be problematic, is the deletion of the folder actually needed?
Yes :-( The
> On 20 Nov 2019, at 13:15, Andy Fan wrote:
> 2. why pg can't do it, while greenplum can?
It's worth noting that Greenplum, the example you're referring to, is using a
completely different query planner, and different planners have different
characteristics and capabilities.
cheers ./daniel
On Wed, Nov 20, 2019 at 8:15 PM Andy Fan wrote:
> Hi Hackers:
>
> First I found the following queries running bad on pg.
>
> select count(*) from part2 p1 where p_size > 40 and p_retailprice >
> (select avg(p_retailprice) from part2 p2 where p2.p_brand=p1.p_brand);
>
> the plan is
>
Hi Hackers:
First I found the following queries running bad on pg.
select count(*) from part2 p1 where p_size > 40 and p_retailprice >
(select avg(p_retailprice) from part2 p2 where p2.p_brand=p1.p_brand);
the plan is
QUERY PLAN
On Wed, Nov 20, 2019 at 9:48 AM Amit Khandekar
wrote:
> On Wed, 20 Nov 2019 at 13:10, Amit Kapila wrote:
> > See comment in pgunlink() "We need to loop because even though
> > PostgreSQL uses flags that allow unlink while the file is open, other
> > applications might have the file
> > open
st 20. 11. 2019 v 12:40 odesílatel Amit Kapila
napsal:
> On Mon, Nov 18, 2019 at 10:59 AM Pavel Stehule
> wrote:
> > po 18. 11. 2019 v 6:24 odesílatel Amit Kapila
> napsal:
> >>
> >>
> >> I have slightly modified the main patch and attached is the result.
> >> Basically, I don't see any need
On Mon, Nov 18, 2019 at 2:22 PM Amit Kapila wrote:
>
> I have modified the commit message as proposed above and additionally
> added comments in nodeLimit.c. I think we should move ahead with this
> bug-fix patch. If we don't like the comment, it can anyway be
> improved later.
>
> Any
On Mon, Nov 18, 2019 at 10:59 AM Pavel Stehule wrote:
> po 18. 11. 2019 v 6:24 odesílatel Amit Kapila
> napsal:
>>
>>
>> I have slightly modified the main patch and attached is the result.
>> Basically, I don't see any need to repeat what is mentioned in the
>> Drop Database page. Let me know
On Wed, Nov 20, 2019 at 4:04 PM Masahiko Sawada
wrote:
>
> On Wed, 20 Nov 2019 at 17:02, Amit Kapila wrote:
> >
> > On Wed, Nov 20, 2019 at 11:01 AM Masahiko Sawada
> > wrote:
> > >
> > > I've attached the latest version patch set. The patch set includes all
> > > discussed points regarding
On Wed, Nov 20, 2019 at 5:43 PM imai.yoshik...@fujitsu.com
wrote:
> Is there any agreement we can throw the wraparound problem away if we adopt
> FullTransactionId?
Here is one argument for why 64 bits ought to be enough: we use 64 bit
LSNs for the WAL, and it usually takes more than one byte of
On Wed, 20 Nov 2019 at 17:02, Amit Kapila wrote:
>
> On Wed, Nov 20, 2019 at 11:01 AM Masahiko Sawada
> wrote:
> >
> > I've attached the latest version patch set. The patch set includes all
> > discussed points regarding index AM options as well as shared cost
> > balance. Also I added some test
Hi
st 20. 11. 2019 v 10:59 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
> Hi hackers,
>
> Working on global temporary table I need to define function which
> returns set of pg_statistic records.
> Unfortunately I failed to declare such function!
> Type pg_statistic is
Hi hackers,
Working on global temporary table I need to define function which
returns set of pg_statistic records.
Unfortunately I failed to declare such function!
Type pg_statistic is defined in postgres.bki so I was not able to refer
to it in pg_proc.dat file.
And if I explicitly enumerate
On Wed, Nov 20, 2019 at 04:16:45PM +0900, btkimurayuzk wrote:
> typedef struct xl_xact_relfilenodes
> {
> - int nrels; /* number of
> subtransaction XIDs */
> + int nrels; /* number of relations
> */
>
On Wed, 20 Nov 2019 at 13:10, Amit Kapila wrote:
> See comment in pgunlink() "We need to loop because even though
> PostgreSQL uses flags that allow unlink while the file is open, other
> applications might have the file
> open without those flags.". Can you once see if there is any flag
> that
On Mon, Nov 18, 2019 at 09:29:03PM +0900, Michael Paquier wrote:
> Now, read() > pread() > read()+lseek(), and we don't actually need to
> seek into the file for all the cases where we read a WAL page. And on
> a platform which uses the fallback implementation, this increases the
> number of
On Wed, 20 Nov 2019 at 13:10, Amit Kapila wrote:
>
> On Tue, Nov 19, 2019 at 4:58 PM Amit Khandekar wrote:
> >
> > On Tue, 19 Nov 2019 at 14:07, Amit Kapila wrote:
> > >
> > >
> > > Have you tried by injecting some error? After getting the error
> > > mentioned above in email, when I retried
At Sun, 17 Nov 2019 20:54:34 -0800, Noah Misch wrote in
> On Tue, Nov 05, 2019 at 02:53:35PM -0800, Noah Misch wrote:
> > I started pre-commit editing on 2019-10-28, and comment+README updates have
> > been the largest part of that. I'll check my edits against the things you
> > list here, and
On 2019-11-15 19:23, Tom Lane wrote:
Peter Eisentraut writes:
Say you want to set up promote_trigger_file to point to a file outside
of the data directory, maybe because you want to integrate it with some
external tooling. So you go into your configuration and set
promote_trigger_file =
On Wed, Nov 20, 2019 at 11:01 AM Masahiko Sawada
wrote:
>
> I've attached the latest version patch set. The patch set includes all
> discussed points regarding index AM options as well as shared cost
> balance. Also I added some test cases used all types of index AM.
>
> During developments I had
73 matches
Mail list logo
