Hello David,
vagrant@vagrant:~$ /usr/local/pgsql/bin/psql -v ON_ERROR_STOP=1 -f two.psql
-f three.psql postgres
?column?
--
2
(1 row)
?column?
--
3
(1 row)
(there is a \quit at the end of two.psql)
Yep, that summarizes my issues!
ON_ERROR_STOP is only of SQL e
Hello Tom,
- when the current script is included from something,
you quit the current script and proceed after the \i of next -f, BAD
Question: is there any way to really abort a psql script from an included
file?
Under what circumstances would it be appropriate for a script to take
Hi,
On 2022-11-19 16:12:24 +1300, Thomas Munro wrote:
> Is there a way to find out about new git commits that is more
> efficient and timely than running N git fetches or whatever every
> minute in a cron job? Maybe some kind of long polling where you send
> an HTTP request that says "I think the
Hi,
In [1] Robert justifiably complained about the use of PROC_QUEUE. I've
previously been bothered by this in [2], but didn't get around to finishing
the patches.
One thing that made me hesitate was the naming of the function for a) checking
whether a dlist_node is a list, b) initializing and de
On Sun, Nov 20, 2022 at 1:35 AM Magnus Hagander wrote:
> tl,tr; it's not there now, but yes if we can find a smart way for th ebf
> clients to consume it, it is something we could build and deploy fairly
> easily.
Cool -- it sounds a lot like you've thought about this already :-)
About the cli
On Fri, Nov 18, 2022 at 10:23:58AM +0900, Michael Paquier wrote:
> Please note that in order to avoid tweaks when choosing the attribute
> name of function call, this needs a total of 8 new catalog functions
> mapping to the SQL keywords, which is what the test added by 2e0d80c
> is about:
> - curr
On 11/19/22 17:24, Tom Lane wrote:
Andres Freund writes:
On 2022-11-19 17:10:57 -0500, Joe Conway wrote:
Rishu Bagga pointed out to me offlist that this catversion bump seems
flawed:
/* mmddN */
-#define CATALOG_VERSION_NO 202211121
+#define CATALOG_VERSION_NO 2022
Andres Freund writes:
> On 2022-11-19 17:10:57 -0500, Joe Conway wrote:
>> Rishu Bagga pointed out to me offlist that this catversion bump seems
>> flawed:
>> /* mmddN */
>> -#define CATALOG_VERSION_NO 202211121
>> +#define CATALOG_VERSION_NO 202211821
>> I think that
Hi,
On 2022-11-19 17:10:57 -0500, Joe Conway wrote:
> Rishu Bagga pointed out to me offlist that this catversion bump seems
> flawed:
>
> diff --git a/src/include/catalog/catversion.h
> b/src/include/catalog/catversion.h
> index
> c6ef593207c227ce10b0c897379476b553974f67..b3a57136b755fed182b4518
Hi,
On 2022-11-19 15:45:06 -0600, Justin Pryzby wrote:
> What do you mean "temporarily" ? I think you're implying that the
> Warnings task is fast but (at least right now) it is not.
In the sense that we don't need all CPUs until the whole commit has finished
testing (none of the tasks are the s
On 11/18/22 16:18, Robert Haas wrote:
Fix typos and bump catversion.
Typos reported by Álvaro Herrera and Erik Rijkers.
Catversion bump for 3d14e171e9e2236139e8976f3309a588bcc8683b was
inadvertently omitted.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/2fb6154
On Sat, Nov 19, 2022 at 01:18:54PM -0800, Andres Freund wrote:
> > Also, if CompilerWarnings doesn't depend on Linux, that means those two
> > tasks will normally start and run simultaneously, which means a single
> > branch will use all 8 of the linux CPUs available from cirrus. Is that
> > inten
Hi,
On 2022-11-19 13:18:54 -0800, Andres Freund wrote:
> > Also, if CompilerWarnings doesn't depend on Linux, that means those two
> > tasks will normally start and run simultaneously, which means a single
> > branch will use all 8 of the linux CPUs available from cirrus. Is that
> > intentional?
Hi,
On 2022-11-19 14:22:20 -0600, Justin Pryzby wrote:
> On Sun, Oct 02, 2022 at 01:52:01PM -0700, Andres Freund wrote:
> >
> > +# To avoid unnecessarily spinning up a lot of VMs / containers for entirely
> > +# broken commits, have a very minimal test that all others depend on.
> > +task:
> > +
On Sun, Oct 02, 2022 at 01:52:01PM -0700, Andres Freund wrote:
>
> +# To avoid unnecessarily spinning up a lot of VMs / containers for entirely
> +# broken commits, have a very minimal test that all others depend on.
> +task:
> + name: SanityCheck
Maybe this should be named 00-SanityCheck, so i
Hi,
On 2022-11-19 10:56:33 -0500, Andrew Dunstan wrote:
> > Perhaps we should just export a directory in configure instead of this
> > guessing game?
>
> I think the obvious candidate would be to export top_builddir from
> src/Makefile.global. That would remove the need to infer it from
> TESTDAT
I missed attaching the patches.
--
David Geier
(ServiceNow)
From f4e962729ca605498d0c8bfc97d0f42d68a0df06 Mon Sep 17 00:00:00 2001
From: David Geier
Date: Thu, 17 Nov 2022 10:22:01 +0100
Subject: [PATCH 1/2] WIP: Change instr_time to just store nanoseconds, that's
cheaper.
---
src/include/por
I think it would be great to get this patch committed. Beyond the
reasons already mentioned, the significant overhead also tends to skew
the reported runtimes in ways that makes it difficult to compare them.
For example, if two nodes are executed equally often but one needs twice
the time to pr
On Sat, Nov 19, 2022 at 12:59 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Sat, Nov 19, 2022 at 12:49 PM Tom Lane wrote:
>
>> Greg Stark writes:
>> > On Sat, 19 Nov 2022 at 14:10, Tom Lane wrote:
>> >> Under what circumstances would it be appropriate for a script to take
>> >>
On Sat, Nov 19, 2022 at 12:49 PM Tom Lane wrote:
> Greg Stark writes:
> > On Sat, 19 Nov 2022 at 14:10, Tom Lane wrote:
> >> Under what circumstances would it be appropriate for a script to take
> >> it on itself to decide that? It has no way of knowing what the next -f
> >> option is or what
Greg Stark writes:
> On Sat, 19 Nov 2022 at 14:10, Tom Lane wrote:
>> Under what circumstances would it be appropriate for a script to take
>> it on itself to decide that? It has no way of knowing what the next -f
>> option is or what the user intended.
> Presumably when they're written by the
Attached patch has vacuumlazy.c pass its VacuumParams state directly
to vacuum_set_xid_limits(), the vacuum.c function that figures out
which actual cutoffs for freezing should be used. The patch also makes
the function use output parameter symbol names that match those used
by its vacuumlazy.c cal
On Sat, 19 Nov 2022 at 14:10, Tom Lane wrote:
> Under what circumstances would it be appropriate for a script to take
> it on itself to decide that? It has no way of knowing what the next -f
> option is or what the user intended.
Presumably when they're written by the same person so the script d
сб, 19 нояб. 2022 г. в 15:51, Peter Eisentraut
:
>
> On 19.11.22 13:12, Марина Полякова wrote:
> >> I'm not in favor of changing this. The existing code intentionally
> >> tries to centralize the "ICU is not supported in this build" knowledge
> >> in few places. Your patch tries to make this chec
On Sat, Nov 19, 2022 at 12:10 PM Tom Lane wrote:
> Fabien COELHO writes:
> > - when the current script is included from something,
> > you quit the current script and proceed after the \i of next -f, BAD
>
> > Question: is there any way to really abort a psql script from an
> included
> >
Fabien COELHO writes:
> - when the current script is included from something,
> you quit the current script and proceed after the \i of next -f, BAD
> Question: is there any way to really abort a psql script from an included
> file?
Under what circumstances would it be appropriate for a s
Hello devs,
I want to abort a psql script. How can I do that? The answer seems to be
\quit, but it is not so simple:
- when the current script is from a terminal, you exit psql, OK
- when the current script is from a file (-f, <), you exit psql, OK
- when the current script is included
On Fri, Nov 18, 2022 at 09:05:04AM -0800, Nathan Bossart wrote:
> rebased
another rebase
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 6e2001411107790991037e91f8d2f9411e2f4fa6 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 7 Sep 2022 22:25:29 -0700
Subject: [PATC
On Fri, Nov 18, 2022 at 04:19:15PM -0500, Robert Haas wrote:
> On Fri, Nov 18, 2022 at 1:50 PM Erik Rijkers wrote:
> > In grant.sgml,
> >
> >'actualy permisions'
> >
> > looks a bit unorthodox.
>
> Fixed that, and the other mistake Álvaro spotted, and also bumped
> catversion because I forgot
Gilles Darold writes:
> Le 17/11/2022 à 17:59, Tom Lane a écrit :
>> I didn't want to back-patch e3fcbbd62 at the time, but it's probably aged
>> long enough now to be safe to back-patch. If we do anything here,
>> it should be to back-patch the whole thing, else we've only partially
>> fixed the
On 2022-11-15 Tu 20:51, Andres Freund wrote:
>> @@ -140,6 +143,27 @@ INIT
>>
>> # Tracking of last port value assigned to accelerate free port lookup.
>> $last_port_assigned = int(rand() * 16384) + 49152;
>> +
>> +# Set the port lock directory
>> +
>> +# If we're told to use a
On 2022-11-19 Sa 09:33, Tom Lane wrote:
> Tomas Vondra writes:
>> On 11/19/22 14:51, Andrew Dunstan wrote:
>>> On 2022-11-19 Sa 05:34, Tomas Vondra wrote:
I wonder if it'd make sense to have some simple & optional alerting
based on how long ago the machine reported the last result. Sen
Tomas Vondra writes:
> On 11/19/22 14:51, Andrew Dunstan wrote:
>> On 2022-11-19 Sa 05:34, Tomas Vondra wrote:
>>> I wonder if it'd make sense to have some simple & optional alerting
>>> based on how long ago the machine reported the last result. Send e-mail
>>> if there was no report for a month
On 11/19/22 14:51, Andrew Dunstan wrote:
>
> On 2022-11-19 Sa 05:34, Tomas Vondra wrote:
>>
>> I wonder if it'd make sense to have some simple & optional alerting
>> based on how long ago the machine reported the last result. Send e-mail
>> if there was no report for a month or so would be enough.
On 2022-11-19 Sa 05:34, Tomas Vondra wrote:
>
> I wonder if it'd make sense to have some simple & optional alerting
> based on how long ago the machine reported the last result. Send e-mail
> if there was no report for a month or so would be enough.
This has been part of the buildfarm for a ver
On 2022-11-18 Fr 22:12, Thomas Munro wrote:
> Hi,
>
> Is there a way to find out about new git commits that is more
> efficient and timely than running N git fetches or whatever every
> minute in a cron job? Maybe some kind of long polling where you send
> an HTTP request that says "I think the
Hi,
I'm unable to reset stats. Please help me to fix this?
testdb => select * from pg_stat_reset_replication_slot(NULL);
ERROR: permission denied for function pg_stat_reset_replication_slot
Regards,
*Satya*
Hi all,
Working with PostgreSQL Logical Replication is just great! It helps a lot
doing real time replication for analytical purposes without using any other
3d party service. Although all these years working as product architect of
reporting i have noted a few requirements which are always a chal
On 19.11.22 13:12, Марина Полякова wrote:
I'm not in favor of changing this. The existing code intentionally
tries to centralize the "ICU is not supported in this build" knowledge
in few places. Your patch tries to make this check early, but in the
process adds more places where ICU support nee
On Sat, Nov 19, 2022 at 4:13 AM Thomas Munro wrote:
> Hi,
>
> Is there a way to find out about new git commits that is more
> efficient and timely than running N git fetches or whatever every
> minute in a cron job? Maybe some kind of long polling where you send
> an HTTP request that says "I th
чт, 17 нояб. 2022 г. в 09:58, Peter Eisentraut
:
>
> On 29.10.22 13:33, Marina Polyakova wrote:
> > 2. initdb/create database report problems with the ICU locale/encoding
> > although they may already report that ICU is not supported in this build:
> >
> > 2.1.
> >
> > $ initdb --locale-provider ic
чт, 17 нояб. 2022 г. в 09:54, Peter Eisentraut
:
>
> On 29.10.22 15:09, Marina Polyakova wrote:
> > On 2022-10-29 14:33, Marina Polyakova wrote:
> >> Hello!
> >>
> >> This is the last proposed patch on this subject [1] moved to a
> >> separate thread for Commitfest..
> >
> > Also added a patch to e
On 18.10.21 14:15, Heikki Linnakangas wrote:
On 05/10/2021 20:24, John Naylor wrote:
I've had a chance to review and test out the v5 patches.
Thanks! I fixed the stray reference to PostgreSQL 14 that Zhihong
mentioned, and pushed.
AFAICT, this thread updated the API of LogicalTapeSetCreate(
On Fri, 18 Nov 2022 at 20:26, Thomas Munro wrote:
>
> On Sat, Nov 19, 2022 at 7:54 AM Simon Riggs
> wrote:
> > I agree. I can't see a reason to keep it anymore.
>
> +Use of promote_trigger_file is deprecated. If you're
>
> I think 'deprecated' usually implies that it still works but you
> sho
On Fri, Nov 18, 2022 at 7:56 AM Amit Kapila wrote:
>
> On Wed, Nov 16, 2022 at 1:50 PM houzj.f...@fujitsu.com
> wrote:
> >
> > On Tuesday, November 15, 2022 7:58 PM houzj.f...@fujitsu.com
> > wrote:
> >
> > I noticed that I didn't add CHECK_FOR_INTERRUPTS while retrying send
> > message.
> > S
On 11/19/22 04:10, Tom Lane wrote:
> Andres Freund writes:
>> On 2022-11-18 15:55:34 -0500, Tom Lane wrote:
>>> We realized today [1] that it's been some time since the buildfarm
>>> had any debug_discard_caches (nee CLOBBER_CACHE_ALWAYS) coverage.
>
>> Do we know when it was covered last? I a
Hi,
On 11/18/22 6:32 PM, Andres Freund wrote:
Hi,
On 2022-11-18 11:09:43 +0100, Drouvot, Bertrand wrote:
Furthermore, the pgstat_fetch_stat_tabentry() can just be a
static inline function.
I think that's just premature optimization for something like this. The
function call overhead on acces
47 matches
Mail list logo
