Allow synced slots to have their inactive_since.
This commit does two things:
1) Maintains inactive_since for sync slots whenever the slot is released
just like any other regular slot.
2) Ensures the value is set to the current timestamp during the promotion
of standby to help correctly
Amit Langote writes:
> On Fri, Apr 5, 2024 at 11:56 AM Tom Lane wrote:
>> Consistency with what? There are plenty of other gram.y productions
>> that throw FEATURE_NOT_SUPPORTED conditionally.
> Ah, yes, I see. I thought maybe not when I read "unconventional use
> of" in your first email.
On Fri, Apr 5, 2024 at 11:56 AM Tom Lane wrote:
> Amit Langote writes:
> > Wonder if, for consistency, I should change the coding so that the
> > FEATURE_NOT_SUPPORTED is reported in transformJsonTable() or
> > something?
>
> Consistency with what? There are plenty of other gram.y productions
>
Amit Langote writes:
> Wonder if, for consistency, I should change the coding so that the
> FEATURE_NOT_SUPPORTED is reported in transformJsonTable() or
> something?
Consistency with what? There are plenty of other gram.y productions
that throw FEATURE_NOT_SUPPORTED conditionally.
On Fri, Apr 5, 2024 at 1:55 AM Tom Lane wrote:
> I wrote:
> > We need to either nuke that ecpg warning entirely, or find a more
> > robust way of detecting whether the gram.y complaint is conditional.
> > I'll put a brown paper bag on my head before suggesting that maybe
> > we could pay
Add "ABI_compatibility" regions to wait_event_names.txt
The current design behind the automatic generation of the C code and
documentation related to wait events introduced in fa88928470b5 does not
offer a way to attach new wait events without breaking ABI
compatibility, as all the events are
Fix test failures when language environment is not UTF-8.
For tests that depend on UTF-8 encoding, force LC_COLLATE=C and
LC_CTYPE=C to avoid an encoding mismatch.
Reported-by: Thomas Munro
Discussion:
https://postgr.es/m/CA+hUKGK-ZqV1njkG_=xcCqXh2fcMkz85FTMnhS2opm4ZerH=x...@mail.gmail.com
Remove reachable call to pg_unreachable().
The loop just before this uses break, not return, so this line
is reachable. Commit cafe1056558fe07cdc52b95205588fcd80870362
introduced this issue.
Jelte Fennema-Nio, reviewed by Tristan Partin
Discussion:
Fix old, misleading comment for PGRES_POLLING_ACTIVE.
The comment implies that we can eventually remove this, but per
discussion, we actually don't want to do that ever, in order to
maintain compatibility.
Jelte Fennema-Nio, reviewed by Tristan Partin
Discussion:
Fix ecpg's mechanism for detecting unsupported cases in the grammar.
ecpg wants to emit a warning if it parses a SQL construct that the
backend can parse but will immediately throw a FEATURE_NOT_SUPPORTED
error for. The way it was testing for this was to see if the string
Fix ecpg's mechanism for detecting unsupported cases in the grammar.
ecpg wants to emit a warning if it parses a SQL construct that the
backend can parse but will immediately throw a FEATURE_NOT_SUPPORTED
error for. The way it was testing for this was to see if the string
Fix ecpg's mechanism for detecting unsupported cases in the grammar.
ecpg wants to emit a warning if it parses a SQL construct that the
backend can parse but will immediately throw a FEATURE_NOT_SUPPORTED
error for. The way it was testing for this was to see if the string
Fix ecpg's mechanism for detecting unsupported cases in the grammar.
ecpg wants to emit a warning if it parses a SQL construct that the
backend can parse but will immediately throw a FEATURE_NOT_SUPPORTED
error for. The way it was testing for this was to see if the string
Fix ecpg's mechanism for detecting unsupported cases in the grammar.
ecpg wants to emit a warning if it parses a SQL construct that the
backend can parse but will immediately throw a FEATURE_NOT_SUPPORTED
error for. The way it was testing for this was to see if the string
Fix ecpg's mechanism for detecting unsupported cases in the grammar.
ecpg wants to emit a warning if it parses a SQL construct that the
backend can parse but will immediately throw a FEATURE_NOT_SUPPORTED
error for. The way it was testing for this was to see if the string
Further cleanup for recent JSON-related commits.
The link commands in test_json_parser/Makefile were a long way
shy of a load, as evidenced by buildfarm failures. Model them
on pgxs.mk's PROGRAM rule. (Probably we should have put these
two test programs in different subdirectories so we could
Further cleanup for recent JSON-related commits.
Add overlooked .gitignore entries.
Fix test_json_parser/Makefile to use the pgxs.mk clean rule
instead of fighting it. Suppresses a warning from make,
at least for me.
Branch
--
master
Details
---
I wrote:
> We need to either nuke that ecpg warning entirely, or find a more
> robust way of detecting whether the gram.y complaint is conditional.
> I'll put a brown paper bag on my head before suggesting that maybe
> we could pay attention to how far the errcode is indented. Perhaps
> a
Tidy up after incremental JSON parser patch
Remove junk left over from non-vpath builds.
Try to remedy gettext error on some platforms.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/88620824c2a62376e224c4b595b9fe69fb858978
Modified Files
--
I wrote:
> Looking at parse.pl, I guess it's probably triggered by some
> unconventional use of ERRCODE_FEATURE_NOT_SUPPORTED in your
> gram.y changes.
Oh, no, it's parse.pl that is at fault. It's doing this:
if (/ERRCODE_FEATURE_NOT_SUPPORTED/)
{
Fix warnings re typedef redefinition in ea7b4e9a2a and 3311ea86ed
Per gripe from Tom Lane and the buildfarm
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/1b00fe30a67774e55c5fc776096a3c96f1a147d2
Modified Files
--
src/common/jsonapi.c| 12
Andrew Dunstan writes:
> On 2024-04-04 Th 09:20, Amit Langote wrote:
>> I don't get that WARNING here, but I remember seeing it at one point,
>> which I am supposed to have fixed.
>>
>> Can you please share more details about where you're seeing it?
> It's with a meson build:
I see it with
On 2024-04-04 Th 09:20, Amit Langote wrote:
Hi Andrew,
On Thu, Apr 4, 2024 at 10:06 PM Andrew Dunstan wrote:
On 2024-04-04 Th 07:21, Amit Langote wrote:
Add basic JSON_TABLE() functionality
Excellent!
But I am getting this:
../../../src/interfaces/ecpg/test/sql/sqljson_jsontable.pgc:23:
Hi Andrew,
On Thu, Apr 4, 2024 at 10:06 PM Andrew Dunstan wrote:
> On 2024-04-04 Th 07:21, Amit Langote wrote:
>
> Add basic JSON_TABLE() functionality
>
>
> Excellent!
>
> But I am getting this:
>
> ../../../src/interfaces/ecpg/test/sql/sqljson_jsontable.pgc:23: WARNING:
> unsupported feature
Hi Erik
On Thu, Apr 4, 2024 at 9:30 PM Erik Rijkers wrote:
> Op 4/4/24 om 13:21 schreef Amit Langote:
> > Add basic JSON_TABLE() functionality
> >
>
> Great that it's now committed. Congrats!
>
>
> There is one 'uninitialized' muttering during compile (gcc 13.2.0):
>
> In function
Add missing initialization in transformJsonFuncExpr()
de3600452b added some code for the new JSON_TABLE_OP to that function
but missed to initialize the default_format variable.
Reported-by: Erik Rijkers
Discussion: https://postgr.es/m/254b2fa2-2f6b-a30a-20ee-21f8a2c12...@xs4all.nl
Branch
On 2024-04-04 Th 07:21, Amit Langote wrote:
Add basic JSON_TABLE() functionality
Excellent!
But I am getting this:
../../../src/interfaces/ecpg/test/sql/sqljson_jsontable.pgc:23: WARNING:
unsupported feature will be passed to server
Is that intended?
cheers
andrew
--
Andrew Dunstan
Op 4/4/24 om 13:21 schreef Amit Langote:
Add basic JSON_TABLE() functionality
Great that it's now committed. Congrats!
There is one 'uninitialized' muttering during compile (gcc 13.2.0):
In function ‘transformJsonFuncExpr’,
inlined from ‘transformExprRecurse’ at parse_expr.c:373:13:
Fix typo introduced in 6185c9737
Reported-by: Jian He
Discussion:
https://postgr.es/m/cacjufxghiu0p0usjh5hnr0_byzn4tq1fc3ekatrqgjeku6w...@mail.gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/2f6e78b0619a0ee2ca170e0073659581847ee73d
Modified Files
Add basic JSON_TABLE() functionality
JSON_TABLE() allows JSON data to be converted into a relational view
and thus used, for example, in a FROM clause, like other tabular
data. Data to show in the view is selected from a source JSON object
using a JSON path expression to get a sequence of JSON
pg_upgrade: Fix typo in message
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/a9d6c3868451a494641b498a15f9ee1c151949a7
Modified Files
--
src/bin/pg_upgrade/check.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Use incremental parsing of backup manifests.
This changes the three callers to json_parse_manifest() to use
json_parse_manifest_incremental_chunk() if appropriate. In the case of
the backend caller, since we don't know the size of the manifest in
advance we always call the incremental parser.
Add support for incrementally parsing backup manifests
This adds the infrastructure for using the new non-recursive JSON parser
in processing manifests. It's important that callers make sure that the
last piece of json handed to the incremental manifest parser contains
the entire last few lines
Introduce a non-recursive JSON parser
This parser uses an explicit prediction stack, unlike the present
recursive descent parser where the parser state is represented on the
call stack. This difference makes the new parser suitable for use in
incremental parsing of huge JSON documents that cannot
Silence meson warning
Commit 619bc23a1a introduced
WARNING: Project targets '>=0.54' but uses feature introduced in '0.55.0':
Passing executable/found program object to script parameter of add_dist_script
Work around that by wrapping the offending line in a meson version check.
Author:
postgres_fdw: Remove useless ternary expression.
There is no case where we would call pgfdw_exec_cleanup_query or
pgfdw_exec_cleanup_query_{begin,end} with a NULL query string, so this
expression is pointless; remove it and instead add to the latter
functions an assertion ensuring the given query
Fix bogus coding in ExecAppendAsyncEventWait().
No configured-by-FDW events would result in "return" directly out of a
PG_TRY block, making the exception stack dangling. Repair.
Oversight in commit 501cfd07d; back-patch to v14, like that commit, but
as we do not have this issue in HEAD (cf.
Fix bogus coding in ExecAppendAsyncEventWait().
No configured-by-FDW events would result in "return" directly out of a
PG_TRY block, making the exception stack dangling. Repair.
Oversight in commit 501cfd07d; back-patch to v14, like that commit, but
as we do not have this issue in HEAD (cf.
Fix bogus coding in ExecAppendAsyncEventWait().
No configured-by-FDW events would result in "return" directly out of a
PG_TRY block, making the exception stack dangling. Repair.
Oversight in commit 501cfd07d; back-patch to v14, like that commit, but
as we do not have this issue in HEAD (cf.
Secondary refactor of heap scanning functions
Similar to 44086b097, refactor heap scanning functions to be more
suitable for the read stream API.
Author: Melanie Plageman
Discussion:
https://postgr.es/m/CAAKRu_YtXJiYKQvb5JsA2SkwrsizYLugs4sSOZh3EAjKUg=g...@mail.gmail.com
Branch
--
master
40 matches
Mail list logo
