On Sat, Jul 9, 2022 at 2:02 PM Ibrar Ahmed wrote:
> Thanks for looking at that, yes you are right, the attached patch do that now
>
> if test "$PORTNAME" = "solaris"; then
>
>CPPFLAGS="$CPPFLAGS -D_POSIX_PTHREAD_SEMANTICS"
>
> + CPPFLAGS="$CPPFLAGS -D__STDC_WANT_LIB_EXT1__"
>
> fi
Hmm.
On Fri, Jul 1, 2022 at 08:11:36AM -0700, David G. Johnston wrote:
> That said, I still think that the current wording should be tweak with respect
> to row vs. rows (especially if we continue to call it a table):
>
> Current:
> "The SET and WHERE clauses in ON CONFLICT DO UPDATE have access to
On Tue, Jul 5, 2022 at 08:12:09PM -0400, Tom Lane wrote:
> "David G. Johnston" writes:
>
> + A function that's marked as dependent on an extension is dropped when
> the
> + extension is dropped, even if cascade is not specified.
> + dependency checking in restrict mode
On Fri, Jul 8, 2022 at 10:17:11PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Jul 5, 2022 at 08:20:25PM -0400, Tom Lane wrote:
> >> I agree this phrasing needs some work, but "resolved" doesn't seem
> >> helpful, since it's not defined here or nearby. Maybe "The default
> >>
I see, thank you.
Tom Lane 于2022年7月9日周六 03:35写道：
> Jingtang Zhang writes:
> > Recently, when I was developing some function about INSERT ... ON
> CONFLICT,
> > I used test cases in `src/test/regress/sql/insert_conflict.sql` to
> evaluate
> > my function. When I copy the CREATE TABLE from this
Bruce Momjian writes:
> On Tue, Jul 5, 2022 at 08:20:25PM -0400, Tom Lane wrote:
>> I agree this phrasing needs some work, but "resolved" doesn't seem
>> helpful, since it's not defined here or nearby. Maybe "The default
>> database name is the specified (or defaulted) user name." ?
> I am not
Robert Haas writes:
> ... I think there's some
> debate to be had here over what behavior we need to preserve exactly
> vs. what we can and should change.
For sure. For example, people occasionally complain because
user-defined triggers can defeat RI integrity checks. Should we
change that?
On Sat, Jul 9, 2022 at 6:46 AM Tom Lane wrote:
> Ibrar Ahmed writes:
> > While compiling the PostgreSQL I have found that *memset_s function
> > requires a define "*__STDC_WANT_LIB_EXT1__*" *
> > *explicit_bzero.c:* In function ‘*explicit_bzero*’:
> > *explicit_bzero.c:23:9:* *warning:
On Tue, Jul 5, 2022 at 08:20:25PM -0400, Tom Lane wrote:
> "David G. Johnston" writes:
> > In passing, the authentication error examples use the phrase
> > "database user name" in a couple of locations. The word
> > database in both cases is both unusual and unnecessary for
> >
Ibrar Ahmed writes:
> While compiling the PostgreSQL I have found that *memset_s function
> requires a define "*__STDC_WANT_LIB_EXT1__*" *
> *explicit_bzero.c:* In function ‘*explicit_bzero*’:
> *explicit_bzero.c:23:9:* *warning: *implicit declaration of function ‘
> *memset_s*’; did you mean
Hi,
While compiling the PostgreSQL I have found that *memset_s function
requires a define "*__STDC_WANT_LIB_EXT1__*" *
*explicit_bzero.c:* In function ‘*explicit_bzero*’:
*explicit_bzero.c:23:9:* *warning: *implicit declaration of function ‘
*memset_s*’; did you mean ‘*memset*’?
On Fri, Jul 8, 2022 at 09:21:31PM -0400, Bruce Momjian wrote:
> On Wed, Jul 6, 2022 at 10:34:58AM -0700, David G. Johnston wrote:
> > Agreed.
> >
> > Tangentially: It does seem a bit unusual to call the fact that the values
> > both
> > case-sensitive and limited to the length of a system
On Wed, Jul 6, 2022 at 10:34:58AM -0700, David G. Johnston wrote:
> Agreed.
>
> Tangentially: It does seem a bit unusual to call the fact that the values both
> case-sensitive and limited to the length of a system identifier an
> implementation detail. But if anything the length is more of one
On Tue, Jun 21, 2022 at 09:07:42AM -0700, David G. Johnston wrote:
> On Tue, Jun 21, 2022 at 6:49 AM Aleksander Alekseev
> wrote:
>
> Hi David,
>
> > It's basically a glorified cross-reference. I didn't dislike directing
> the reader to the internals section enough to try and
On Tue, Jun 21, 2022 at 09:02:41AM -0700, David G. Johnston wrote:
> On Tue, Jun 21, 2022 at 6:33 AM Aleksander Alekseev
> Maybe it's worth using `array_length(array[] :: int[], 1)` instead.
>
> I think subconsciously the cast looked ugly to me so I probably skipped adding
> it. I do agree
В Сб, 09/07/2022 в 02:32 +0300, Yura Sokolov пишет:
> В Пт, 08/07/2022 в 11:04 -0400, Robert Haas пишет:
> > On Fri, Jul 8, 2022 at 10:11 AM Yura Sokolov
> > wrote:
> > > I see analogy with Bus Stop:
> > > - there is bus stop
> > > - there is a schedule of bus arriving this top
> > > - there are
On 7/1/22 08:08, Jacob Champion wrote:
> It's been July everywhere on Earth for a few hours, so the July
> commitfest is now in progress:
>
> https://commitfest.postgresql.org/38/
One week down, three to go.
I forgot to put the overall status in the last email. We started the
month with the
В Пт, 08/07/2022 в 11:04 -0400, Robert Haas пишет:
> On Fri, Jul 8, 2022 at 10:11 AM Yura Sokolov wrote:
> > I see analogy with Bus Stop:
> > - there is bus stop
> > - there is a schedule of bus arriving this top
> > - there are passengers, who every day travel with this bus
> >
> > Bus
Zhihong Yu writes:
> I was looking at the following comment in createplan.c :
> * For table scans, rather than using the relation targetlist (which is
> * only those Vars actually needed by the query), we prefer to generate
> a
> * tlist containing all Vars in order. This will
On Thu, Jun 30, 2022 at 02:40:50PM +0900, Dong Wook Lee wrote:
> On 22/06/29 03:57오후, Jacob Champion wrote:
> > On 6/18/22 01:55, Dong Wook Lee wrote:
> > > Hi hackers,
> > >
> > > I thought it would be nice to have an configuration example of the
> > > pg_prewarm extension.
> > > Therefore,
On 3/31/22 07:37, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Mar 31, 2022 at 10:11 AM Tom Lane wrote:
>>> ... Would it be feasible or reasonable
>>> to drop reviewers if they've not commented in the thread in X amount
>>> of time?
>
>> In theory, this might cause someone who made a
On Fri, Jul 8, 2022 at 12:48 PM Zhihong Yu wrote:
>
>
> On Fri, Jul 8, 2022 at 12:30 PM Tom Lane wrote:
>
>> Ibrar Ahmed writes:
>> > I give a quick look and I think in case whenever data is extracted from
>> the
>> > heap it shows all the columns. Therefore when columns are extracted from
>>
On Fri, Jul 8, 2022 at 5:02 PM Nathan Bossart wrote:
> I think this is an interesting approach, as it seems to move things closer
> to the end goal (i.e., removing [NO]INHERIT), but it also introduces a
> pretty significant compatibility break. With this change, you cannot keep
> using
On Tue, Jul 5, 2022 at 1:32 AM Andres Freund wrote:
> I just thought an easier way - why don't we introduce a 'catalog_double'
> that's defined to be pg_attribute_aligned(whatever-we-need) on AIX? Then we
> can get rid of the manually enforced alignedness and we don't need to contort
> catalog
On 2022-07-05 Tu 15:04, Andrew Dunstan wrote:
> On 2022-07-05 Tu 14:36, Andres Freund wrote:
>>
I think Andrew's beta 2 comment was more about my other architectural
complains around the json expression eval stuff.
>>> Right. That's being worked on but it's not going to be a mechanical
On Fri, Jul 08, 2022 at 03:56:56PM -0400, Robert Haas wrote:
> For those who may not have read the entire thread, the current patch
> does not actually remove the role-level option as the subject line
> suggests, but rather makes it set the default for future grants as
> suggested by Tom in
>
On 2022-07-08 Fr 16:03, Erik Rijkers wrote:
> Hi,
>
> Attached are a few small changes to the JSON_TABLE section in func.sgml.
>
> The first two changes are simple typos.
>
> Then there was this line:
>
>
> context_item, path_expression [ AS json_path_name ] [ PASSING { value
> AS varname }
I wrote:
> 0003 moves the node-level attributes as discussed.
Meh. Just realized that I forgot to adjust the commentary in nodes.h
about where to put node attributes.
Maybe like
- * Attributes can be attached to a node as a whole (the attribute
- * specification must be at the end of the
Hi,
Attached are a few small changes to the JSON_TABLE section in func.sgml.
The first two changes are simple typos.
Then there was this line:
context_item, path_expression [ AS json_path_name ] [ PASSING { value AS
varname } [, ...]]
those are the parameters to JSON_TABLE() so I
On Tue, Jul 5, 2022 at 8:04 AM Robert Haas wrote:
> On Sun, Jul 3, 2022 at 1:17 PM Nathan Bossart
> wrote:
> > If by "bolder" you mean "mark [NO]INHERIT as deprecated-and-to-be-removed
> > and begin emitting WARNINGs when it and WITH INHERIT DEFAULT are used," I
> > think it's worth
On Fri, Jul 8, 2022 at 12:30 PM Tom Lane wrote:
> Ibrar Ahmed writes:
> > I give a quick look and I think in case whenever data is extracted from
> the
> > heap it shows all the columns. Therefore when columns are extracted from
> > the index only it shows the indexed column only.
>
> This is
Hi,
I tried to apply this patch v5 to current master branch but it complains,
"git apply --check
v5-0001-Add-protections-in-xlog-record-APIs-against-large.patch
error: patch failed: src/include/access/xloginsert.h:43
error: src/include/access/xloginsert.h: patch does not apply"
then I checked
Jingtang Zhang writes:
> Recently, when I was developing some function about INSERT ... ON CONFLICT,
> I used test cases in `src/test/regress/sql/insert_conflict.sql` to evaluate
> my function. When I copy the CREATE TABLE from this case alone, and paste
> it to psql, I got a syntax error. As I
On Fri, Jul 8, 2022 at 12:07:45PM -0400, Bruce Momjian wrote:
> On Fri, Jul 8, 2022 at 11:49:47AM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > Agreed. I don't want to break links into the documentation in final
> > > released versions, so head and PG15 seem wise.
> >
> > I would not
Ibrar Ahmed writes:
> I give a quick look and I think in case whenever data is extracted from the
> heap it shows all the columns. Therefore when columns are extracted from
> the index only it shows the indexed column only.
This is operating as designed, and I don't think that the proposed
patch
On Thu, Jul 7, 2022 at 1:43 PM Alexander Korotkov wrote:
> On Thu, Jul 7, 2022 at 2:16 AM Steve Chavez wrote:
> > Thanks Alexander!
> >
> > wrt to the new patch. I think the following comment is misleading since
> > keyDeleted can be true or false:
> >
> > + /* switch equal_match to false so we
On Fri, Jul 8, 2022 at 10:32 PM Zhihong Yu wrote:
>
>
> On Fri, Jul 8, 2022 at 9:40 AM Zhihong Yu wrote:
>
>> Hi,
>> Here is the query which involves aggregate on a single column:
>>
>>
>> https://dbfiddle.uk/?rdbms=postgres_13=44bfd8f6b6b5aad34d00d449c04c5a96
>>
>> As you can see from
On Thu, Jul 7, 2022 at 2:50 AM Peter Eisentraut
wrote:
> I looked into how you decode the serial number. I have found some code
> elsewhere that passed the result of X509_get_serialNumber() directly to
> ASN1_INTEGER_set(). But I guess a serial number of maximum length 20
> octets wouldn't fit
On Fri, Jul 8, 2022 at 10:47 AM Alvaro Herrera wrote:
> Saving some sort of history would be much more useful, but of course a
> lot more work.
I think that storing a certain amount of history would be very useful,
for lots of reasons. Not just for instrumentation purposes; I envisage
a design
Alvaro Herrera writes:
> While going over this patch, I noticed that I forgot to add support for
> XidList in copyfuncs.c. OK if I push this soon quickly?
Yeah, go ahead, that part of copyfuncs is still going to be manually
maintained, so we need the fix.
What about equalfuncs etc?
On Thu, Jul 7, 2022 at 10:53 PM Greg Stark wrote:
> > - -> Parallel Seq Scan on tenk1 (actual rows=1960
> loops=50)
> > + -> Parallel Seq Scan on tenk1 (actual rows=1960.00
>
> At the not inconsiderable risk of bike-shedding
>
> I'm wondering if printing
On Thu, Jul 7, 2022 at 3:14 PM vignesh C wrote:
> On Thu, Jun 23, 2022 at 2:25 AM Ibrar Ahmed wrote:
> >
> >
> >
> > On Thu, Jun 23, 2022 at 1:04 AM David G. Johnston <
> david.g.johns...@gmail.com> wrote:
> >>
> >> On Wed, Jun 22, 2022 at 12:11 PM Ibrar Ahmed
> wrote:
> >>>
> >>> On Thu, Jun
On Thu, Jul 7, 2022 at 2:41 PM Amit Kapila wrote:
> On Thu, Jun 23, 2022 at 2:25 AM Ibrar Ahmed wrote:
> >
> > On Thu, Jun 23, 2022 at 1:04 AM David G. Johnston <
> david.g.johns...@gmail.com> wrote:
> >>
> >> - WRITE_FLOAT_FIELD(rows, "%.0f");
> >> + WRITE_FLOAT_FIELD(rows, "%.2f");
> >>
> >>
While going over this patch, I noticed that I forgot to add support for
XidList in copyfuncs.c. OK if I push this soon quickly?
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
>From 24185e0421cc1e22f9a78f56d03e4585a142e78e Mon Sep 17 00:00:00 2001
From: Alvaro
On 2022-Jul-04, Ken Kato wrote:
> I think having number of index scans of the last vacuum in
> pg_stat_all_tables can be helpful. This value shows how efficiently vacuums
> have performed and can be an indicator to increase maintenance_work_mem.
Yeah, this would be a good metric to expose, since
On Fri, Jul 8, 2022 at 9:40 AM Zhihong Yu wrote:
> Hi,
> Here is the query which involves aggregate on a single column:
>
>
> https://dbfiddle.uk/?rdbms=postgres_13=44bfd8f6b6b5aad34d00d449c04c5a96
>
> As you can see from `Output:`, there are many columns added which are not
> needed by the
On Fri, Jul 08, 2022 at 01:02:51PM -0400, David Steele wrote:
> I think I wrote this before I'd had enough coffee. "fully persisted to
> storage" can mean many things depending on the storage (Posix, CIFS, S3,
> etc.) so I think this is fine. The basic_archive module is there for people
> who
On Fri, Jul 08, 2022 at 09:39:10PM +0530, Bharath Rupireddy wrote:
> 0001 - there are many places where lstat/stat is being used - don't we
> need to replace all or most of them with get_dirent_type?
It's been a while since I wrote this one, but I believe my intent was to
replace as many
On Fri, Jul 8, 2022 at 11:53 AM Justin Pryzby wrote:
> pg_upgrade drops template1 and postgres before upgrading:
Hmm, but I bet you could fiddle with template0. Indeed what's the
difference between a user fiddling with template0 and me committing a
patch that bumps catversion? If the latter
Hi all, apologies if this is the wrong list to use, but I figured this is a
low-level enough problem that it might be the best to gain some
understanding.
In PGDB 13.4 I have a simple (obscured) table;
CREATE SEQUENCE tbl_id_seq START 1;
CREATE TABLE tbl (
a BIGINT UNIQUE NOT NULL DEFAULT
On 7/8/22 12:54, Nathan Bossart wrote:
On Fri, Jul 08, 2022 at 08:20:09AM -0400, David Steele wrote:
Nathan, I don't see the language about being sure to persist to storage
here?
It's here:
When an archive library encounters a pre-existing file, it may return
true if the WAL
>
> It seems from your results that performance degrades for large
> relations. Did you try to investigate the reasons for the same?
>
I have not tried to investigate the performance degradation for large
relations yet.
Once I'm done with changes for the slot usage, I'll look into this and come
Hi Amit and Dilip,
Thanks for the replies.
> > I had a quick look into the patch and it seems it is using the worker
> > array index instead of relid while forming the slot name
>
Yes, I changed the slot names so they include slot index instead of
relation id.
This was needed because I aimed
On Fri, Jul 08, 2022 at 08:20:09AM -0400, David Steele wrote:
> On 7/7/22 21:56, Kyotaro Horiguchi wrote:
>> Thinking RFC'ish, the meaning of "may" and "must" is significant in
>> this description. On the other hand it uses both "may" and "can" but
>> I thinkthat their difference is not
Hi,
Here is the query which involves aggregate on a single column:
https://dbfiddle.uk/?rdbms=postgres_13=44bfd8f6b6b5aad34d00d449c04c5a96
As you can see from `Output:`, there are many columns added which are not
needed by the query executor.
I wonder if someone has noticed this in the past.
If
On Thu, Jun 30, 2022 at 5:33 PM Peter Eisentraut
wrote:
>
> On 25.04.22 20:39, Stephen Frost wrote:
> > All of which isn't an issue if we don't have an external tool trying to
> > do this and instead have the server doing it as the server knows its
> > internal status, that the archive command
On Fri, Jul 1, 2022 at 2:23 AM Amit Langote wrote:
> So, I hacked together a patch (attached 0001) that invents an "RI
> plan" construct (struct RIPlan) to replace the use of an "SPI plan"
> (struct _SPI_plan).
>
> With that in place, I decided to rebase my previous patch [1] to use
> this new
On Sat, Apr 9, 2022 at 1:49 AM Nathan Bossart wrote:
>
> On Wed, Mar 30, 2022 at 09:21:30AM -0700, Nathan Bossart wrote:
> > Here is an updated patch set.
>
> rebased
Thanks.
0001 - there are many places where lstat/stat is being used - don't we
need to replace all or most of them with
On Fri, Jul 8, 2022 at 11:49:47AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Agreed. I don't want to break links into the documentation in final
> > released versions, so head and PG15 seem wise.
>
> I would not expect this to change the doc URLs for any individual
> catalogs or views
On Thu, Jul 07, 2022 at 03:11:38PM -0400, Robert Haas wrote:
> point: we assume that nothing significant has happened between when
> the cluster was created and when pg_upgrade is run, but we don't check
> it. Either we shouldn't assume it, or we should check it.
>
> So, is such activity ever
Bruce Momjian writes:
> Agreed. I don't want to break links into the documentation in final
> released versions, so head and PG15 seem wise.
I would not expect this to change the doc URLs for any individual
catalogs or views --- if it does, I won't be happy.
regards, tom
On Sat, Jun 25, 2022 at 1:31 AM Cary Huang wrote:
>
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: not tested
> Documentation:not tested
>
>
On 08.07.22 15:52, Tom Lane wrote:
I'll re-read the patch today, but how open are you to putting the
struct attributes at the top? I'm willing to do the legwork.
I agree near the top would be preferable. I think it would even be
feasible to parse the whole thing if pgindent split it across
On Fri, Jul 8, 2022 at 09:21:13AM +1000, Peter Smith wrote:
> > My only question is whether we apply this to head, head & PG 15, or all
> > branches? I think the URLs will change with this adjustment so we might
> > want to do only head & PG 15.
>
> AFAIK the chapter has been structured like
Hi, community.
Recently, when I was developing some function about INSERT ... ON CONFLICT,
I used test cases in `src/test/regress/sql/insert_conflict.sql` to evaluate
my function. When I copy the CREATE TABLE from this case alone, and paste
it to psql, I got a syntax error. As I go through the
On 8/7/2022 05:12, Ian Barwick wrote:
ERROR: bind message supplies 0 parameters, but prepared statement
"pgsql_fdw_prep_178" requires 6
CONTEXT: remote SQL command: INSERT INTO public.foo_part_1(t, v1,
v2, v3, v4, v5) VALUES ($1, $2, $3, $4, $5, $6)
COPY foo, line 88160
On Fri, Jul 8, 2022 at 10:11 AM Yura Sokolov wrote:
> I see analogy with Bus Stop:
> - there is bus stop
> - there is a schedule of bus arriving this top
> - there are passengers, who every day travel with this bus
>
> Bus occasionally comes later... Well, it comes later quite often...
>
> Which
On 2022-07-08 Fr 07:57, Dagfinn Ilmari Mannsåker wrote:
> Erik Rijkers writes:
>
>> Hi,
>>
>> Comparison of 2 values of type jsonb is allowed.
>>
>> Comparison of 2 values of type json gives an error.
>>
>> That seems like an oversight -- or is it deliberate?
> This is because json is just a
On Thu, Jul 7, 2022 at 4:16 PM Bruce Momjian wrote:
> You are right to be concerned since you are spanning number spaces, but
> I think you are fine because the relfilenode in the user-space cannot
> have been used since it already was being used in each database. It is
> true we never had a
В Пт, 08/07/2022 в 09:44 -0400, Robert Haas пишет:
> On Thu, Jul 7, 2022 at 10:39 PM Kyotaro Horiguchi
> wrote:
> > At Thu, 7 Jul 2022 13:58:06 -0500, Justin Pryzby
> > wrote in
> > > I agree that this is a bug, since it can (and did) cause false positives
> > > in a
> > > monitoring system.
>
On 7/8/22 09:09, David Steele wrote:
On 7/8/22 08:22, Julien Rouhaud wrote:
On Fri, Jul 8, 2022 at 7:42 PM David Steele wrote:
On 7/7/22 12:43, Fujii Masao wrote:
Since an exclusive backup method was dropped in v15, in v15 or
later, we
need to create backup_label and tablespace_map files
On 7/8/22 09:10, Christoph Berg wrote:
Re: David Steele
To enable us to do that more easily, how about adding the
pg_backup_label() function that returns backup_label and tablespace_map?
I'm thinking to make this function available just after
pg_backup_start() finishes
I was just
Peter Eisentraut writes:
> On 06.07.22 22:46, Tom Lane wrote:
>> ... There is one nasty problem
>> we need a solution to, which is that pgindent is not at all on board
>> with this idea of attaching node attrs to typedefs.
> I have found that putting the attributes at the end of the struct
>
On Thu, Jul 7, 2022 at 10:39 PM Kyotaro Horiguchi
wrote:
> At Thu, 7 Jul 2022 13:58:06 -0500, Justin Pryzby wrote
> in
> > I agree that this is a bug, since it can (and did) cause false positives in
> > a
> > monitoring system.
>
> I'm not this is undoubtfully a bug but agree about the rest.
Bharath Rupireddy writes:
> On Fri, Jul 8, 2022 at 1:40 AM Tom Lane wrote:
>> It doesn't seem like a great place for a hook, because the list of stuff
>> you could safely do there would be mighty short, possibly the empty set.
> I agree with this. But, all of the areas that v2-0003 touched for
Re: David Steele
> > To enable us to do that more easily, how about adding the
> > pg_backup_label() function that returns backup_label and tablespace_map?
> > I'm thinking to make this function available just after
> > pg_backup_start() finishes
I was just wondering: Why is "labelfile" only
On 7/8/22 08:22, Julien Rouhaud wrote:
On Fri, Jul 8, 2022 at 7:42 PM David Steele wrote:
On 7/7/22 12:43, Fujii Masao wrote:
Since an exclusive backup method was dropped in v15, in v15 or later, we
need to create backup_label and tablespace_map files from the result of
pg_backup_stop()
On Thu, Jul 7, 2022 at 10:58 AM Fujii Masao wrote:
> But if many think that it's worth adding the test, I will give a try. But
> even in that case, I think it's better to commit the proposed patch at first
> to fix the bug, and then to write the patch adding the test.
I don't think that we
On Fri, Jul 8, 2022 at 1:40 AM Tom Lane wrote:
>
> Joe Conway writes:
> > It isn't clear to me if having a hook in the timeout handler is a
> > nonstarter -- perhaps a comment with suitable warning for prospective
> > extension authors is enough? Anyone else want to weigh in on this issue
> >
On Fri, Jul 8, 2022 at 7:42 PM David Steele wrote:
>
> On 7/7/22 12:43, Fujii Masao wrote:
>
> > Since an exclusive backup method was dropped in v15, in v15 or later, we
> > need to create backup_label and tablespace_map files from the result of
> > pg_backup_stop() when taking a base backup
On 7/7/22 21:56, Kyotaro Horiguchi wrote:
At Thu, 7 Jul 2022 15:07:16 -0700, Nathan Bossart
wrote in
Here's an updated patch.
Thinking RFC'ish, the meaning of "may" and "must" is significant in
this description. On the other hand it uses both "may" and "can" but
I thinkthat their
On 7/8/22 07:53, Bharath Rupireddy wrote:
On Fri, Jul 8, 2022 at 5:12 PM David Steele wrote:
To enable us to do that more easily, how about adding the
pg_backup_label() function that returns backup_label and tablespace_map?
I'm thinking to make this function available just after
Erik Rijkers writes:
> Hi,
>
> Comparison of 2 values of type jsonb is allowed.
>
> Comparison of 2 values of type json gives an error.
>
> That seems like an oversight -- or is it deliberate?
This is because json is just a textual representation, and different
JSON strings can be semantically
On Fri, Jul 8, 2022 at 5:12 PM David Steele wrote:
>
> > To enable us to do that more easily, how about adding the
> > pg_backup_label() function that returns backup_label and tablespace_map?
> > I'm thinking to make this function available just after
> > pg_backup_start() finishes
>
> This makes
On 7/7/22 12:43, Fujii Masao wrote:
Since an exclusive backup method was dropped in v15, in v15 or later, we
need to create backup_label and tablespace_map files from the result of
pg_backup_stop() when taking a base backup using low level backup API.
One issue when doing this is that; there
On Fri, Jul 8, 2022 at 5:59 PM Amit Kapila wrote:
>
> On Fri, Jul 8, 2022 at 12:46 PM Masahiko Sawada wrote:
> >
> > On Fri, Jul 8, 2022 at 3:27 PM Amit Kapila wrote:
> > >
> >
> > > 1.
> > > In ReorderBufferGetCatalogChangesXacts(), isn't it better to use the
> > > list length of
On Tue, Jul 5, 2022 at 9:33 PM vignesh C wrote:
>
> Since the existing test is already handling the verification of this
> scenario, I felt no need to add the test. Updated v29 patch removes
> the 0001 patch which had the test case.
>
I am not able to apply 0001.
patching file
On Thu, Mar 03, 2022 at 10:21:05AM +0100, Jille Timmermans wrote:
> I'm using https://pkg.go.dev/github.com/jackc/pgx/v4#Conn.CopyFrom, which
> uses the COPY FROM protocol but doesn't actually have to originate from a
> file.
It is Friday here, so I would easily miss something.. It is possible
Hi huyajun,
Thank you for your comments!
On Wed, 29 Jun 2022 17:56:39 +0800
huyajun wrote:
> Hi, Nagata-san
> I read your patch with v27 version and has some new comments,I want to
> discuss with you.
>
> 1. How about use DEPENDENCY_INTERNAL instead of DEPENDENCY_AUTO
> when record
On Fri, Jul 8, 2022 at 3:31 PM Bharath Rupireddy
wrote:
>
> On Thu, Jul 7, 2022 at 10:14 PM Fujii Masao
> wrote:
> >
> > Hi,
> >
> > Since an exclusive backup method was dropped in v15, in v15 or later, we
> > need to create backup_label and tablespace_map files from the result of
> >
On Thu, Jul 7, 2022 at 10:14 PM Fujii Masao wrote:
>
> Hi,
>
> Since an exclusive backup method was dropped in v15, in v15 or later, we need
> to create backup_label and tablespace_map files from the result of
> pg_backup_stop() when taking a base backup using low level backup API. One
> issue
On Fri, Jul 8, 2022 at 12:46 PM Masahiko Sawada wrote:
>
> On Fri, Jul 8, 2022 at 3:27 PM Amit Kapila wrote:
> >
>
> > 1.
> > In ReorderBufferGetCatalogChangesXacts(), isn't it better to use the
> > list length of 'catchange_txns' to allocate xids array? If we can do
> > so, then we will save
Hello,
Reading the thread, I think the feature has value: it would basically transfer
control of the sequence cache to the client application.
However, I don't think that returning only the last value is a sensible thing
to do. The client will need to know the details of the sequence to do
2022年7月8日(金) 17:10 Yugo NAGATA :
>
> On Fri, 8 Jul 2022 16:50:10 +0900
> Ian Lawrence Barwick wrote:
>
> > 2022年7月8日(金) 14:06 Fujii Masao :
> > > On 2022/07/08 11:19, Yugo NAGATA wrote:
> > > >> You added "foreign tables" for BEFORE statement-level trigger as the
> > > >> above, but ISTM that
On Fri, 8 Jul 2022 16:50:10 +0900
Ian Lawrence Barwick wrote:
> 2022年7月8日(金) 14:06 Fujii Masao :
> > On 2022/07/08 11:19, Yugo NAGATA wrote:
> > >> You added "foreign tables" for BEFORE statement-level trigger as the
> > >> above, but ISTM that you also needs to do that for AFTER
I've pushed 0001 (although the email seems to have been swallowed
again), and pending additional comments on 0002 and 0003 I'll squash
and push those next week. 0004 needs some thought on integrating with
symbols we discover during configure.
--
John Naylor
EDB: http://www.enterprisedb.com
On Fri, Jul 8, 2022 at 11:07 AM Yugo NAGATA wrote:
> On Fri, 08 Jul 2022 09:44:10 +0900 (JST)
> Kyotaro Horiguchi wrote:
> > At Fri, 8 Jul 2022 01:06:18 +0900, Fujii Masao
> > wrote in
> > > On 2022/07/08 0:33, Tom Lane wrote:
> > > >> On 2022/06/30 10:48, Yugo NAGATA wrote:
> > > >>> When a
2022年7月8日(金) 14:06 Fujii Masao :
> On 2022/07/08 11:19, Yugo NAGATA wrote:
> >> You added "foreign tables" for BEFORE statement-level trigger as the
> >> above, but ISTM that you also needs to do that for AFTER statement-level
> >> trigger. No?
> >
> > Oops, I forgot it. I attached the updated
On Fri, Jul 8, 2022 at 3:27 PM Amit Kapila wrote:
>
> On Fri, Jul 8, 2022 at 6:45 AM Masahiko Sawada wrote:
> >
> > On Thu, Jul 7, 2022 at 3:40 PM Amit Kapila wrote:
> > >
> > > On Thu, Jul 7, 2022 at 8:21 AM Masahiko Sawada
> > > wrote:
> >
> > I've attached the new version patch that
Hi,
On Thu, Jun 02, 2022 at 10:08:15AM +0900, Michael Paquier wrote:
> On Thu, May 26, 2022 at 03:26:57PM +0800, Julien Rouhaud wrote:
>
> > After a bit more digging, I think that this comes from the fact that
> > there's no
> > "official" name for this file. Even the documentation just says
1 - 100 of 105 matches
Mail list logo
