This patch moves the parse analysis component of ExecuteQuery() and
EvaluateParams() into a new transformExecuteStmt() that is called from
transformStmt(). This makes EXECUTE behave more like other utility
commands.
Effects are that error messages can have position information (see
regression t
Hello,
On Fri, Oct 25, 2019 at 7:18 AM Tomas Vondra
wrote:
> On Thu, Oct 24, 2019 at 03:48:57PM -0300, Alvaro Herrera wrote:
> >On 2019-Oct-23, kato-...@fujitsu.com wrote:
> >
> >> Hello
> >>
> >> To benchmark with tpcb model, I tried to create a foreign key in the
> >> partitioned history table
On Thu, Oct 31, 2019 at 3:45 PM Dilip Kumar wrote:
>
> On Thu, Oct 31, 2019 at 11:33 AM Dilip Kumar wrote:
> >
> > On Tue, Oct 29, 2019 at 1:59 PM Masahiko Sawada
> > wrote:
> > > Actually after increased shared_buffer I got expected results:
> > >
> > > * Test1 (after increased shared_buffers)
Hi.sorry for my English.I want to once again open the topic of 64 bit transaction id. I did not manage to find in the archive of the option that I want to discuss, so I write. If I searched poorly, then please forgive me.The idea is not very original and probably has already been considered, again
Hello,
I give a quick look and I think we can
void
psql_setup_cancel_handler(void)
{
setup_cancel_handler(psql_sigint_callback);
}
Because it does not matter for setup_cancel_handler what we passed
because it is ignoring that in case of windows.
The "psql_sigint_callback" function is
On Fri, Nov 1, 2019 at 8:00 AM Fujii Masao wrote:
> On Fri, Nov 1, 2019 at 6:34 AM Ibrar Ahmed wrote:
> >
> >
> >
> > On Thu, Oct 31, 2019 at 6:56 PM Tom Lane wrote:
> >>
> >> Fujii Masao writes:
> >> > ... I found that the command tag of
> >> > ALTER MATERIALIZED VIEW RENAME COLUMN is "ALTER
Hi
pá 1. 11. 2019 v 10:11 odesílatel Павел Ерёмин
napsal:
> Hi.
> sorry for my English.
> I want to once again open the topic of 64 bit transaction id. I did not
> manage to find in the archive of the option that I want to discuss, so I
> write. If I searched poorly, then please forgive me.
> Th
On 2019-10-29 17:10, Tom Lane wrote:
Peter Eisentraut writes:
On 2019-10-28 13:45, Robert Haas wrote:
In theory, the do_rethrow variable could conflict with a symbol
declared in the surrounding scope, but that doesn't seem like it's a
problem worth getting worked up about.
Right. A PG_TRY
Hi, hackers
As the $Subject, does anyone have one? I'd like to refer to it, and
write an example for people who is also looking for the document.
Thanks.
--
Adam Lee
On 2019-10-08 12:44, Nikolay Shaplov wrote:
В письме от понедельник, 7 октября 2019 г. 12:59:27 MSK пользователь Robert
Haas написал:
This thread is a follow up to the thread
https://www.postgresql.org/message-id/2620882.s52SJui4ql@x200m where I've
been trying to remove StdRdOptions structure a
On 2019-10-25 07:05, Andrey Borodin wrote:
21 окт. 2019 г., в 14:09, Andrey Borodin написал(а):
With Silesian corpus pglz_decompress_hacked is actually decreasing performance
on high-entropy data.
Meanwhile pglz_decompress_hacked8 is still faster than usual pglz_decompress.
In spite of this be
On 2019-10-21 08:44, Fujii Masao wrote:
Probably we can use standby mode + recovery target setting for
the almost same purpose. In this configuration, if end-of-WAL is reached
before recovery target, the startup process keeps waiting for new WAL to
be available. Then, if recovery target is reache
On 2019-10-20 00:23, Euler Taveira wrote:
You can probably achieve that using ALTER PUBLICATION to disable
publication of deletes or truncates, as the case may be, either
permanently or just for the duration of the operations you want to skip.
... then you are skipping all tables in the publica
On 2019-Nov-01, Fabien COELHO wrote:
> diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
> index 03bcd22996..389b4d7bcd 100644
> --- a/src/bin/pgbench/pgbench.c
> +++ b/src/bin/pgbench/pgbench.c
> @@ -59,9 +59,10 @@
>
> #include "common/int.h"
> #include "common/logging.h"
> -
On Thu, Oct 31, 2019 at 06:07:34PM +0900, Michael Paquier wrote:
> On Mon, Oct 28, 2019 at 10:56:33PM -0500, Justin Pryzby wrote:
> > I suppose it should something other than partition(ed), since partitions
> > can be
> > partitioned, too...
> >
> > Attaching a partition acquires a SHARE UP
On Fri, Nov 01, 2019 at 08:59:48AM -0500, Justin Pryzby wrote:
> I guess you mean because it's not a child until after the ALTER. Yes, that
> makes sense.
Yes, perhaps you have another idea than mine on how to shape this
sentence?
--
Michael
signature.asc
Description: PGP signature
On Thu, Oct 31, 2019 at 05:38:32PM +0900, Fujii Masao wrote:
> Thanks for the patch! Looks good to me.
Thanks. I have applied the core fix down to 9.4, leaving the new
assertion improvements only for HEAD.
--
Michael
signature.asc
Description: PGP signature
Yeah, I agree that there's no reason to store the digests themselves and I
really liked the idea of it being optional.
If it turns out that memory consumption on real workloads is small enough,
it could eventually be turned on by default.
I'll start working on patch
Em qui, 31 de out de 2019 às 1
On Fri, Nov 01, 2019 at 11:11:13AM -0300, Igor Calabria wrote:
Yeah, I agree that there's no reason to store the digests themselves and I
really liked the idea of it being optional.
That's not what I wrote. My point was that we *should* store the digests
themselves, otherwise we just introduce
On Thu, Oct 31, 2019 at 9:36 AM Tom Lane wrote:
> > float8 and related types are now hardcoded to pass-by-value or
> > pass-by-reference depending on whether the build is 64- or 32-bit, as
> > was previously also the default.
>
> I'm less happy with doing this. It makes it impossible to test the
Em sex, 1 de nov de 2019 às 03:42, Zhenghua Lyu escreveu:
>
> My issue: I did some spikes and tests on TPCDS 1TB Bytes data. For query
> 104, it generates
> nestloop join even with enable_nestloop set off. And the final plan's total
> cost is very huge (about 1e24). But If I enlarge the dis
On Thu, Oct 31, 2019 at 11:37 AM Andrew Dunstan
wrote:
> This patch provides a hook for a function that can supply an SSL
> passphrase. The hook can be filled in by a shared preloadable module. In
> order for that to be effective, the startup order is modified slightly.
> There is a test attached
On 25.10.2019 20:00, Pavel Stehule wrote:
>
>> So except the limitation mentioned above (which I do not
consider as critical) there is only one problem which was not
addressed: maintaining statistics for GTT.
>> If all of the following conditions are true:
>>
>> 1)
On Fri, Nov 1, 2019 at 7:41 AM Robert Haas wrote:
> Could we get around this by making Datum 8 bytes everywhere?
I really like that idea.
Even Raspberry Pi devices (which can cost as little as $35) use 64-bit
ARM processors. It's abundantly clear that 32-bit platforms do not
matter enough to jus
On Wed, Oct 30, 2019 at 9:43 AM Antonin Houska wrote:
> 5. In the first session, FlushBuffer()->TerminateBufferIO() will not clear
> BM_DIRTY because MarkBufferDirtyHint() has eventually set
> BM_JUST_DIRTIED. Thus the hint bit change itself will be written by the next
> call of FlushBuffer(). How
Hello Alvaro,
#include "common/int.h"
#include "common/logging.h"
-#include "fe_utils/conditional.h"
#include "getopt_long.h"
#include "libpq-fe.h"
+#include "fe_utils/conditional.h"
+#include "fe_utils/cancel.h"
#include "pgbench.h"
#include "portability/instr_time.h"
wtf?
I underst
On Fri, Nov 1, 2019 at 11:15 AM Konstantin Knizhnik
wrote:
> It seems to me that I have found quite elegant solution for per-backend
> statistic for GTT: I just inserting it in backend's catalog cache, but not in
> pg_statistic table itself.
> To do it I have to add InsertSysCache/InsertCatCache
On 2019-Nov-01, Fabien COELHO wrote:
> > > #include "common/int.h"
> > > #include "common/logging.h"
> > > -#include "fe_utils/conditional.h"
> > > #include "getopt_long.h"
> > > #include "libpq-fe.h"
> > > +#include "fe_utils/conditional.h"
> > > +#include "fe_utils/cancel.h"
> > > #include
On Wed, Oct 30, 2019 at 10:16 AM Asif Rehman wrote:
> 'startptr' is used by sendFile() during checksum verification. Since
> SendBackupFiles() is using sendFIle we have to set a valid WAL location.
Ugh, global variables.
Why are START_BACKUP, SEND_BACKUP_FILELIST, SEND_BACKUP_FILES, and
STOP_BAC
Hi,
On 2019-11-01 19:58:04 +1300, Thomas Munro wrote:
> On Fri, Nov 1, 2019 at 7:42 PM Zhenghua Lyu wrote:
> > It is tricky to set disable_cost a huge number. Can we come up with
> > better solution?
>
> What happens if you use DBL_MAX?
That seems like a bad idea - we add the cost multiple
>
> That's not what I wrote. My point was that we *should* store the digests
> themselves, otherwise we just introduce additional errors into the
> estimates, because it discards the weights/frequencies.
Sorry. I meant to write "no reason to *not* store the digests"
Em sex, 1 de nov de 2019 às
On 01.11.2019 18:26, Robert Haas wrote:
On Fri, Nov 1, 2019 at 11:15 AM Konstantin Knizhnik
wrote:
It seems to me that I have found quite elegant solution for per-backend
statistic for GTT: I just inserting it in backend's catalog cache, but not in
pg_statistic table itself.
To do it I hav
On Fri, Nov 1, 2019 at 12:00 PM Andres Freund wrote:
> That seems like a bad idea - we add the cost multiple times. And we
> still want to compare plans that potentially involve that cost, if
> there's no other way to plan the query.
Yeah. I kind of wonder if we shouldn't instead (a) skip adding
Hi,
As per the following code, t1 is a remote table through postgres_fdw:
test=# BEGIN;
BEGIN
test=# SELECT * FROM t1;
...
test=# PREPARE TRANSACTION 'gxid1';
ERROR: cannot prepare a transaction that modified remote tables
I have attached a patch to the documentation
On Sun, Aug 18, 2019 at 11:00 AM Tom Lane wrote:
> Perhaps the way to resolve Peter's objection is to make the syntax
> more fully like UPDATE:
>
> INSERT INTO target SET c1 = x, c2 = y+z, ... FROM tables-providing-x-y-z
>
> (with the patch as-submitted corresponding to the case with an empty
> FR
On 2019-Nov-01, Peter Eisentraut wrote:
> On 2019-10-25 07:05, Andrey Borodin wrote:
> > > 21 окт. 2019 г., в 14:09, Andrey Borodin
> > > написал(а):
> > >
> > > With Silesian corpus pglz_decompress_hacked is actually decreasing
> > > performance on high-entropy data.
> > > Meanwhile pglz_deco
Hi,
On 2019-11-01 12:22:06 -0400, Robert Haas wrote:
> On Fri, Nov 1, 2019 at 12:00 PM Andres Freund wrote:
> > That seems like a bad idea - we add the cost multiple times. And we
> > still want to compare plans that potentially involve that cost, if
> > there's no other way to plan the query.
>
Hi,
I've a basic experimental extension where I use extensible nodes. This is
the commit which adds the extensible node to the project:
https://github.com/onderkalaci/pgcolor/commit/10cba5d02a828dbee4bc140f5e88d6c44b40e5c2
Hope that gives you some pointers.
On Fri, Nov 1, 2019 at 1:18 PM Adam L
On Fri, Nov 1, 2019 at 12:43 PM Andres Freund wrote:
> Hm. That seems complicated. Is it clear that we'd always notice that we
> have no plan early enough to know which paths to reconsider? I think
> there's cases where that'd only happen a few levels up.
Yeah, there could be problems of that kin
On Fri, Nov 01, 2019 at 11:01:22PM +0900, Michael Paquier wrote:
> On Fri, Nov 01, 2019 at 08:59:48AM -0500, Justin Pryzby wrote:
> > I guess you mean because it's not a child until after the ALTER. Yes, that
> > makes sense.
>
> Yes, perhaps you have another idea than mine on how to shape this
>
On Thu, Oct 31, 2019 at 4:58 PM Andrew Dunstan
wrote:
> This patch allows the superuser to grant passwordless connection rights
> in postgres_fdw user mappings.
This is clearly something that we need, as the current code seems
woefully ignorant of the fact that passwords are not the only
authenti
On Fri, Nov 01, 2019 at 12:48:28PM -0300, Alvaro Herrera wrote:
On 2019-Nov-01, Peter Eisentraut wrote:
On 2019-10-25 07:05, Andrey Borodin wrote:
> > 21 окт. 2019 г., в 14:09, Andrey Borodin написал(а):
> >
> > With Silesian corpus pglz_decompress_hacked is actually decreasing
performance on
On Fri, Nov 01, 2019 at 09:30:52AM -0700, Jim Finnerty wrote:
re: coping with adding disable_cost more than once
Another option would be to have a 2-part Cost structure. If disable_cost is
ever added to the Cost, then you set a flag recording this. If any plans
exist that have no disable_costs
On Fri, Nov 01, 2019 at 10:25:17AM +0100, Pavel Stehule wrote:
Hi
pá 1. 11. 2019 v 10:11 odesílatel Павел Ерёмин
napsal:
Hi.
sorry for my English.
I want to once again open the topic of 64 bit transaction id. I did not
manage to find in the archive of the option that I want to discuss, so I
w
On Thu, Aug 8, 2019 at 9:42 AM Rafia Sabih wrote:
> Sounds like an interesting idea, but does it really help? Because if
> vacuum was interrupted previously, wouldn't it already know the dead
> tuples, etc in the next run quite quickly, as the VM, FSM is already
> updated for the page in the previ
On Fri, Nov 01, 2019 at 12:05:12PM +0300, Павел Ерёмин wrote:
Hi.
sorry for my English.
I want to once again open the topic of 64 bit transaction id. I did not
manage to find in the archive of the option that I want to discuss, so I
write. If I searched poorly, then please forgive me.
On 2019-11-01 12:56:30 -0400, Robert Haas wrote:
> On Fri, Nov 1, 2019 at 12:43 PM Andres Freund wrote:
> > As a first step I'd be inclined to "just" adjust disable_cost up to
> > something like 1.0e12. Unfortunately much higher and and we're getting
> > into the area where the loss of precision s
I understand that you are unhappy about something, but where the issue is
fails me, the "wtf" 3 characters are not enough to point me in the right
direction. Feel free to elaborate a little bit more:-)
I don't see why you move the "conditional.h" line out of its correct
alphabetical position (
Robert Haas wrote:
> On Wed, Oct 30, 2019 at 9:43 AM Antonin Houska wrote:
> > 5. In the first session, FlushBuffer()->TerminateBufferIO() will not clear
> > BM_DIRTY because MarkBufferDirtyHint() has eventually set
> > BM_JUST_DIRTIED. Thus the hint bit change itself will be written by the next
On 11/1/19 11:01 AM, Robert Haas wrote:
> On Thu, Oct 31, 2019 at 11:37 AM Andrew Dunstan
> wrote:
>> This patch provides a hook for a function that can supply an SSL
>> passphrase. The hook can be filled in by a shared preloadable module. In
>> order for that to be effective, the startup order
On 11/1/19 12:58 PM, Robert Haas wrote:
> On Thu, Oct 31, 2019 at 4:58 PM Andrew Dunstan
> wrote:
>> This patch allows the superuser to grant passwordless connection rights
>> in postgres_fdw user mappings.
> This is clearly something that we need, as the current code seems
> woefully ignorant o
Peter Geoghegan writes:
> On Fri, Nov 1, 2019 at 7:41 AM Robert Haas wrote:
>> Could we get around this by making Datum 8 bytes everywhere?
> I really like that idea.
> Even Raspberry Pi devices (which can cost as little as $35) use 64-bit
> ARM processors. It's abundantly clear that 32-bit pla
On Fri, Nov 1, 2019 at 6:31 PM Robert Haas wrote:
> On Sun, Aug 18, 2019 at 11:00 AM Tom Lane wrote:
> > Perhaps the way to resolve Peter's objection is to make the syntax
> > more fully like UPDATE:
> >
> > INSERT INTO target SET c1 = x, c2 = y+z, ... FROM tables-providing-x-y-z
> >
> > (with t
Peter Eisentraut wrote:
> I looked into this problem. The way to address this would be adding
> proper collation support to the text search subsystem. See the TODO
> markers in src/backend/tsearch/ts_locale.c for starting points. These
> APIs spread out to a lot of places, so it will
On Fri, Nov 1, 2019 at 11:00 AM Tom Lane wrote:
> This line of argument seems to me to be the moral equivalent of
> "let's drop 32-bit support altogether". I'm not entirely on board
> with that.
I don't think that those two things are equivalent at all. There may
even be workloads that will bene
On 2019-Nov-01, Fabien COELHO wrote:
> Because "cancel.h" requires PGconn declaration, thus must appear after
> "libpq-fe.h",
Then you need to add #include libpq-fe.h in cancel.h. Our policy is
that headers compile standalone (c.h / postgres_fe.h / postgres.h
excluded).
--
Álvaro Herrera
On Mon, Aug 5, 2019 at 8:44 PM Bruce Momjian wrote:
> Right. The 8k page LSN changes each time the page is modified, and the
> is part of the page nonce.
What about hint bit changes?
I think even with wal_log_hints=on, it's not the case that *every*
change to hint bits results in an LSN change.
On Tue, Aug 6, 2019 at 10:36 AM Bruce Momjian wrote:
> OK, I think you are missing something. Let me go over the details.
> First, I think we are all agreed we are using CTR for heap/index pages,
> and for WAL, because CTR allows byte granularity, it is faster, and
> might be more secure.
>
> So
On Fri, Nov 1, 2019 at 3:15 PM Peter Geoghegan wrote:
> I don't think that those two things are equivalent at all. There may
> even be workloads that will benefit when run on 32-bit hardware.
> Having to palloc() and pfree() with 8 byte integers is probably very
> slow.
Yeah! I mean, users who ar
It would be useful to have CREATE INDEX CONCURRENTLY be ignored by
vacuuming's OldestXmin. Frequently in OLTP scenarios, CIC transactions
are severely disruptive because they are the only long-running
transactions in the system, and VACUUM has to keep rows only for their
sake, pointlessly. The mo
On Fri, Nov 1, 2019 at 1:19 PM Robert Haas wrote:
> Yeah! I mean, users who are using only 4-byte or smaller pass-by-value
> quantities will be harmed, especially in cases where they are storing
> a lot of them at the same time (e.g. sorting) and especially if they
> double their space consumption
Then you need to add #include libpq-fe.h in cancel.h. Our policy is
that headers compile standalone (c.h / postgres_fe.h / postgres.h
excluded).
Ok. I do not make a habit of adding headers in postgres, so I did not
notice there was an alphabetical logic to that.
Attached patch v4 does it.
On 30/10/2019 09:04, Fabien COELHO wrote:
>
>> I think possibly what the spec says (and that neither my patch nor
>> Peter's implements) is assigning the alias just to the > list>.
>
> I think you are right, the alias is only on the identical columns.
>
> It solves the issue I raised about inacces
> On 30 Oct 2019, at 01:10, Andres Freund wrote:
>Make StringInfo available to frontend code.
I’ve certainly wanted just that on multiple occasions, so +1 on this.
>Therefore it seems best to just making StringInfo being usable by
>frontend code. There's not much to do for that, exc
I wrote:
> Anyway, with the benefit of more time to let this thing percolate
> in my hindbrain, I am thinking that the fundamental error we've made
> is to do transformAlterTableStmt in advance of execution *at all*.
> The idea I now have is to scrap that, and instead apply the
> parse_utilcmd.c tr
Hi,
On 2019-11-01 23:19:33 +0100, Daniel Gustafsson wrote:
> > On 30 Oct 2019, at 01:10, Andres Freund wrote:
>
> >Make StringInfo available to frontend code.
>
> I’ve certainly wanted just that on multiple occasions, so +1 on this.
Cool.
> + * StringInfo provides an extensible string da
On Fri, Nov 01, 2019 at 02:00:10PM -0400, Tom Lane wrote:
> Peter Geoghegan writes:
>> Even Raspberry Pi devices (which can cost as little as $35) use 64-bit
>> ARM processors. It's abundantly clear that 32-bit platforms do not
>> matter enough to justify keeping all the SIZEOF_DATUM crud around.
On 2019-11-02 11:47:26 +0900, Michael Paquier wrote:
> On Fri, Nov 01, 2019 at 02:00:10PM -0400, Tom Lane wrote:
> > Peter Geoghegan writes:
> >> Even Raspberry Pi devices (which can cost as little as $35) use 64-bit
> >> ARM processors. It's abundantly clear that 32-bit platforms do not
> >> matt
On Fri, Nov 1, 2019 at 7:47 PM Michael Paquier wrote:
> > This line of argument seems to me to be the moral equivalent of
> > "let's drop 32-bit support altogether". I'm not entirely on board
> > with that. Certainly, a lot of the world is 64-bit these days,
> > but people are still building sma
On Fri, Nov 01, 2019 at 09:58:26AM +0900, Amit Langote wrote:
> On Thu, Oct 31, 2019 at 1:45 PM Michael Paquier wrote:
>> The patch is rather simple as per the attached, with extended
>> regression tests included. I have not checked on back-branches yet,
>> but that's visibly wrong since 8b08f7d
pá 1. 11. 2019 v 17:09 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 01.11.2019 18:26, Robert Haas wrote:
> > On Fri, Nov 1, 2019 at 11:15 AM Konstantin Knizhnik
> > wrote:
> >> It seems to me that I have found quite elegant solution for per-backend
> statistic for
71 matches
Mail list logo
