When updating a table row with generated columns, we only need to
recompute those generated columns whose base columns have changed in
this update and keep the rest unchanged. This can result in a
significant performance benefit (easy to reproduce for example with a
tsvector column). The requ
On 2019-10-29 03:33, Thomas Munro wrote:
Seems to work as described with -E UTF-8, but it fails with clusters
using -E SQL_ASCII. That causes the pg_upgrade check to fail on
machines where that is the default encoding chosen by initdb (where
unpatched master succeeds):
pg_restore: creating COLL
Michael Paquier writes:
> On Fri, Dec 20, 2019 at 02:42:22PM -0500, Tom Lane wrote:
>> I notice in testing this that the "nosuper" business added by
>> 6136e94dc is broken in more ways than what the buildfarm is
>> complaining about: it leaves the role around at the end of the
>> test.
> Roles le
On Fri, Dec 20, 2019 at 09:17:14AM +0100, Peter Eisentraut wrote:
> committed with that comment removed
Yeah, thanks!
--
Michael
signature.asc
Description: PGP signature
On Fri, Dec 20, 2019 at 08:57:04AM -0500, Bruce Momjian wrote:
> I can imagine using larger pgstat_track_activity_query_size values for
> data warehouse queries, where they are long and there are only a few of
> them.
Why are those queries that long anyway? A too long IN clause with an
insane amo
On Fri, Dec 20, 2019 at 04:30:38PM +0100, Antonin Houska wrote:
> I wanted to register the patch for the next CF so it's not forgotten, but see
> it's already there. Why have you set the status to "withdrawn"?
Because my patch was incorrect, and I did not make enough bandwidth to
think more on the
On Fri, Dec 20, 2019 at 03:07:26PM +0500, Andrey Borodin wrote:
>> Sending a cancellation is currently the only way to resume after
>> disabling synchronous replication. Some HA solutions (e.g.
>> pg_auto_failover) rely on this behaviour. Would it be worth checking
>> whether synchronous replicatio
On Fri, Dec 20, 2019 at 11:33:02AM -0300, Alvaro Herrera wrote:
> Fair enough.
And done:
https://commitfest.postgresql.org/25/2251/
Sorry for the late reply.
--
Michael
signature.asc
Description: PGP signature
On Fri, Dec 20, 2019 at 02:42:22PM -0500, Tom Lane wrote:
> Concretely, I think we ought to do (and back-patch) the attached.
Thanks for the fix, I have not been able to look at that.
> I notice in testing this that the "nosuper" business added by
> 6136e94dc is broken in more ways than what the
On 12/18/19, 8:34 AM, "Bossart, Nathan" wrote:
> On 12/17/19, 2:26 AM, "Kyotaro Horiguchi" wrote:
>> If so, we could amend also that case by marking the last segment as
>> .ready when XLogWrite writes the first bytes of the next segment. (As
>> the further corner-case, it still doesn't work if a
Hi,
On 2019-12-20 16:38:32 -0500, Bruce Momjian wrote:
> On Thu, Dec 12, 2019 at 09:31:22AM +0800, Craig Ringer wrote:
> > On Fri, 6 Dec 2019 at 09:57, Michael Paquier wrote:
> >
> > On Thu, Dec 05, 2019 at 12:23:40PM +0300, Konstantin Knizhnik wrote:
> > > Concerning keeping PGPROC size
while preparing the patch for the Commitfest, I found a bug in the
to_char() function that is quite correlated with this issue:
SELECT to_char('1997-02-01'::date, '-WW-D')
returns: 1997-05-7 -> which is ok, I believe. Feb, 1st was on
Saturday,
so counting from Sundays, it was day 7 of w
Hi,
On 2019-12-20 11:12:53 -0500, Tom Lane wrote:
> (2) Explicitly mark Vars as being nullable by some outer join. I think
> we could probably get this down to one additional integer field in
> struct Var, so it wouldn't be too much of a penalty.
I've for a while wished that we could, e.g. so ex
Hi Tom,
thanks for answering!
I commited two different patches:
---
The first one is for the strange behaviour of to_char(), which could be
seen as a bug, I believe. As described earlier, to_char() with the
'WW-D' pattern could return wrong week numbers.
The non-ISO week number is defi
On Thu, Dec 12, 2019 at 09:31:22AM +0800, Craig Ringer wrote:
> On Fri, 6 Dec 2019 at 09:57, Michael Paquier wrote:
>
> On Thu, Dec 05, 2019 at 12:23:40PM +0300, Konstantin Knizhnik wrote:
> > Concerning keeping PGPROC size as small as possible, I agree that it is
> > reasonable argum
Andreas Karlsson writes:
> On 12/20/19 1:54 AM, Andreas Karlsson wrote:
>> On 12/20/19 1:01 AM, Ranier Vilela wrote:> First case:
>>> Third case:
>>> \ src \ backend \ utils \ cache \ relcache.c (line 5190)
>>> if (relation-> rd_pubactions)
>>>
>>> It will never be executed, because if relation->
Andrey Borodin writes:
> I think proper solution here would be to add GUC to disallow cancellation of
> synchronous replication.
This sounds entirely insane to me. There is no possibility that you
can prevent a failure from occurring at this step.
> Three is still a problem when backend is not
Alvaro Herrera writes:
> On 2019-Dec-20, Paul A Jungwirth wrote:
>> Is it permitted to add casts with polymorphic inputs & outputs? Is
>> that something that we would actually want to do? I'd probably need
>> both the polymorphic and concrete casts so that you could still say
>> `int4range(1,2)::i
Alvaro Herrera writes:
> This very small patch removes some duplicated code in pg_publication.
Seems like the extra test on missing_oid is unnecessary:
+ oid = get_publication_oid(pubname, missing_ok);
+ if (!OidIsValid(oid) && missing_ok)
+ return NULL;
As coded, it's
This very small patch removes some duplicated code in pg_publication.
--
Álvaro Herrerahttp://www.linkedin.com/in/alvherre
diff --git a/src/backend/catalog/pg_publication.c b/src/backend/catalog/pg_publication.c
index d442c8e0bb..347324f320 100644
--- a/src/backend/cat
I wrote:
> This is a bit messier. But I think that the discrepancy is not
> really the fault of this patch: rather, it's a bug in the way the
> GSS support was put into libpq. I thought we had a policy that
> all builds would recognize all possible parameters and then
> perhaps fail later. Certa
On 2019-Dec-20, Paul A Jungwirth wrote:
> Is it permitted to add casts with polymorphic inputs & outputs? Is
> that something that we would actually want to do? I'd probably need
> both the polymorphic and concrete casts so that you could still say
> `int4range(1,2)::int4multirange`.
I'm embarras
On Fri, Dec 20, 2019 at 10:19 AM Pavel Stehule wrote:
> I had a talk with Paul about possible simplification of designed operators.
> Last message from Paul was - he is working on new version.
Thanks Alvaro & Pavel for helping move this forward. I've added the
casts but they aren't used automati
On 2019-Dec-20, Alvaro Herrera wrote:
> I am not convinced that adding TYPTYPE_MULTIRANGE is really necessary.
> Why can't we just treat those types as TYPTYPE_RANGE and distinguish
> them using TYPCATEGORY_MULTIRANGE? That's what we do for arrays. I'll
> try to do that next.
I think this can b
[ redirecting to -hackers ]
Michael Paquier writes:
> On Fri, Dec 20, 2019 at 05:55:10AM +, Andrew Dunstan wrote:
>> Superuser can permit passwordless connections on postgres_fdw
> After this commit a couple of buildfarm animals are unhappy with the
> regression tests of postgres_fdw:
Yeah,
pá 20. 12. 2019 v 18:43 odesílatel Alvaro Herrera
napsal:
> I took the liberty of rebasing this series on top of recent branch
> master. The first four are mostly Paul's originals, except for conflict
> fixes; the rest are changes I'm proposing as I go along figuring out the
> whole thing. (I w
On Fri, Dec 20, 2019 at 06:14:09PM +, Andrew Gierth wrote:
> > "Bruce" == Bruce Momjian writes:
>
> >> This came up recently on IRC, not sure if the report there was
> >> passed on at all.
> >>
> >> ProcessStartupPacket assumes that there will be only one negotiation
> >> request fo
Robert Haas writes:
> On Fri, Dec 20, 2019 at 11:13 AM Tom Lane wrote:
>> The alternatives that seem plausible at this point are
>> ...
>> (2) Explicitly mark Vars as being nullable by some outer join. I think
>> we could probably get this down to one additional integer field in
>> struct Var, s
> "Bruce" == Bruce Momjian writes:
>> This came up recently on IRC, not sure if the report there was
>> passed on at all.
>>
>> ProcessStartupPacket assumes that there will be only one negotiation
>> request for an encrypted connection, but libpq is capable of issuing
>> two: it will a
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Sun, Dec 1, 2019 at 01:13:31AM +, Andrew Gierth wrote:
> > This came up recently on IRC, not sure if the report there was passed on
> > at all.
> >
> > ProcessStartupPacket assumes that there will be only one negotiation
> > request f
On Fri, 20 Dec 2019 at 17:46, Tom Lane wrote:
> Simon Riggs writes:
> > On Fri, 20 Dec 2019 at 13:07, Robert Haas wrote:
> >> With regard to this point, I second Tomas's comments.
>
> > I also agree with Tomas' comments. I am explaining *why* it will be an
> > improvement, expanding on my earli
Simon Riggs writes:
> On Fri, 20 Dec 2019 at 13:07, Robert Haas wrote:
>> With regard to this point, I second Tomas's comments.
> I also agree with Tomas' comments. I am explaining *why* it will be an
> improvement, expanding on my earlier notes.
> This function is called extremely frequently in
On Sun, Dec 1, 2019 at 01:13:31AM +, Andrew Gierth wrote:
> This came up recently on IRC, not sure if the report there was passed on
> at all.
>
> ProcessStartupPacket assumes that there will be only one negotiation
> request for an encrypted connection, but libpq is capable of issuing
> two:
Mark Lorenz writes:
> while preparing the patch for the Commitfest, I found a bug in the
> to_char() function that is quite correlated with this issue:
> SELECT to_char('1997-02-01'::date, '-WW-D')
> returns: 1997-05-7 -> which is ok, I believe. Feb, 1st was on Saturday,
> so counting from
On Fri, 20 Dec 2019 at 13:07, Robert Haas wrote:
>
> > Read only transactions should have a fast path thru this function since
> they frequently read more data than write transactions.
>
> With regard to this point, I second Tomas's comments.
>
I also agree with Tomas' comments. I am explaining
Mark Lorenz writes:
> I got the advice to split the patches for:
> - fixing the to_char() function
> - changing the to_date()/to_timestamp() behaviour
> So I appended the split patches.
I'm a bit skeptical of the premise here. The fine manual says
In to_timestamp and to_date, weekday names
This is a usability complaint. If one knows enough about vacuum and/or
logging, I'm sure there's no issue.
Right now vacuum shows:
| 1 postgres=# VACUUM t;
| 2 DEBUG: vacuuming "public.t"
| 3 DEBUG: scanned index "t_i_key" to remove 999 row versions
| 4 DETAIL: CPU: user: 0.00 s, sys
On Fri, Dec 20, 2019 at 11:13 AM Tom Lane wrote:
> The alternatives that seem plausible at this point are
>
> (1) Create some sort of wrapper node indicating "the contents of this
> expression might be replaced by NULL". This is basically what the
> planner's PlaceHolderVars do, so maybe we'd jus
I wrote:
> I started to think a little harder about the rough ideas I sketched
> yesterday in [1] about making the planner deal with outer joins in
> a less ad-hoc manner.
> [1] https://www.postgresql.org/message-id/7771.1576452845%40sss.pgh.pa.us
After further study, the idea of using join alias
Hi,
I got the advice to split the patches for:
- fixing the to_char() function
- changing the to_date()/to_timestamp() behaviour
So I appended the split patches.
Kind regards,
Mark Lorenz
From 4e35bd88bef1916e7d11ad0776b3075e3183f7d0 Mon Sep 17 00:00:00 2001
From: Mark Lorenz
Date: Fri, 20 Dec
On Fri, Dec 20, 2019 at 8:24 AM Suraj Kharage
wrote:
> Thank you for review comments.
Thanks for the new version.
+ --verify-backup
Whitespace.
+struct manifesthash_hash *hashtab;
Uh, I had it in mind that you would nuke this line completely, not
just remove "typedef" from it. You shoul
On 12/20/19 1:54 AM, Andreas Karlsson wrote:
On 12/20/19 1:01 AM, Ranier Vilela wrote:> First case:
Third case:
\ src \ backend \ utils \ cache \ relcache.c (line 5190)
if (relation-> rd_pubactions)
It will never be executed, because if relation-> rd_pubactions is
true, the function returns on
Antonin Houska wrote:
> Michael Paquier wrote:
>
> > On Mon, Nov 11, 2019 at 10:03:14AM +0100, Antonin Houska wrote:
> > > This looks good to me.
> >
> > Actually, no, this is not good. I have been studying more the patch,
> > and after stressing more this code path with a cluster having
> >
Fixed some typos in attached v5-0002 patch. Please consider this patch for
review.
On Fri, Dec 20, 2019 at 6:54 PM Suraj Kharage <
suraj.khar...@enterprisedb.com> wrote:
> Thank you for review comments.
>
> On Thu, Dec 19, 2019 at 2:54 AM Robert Haas wrote:
>
>> On Tue, Dec 17, 2019 at 12:54 AM
On 2019-Dec-20, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Dec-20, Michael Paquier wrote:
> >> The patch has been committed once as of e788bd9, then reverted as of
> >> 9555cc8 because it had a couple of fundamental issues and many people
> >> were not happy with it.
>
> > Hmm, should
Alvaro Herrera writes:
> On 2019-Dec-20, Michael Paquier wrote:
>> The patch has been committed once as of e788bd9, then reverted as of
>> 9555cc8 because it had a couple of fundamental issues and many people
>> were not happy with it.
> Hmm, should we mark the commitfest entry as rejected then?
On 2019-Dec-20, Michael Paquier wrote:
> On Fri, Dec 20, 2019 at 02:45:26AM +, tsunakawa.ta...@fujitsu.com wrote:
> > I've got interested in this. What's the current status of this
> > patch? The CF entry shows it was committed.
> >
> > But I understood not, because the relevant code doesn't
Hi,
I fixed the described issue in the to char() function.
The output of the current version is:
postgres=# SELECT to_char('1997-02-01'::date, '-WW-D');
to_char
-
1997-05-7
(1 row)
postgres=# SELECT to_char('1997-02-03'::date, '-WW-D');
to_char
-
1997-05-2
(1 row)
ROS Didier writes:
> I created a read-only role as follows:
> psql -p 5434 kidsdpn03
> CREATE ROLE kidsdpn03_ro PASSWORD 'xxx';
> ALTER ROLE kidsdpn03_ro WITH LOGIN;
> GRANT CONNECT ON DATABASE kidsdpn03 TO kidsdpn03_ro;
> GRANT USAGE ON SCHEMA kidsdpn03 TO kidsdpn03_ro;
> GRANT SELECT ON ALL TABL
On Fri, Dec 20, 2019 at 02:35:37PM +0300, Alexey Kondratov wrote:
> On 19.12.2019 20:52, Robert Haas wrote:
> > On Thu, Dec 19, 2019 at 10:59 AM Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > Good question. I am in favor of allowing a larger value if no one
> > > > objects. I don't think a
On Fri, Dec 20, 2019 at 2:00 PM Kyotaro Horiguchi
wrote:
>
> Hello.
>
> At Fri, 13 Dec 2019 14:46:20 +0530, Amit Kapila
> wrote in
> > On Wed, Dec 11, 2019 at 11:46 PM Robert Haas wrote:
> > >
> > > On Mon, Dec 2, 2019 at 3:32 AM Dilip Kumar wrote:
> > > > I have rebased the patch set on the l
On Fri, Dec 20, 2019 at 11:47 AM Masahiko Sawada
wrote:
>
> On Mon, 2 Dec 2019 at 17:32, Dilip Kumar wrote:
> >
> > On Sun, Dec 1, 2019 at 7:58 AM Michael Paquier wrote:
> > >
> > > On Fri, Nov 22, 2019 at 01:18:11PM +0530, Dilip Kumar wrote:
> > > > I have rebased the patch on the latest head a
Thank you for review comments.
On Thu, Dec 19, 2019 at 2:54 AM Robert Haas wrote:
> On Tue, Dec 17, 2019 at 12:54 AM Suraj Kharage
> wrote:
> > I have implemented the simplehash in backup validator patch as Robert
> suggested. Please find attached 0002 patch for the same.
> >
> > kindly review
On Fri, Dec 20, 2019 at 12:46 AM Simon Riggs wrote:
> If the TopTransactionId is not assigned, we can leave the whole function more
> quickly, not just avoid a test.
Those things are not really any different from each other. You leave
the function when you've done all the necessary tests
>
Hi
I created a read-only role as follows:
psql -p 5434 kidsdpn03
CREATE ROLE kidsdpn03_ro PASSWORD 'xxx';
ALTER ROLE kidsdpn03_ro WITH LOGIN;
GRANT CONNECT ON DATABASE kidsdpn03 TO kidsdpn03_ro;
GRANT USAGE ON SCHEMA kidsdpn03 TO kidsdpn03_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA kidsdpn03 TO kidsd
Hi,
While testing this feature with parallel vacuum on "TEMPORARY TABLE", I got
a server crash on PG Head+V36_patch.
Changed configuration parameters and Stack trace are as below:
autovacuum = on
max_worker_processes = 4
shared_buffers = 10MB
max_parallel_workers = 8
max_parallel_maintenance_work
On 19.12.2019 20:52, Robert Haas wrote:
On Thu, Dec 19, 2019 at 10:59 AM Tom Lane wrote:
Bruce Momjian writes:
Good question. I am in favor of allowing a larger value if no one
objects. I don't think adding the min/max is helpful.
The original poster.
And probably anyone else, who debu
On Fri, 20 Dec 2019 13:41:25 +0900 (JST)
Kyotaro Horiguchi wrote:
> At Fri, 20 Dec 2019 00:35:19 +0100, Jehan-Guillaume de Rorthais
> wrote in
> > On Fri, 13 Dec 2019 16:12:55 +0900
> > Michael Paquier wrote:
>
> The first one;
>
> > > I mentioned a SRF function which takes an input argume
> 20 дек. 2019 г., в 12:23, Marco Slot написал(а):
>
> On Fri, Dec 20, 2019 at 6:04 AM Andrey Borodin wrote:
>> I think proper solution here would be to add GUC to disallow cancellation of
>> synchronous replication. Retry step 3 will wait on locks after hanging 1 and
>> data will be consis
On Thu, 19 Dec 2019 19:19:56 +0100
Peter Eisentraut wrote:
> On 2019-12-19 19:15, Dave Cramer wrote:
> > It seems that if you drop the publication on an existing slot it needs
> > to be recreated. Is this expected behaviour
>
> A publication is not associated with a slot. Only a subscription
On Sat, Dec 14, 2019 at 06:32:25PM +0100, Tomas Vondra wrote:
> I've done a bit more testing on this, after resolving a couple of minor
> conflicts due to recent commits (rebased version attached).
>
> In particular, I've made a comparison with different dataset sizes,
> group sizes, GUC settings
Hi,
while preparing the patch for the Commitfest, I found a bug in the
to_char() function that is quite correlated with this issue:
SELECT to_char('1997-02-01'::date, '-WW-D')
returns: 1997-05-7 -> which is ok, I believe. Feb, 1st was on Saturday,
so counting from Sundays, it was day 7 o
Hello.
At Fri, 13 Dec 2019 14:46:20 +0530, Amit Kapila wrote
in
> On Wed, Dec 11, 2019 at 11:46 PM Robert Haas wrote:
> >
> > On Mon, Dec 2, 2019 at 3:32 AM Dilip Kumar wrote:
> > > I have rebased the patch set on the latest head.
> >
> > 0001 looks like a clever approach, but are you sure it
On 2019-12-19 08:49, Michael Paquier wrote:
On Thu, Dec 19, 2019 at 08:31:05AM +0100, Peter Eisentraut wrote:
On 2019-12-19 04:59, Michael Paquier wrote:
This part needs a comment. Like it is the equivalent of what
src/common/'s Makefile does or something like that?
This was meant to be addr
> I'm starting to take a closer look at this feature. I've just finished
> reading the discussion, excluding other referenced materials.
Thank you!
> The following IVM wiki page returns an error. Does anybody know what's wrong?
>
> https://wiki.postgresql.org/wiki/Incremental_View_Maintenance
65 matches
Mail list logo
