On Thu, Mar 05, 2020 at 08:20:23PM -0500, David Steele wrote:
> Couldn't we use pageinspect?
Oh, indeed. I forgot that we already have this function. The tests
of page.sql don't care about the page size either, so it would be
enough to add a couple of calls with some hardcoded bytea input.
--
Mi
On 3/5/20 8:10 PM, Michael Paquier wrote:
On Thu, Mar 05, 2020 at 07:58:50PM -0500, David Steele wrote:
Yeah, keeping BLKSZ a constant is pretty important for performance. That's
one of the main reasons that we only support the default.
Doing something is not complicated, now how would people
On Thu, Mar 05, 2020 at 07:58:50PM -0500, David Steele wrote:
> Yeah, keeping BLKSZ a constant is pretty important for performance. That's
> one of the main reasons that we only support the default.
Doing something is not complicated, now how would people like to do
it? Here are the options I can
On 3/5/20 7:48 PM, Michael Paquier wrote:
On Thu, Mar 05, 2020 at 04:14:20PM -0800, Magnus Hagander wrote:
That's a pretty dangerous mistake, and moreso because we don't have a
test around it. We should really find a way to add such a test -- just
a hardcoded page calculation that should always
On Thu, Mar 05, 2020 at 04:14:20PM -0800, Magnus Hagander wrote:
> That's a pretty dangerous mistake, and moreso because we don't have a
> test around it. We should really find a way to add such a test -- just
> a hardcoded page calculation that should always return the same value
> perhaps?
Yes..
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Thu, Mar 05, 2020 at 07:32:59PM -0500, David Steele wrote:
> > FWIW, we use static values in our unit tests (which are written in C), then
> > test against packaged versions of Postgres for integration tests.
> >
> > When I saw the co
On Thu, Mar 05, 2020 at 07:32:59PM -0500, David Steele wrote:
> FWIW, we use static values in our unit tests (which are written in C), then
> test against packaged versions of Postgres for integration tests.
>
> When I saw the commit I pulled it in so I could remove instructions for the
> manual s
On 3/5/20 6:30 PM, Michael Paquier wrote:
On Thu, Mar 05, 2020 at 12:51:50PM -0500, David Steele wrote:
Bit of a bummer that this passed make check-world, but the pgBackRest tests
definitely did not like it.
Is that because you have a copy of this routine in your code?
Yes, we pull this fil
On 3/5/20 7:14 PM, Magnus Hagander wrote:
On Thu, Mar 5, 2020 at 3:30 PM Michael Paquier wrote:
On Thu, Mar 05, 2020 at 12:51:50PM -0500, David Steele wrote:
Looks like you changed 65535 -> 65536 before commit. I checked the original
patch and it has 65535.
That's my fault, thanks. I have
On Thu, Mar 5, 2020 at 3:30 PM Michael Paquier wrote:
>
> On Thu, Mar 05, 2020 at 12:51:50PM -0500, David Steele wrote:
> > Looks like you changed 65535 -> 65536 before commit. I checked the original
> > patch and it has 65535.
>
> That's my fault, thanks. I have been playing with the surroundin
On Thu, Mar 05, 2020 at 12:51:50PM -0500, David Steele wrote:
> Looks like you changed 65535 -> 65536 before commit. I checked the original
> patch and it has 65535.
That's my fault, thanks. I have been playing with the surroundings
while looking at your patch.
> Bit of a bummer that this passe
Fix page-level checksum calculation in checksum_impl.h
Issue introduced by me, as of 0065174.
Reported-by: David Steele
Discussion:
https://postgr.es/m/1cf30561-7dad-dc6e-9fc3-5c456948c...@pgmasters.net
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/addd034ae1795
Remove ancient support for upgrading pre-7.3 foreign key constraints.
Before 7.3, foreign key constraints had no explicit catalog
representation, so that what pg_dump produced for them was (usually)
a set of three CREATE CONSTRAINT TRIGGER commands. Commit a2899ebdc
and some follow-on fixes added
Remove the "opaque" pseudo-type and associated compatibility hacks.
A long time ago, it was necessary to declare datatype I/O functions,
triggers, and language handler support functions in a very type-unsafe
way involving a single pseudo-type "opaque". We got rid of those
conventions in 7.3, but
Remove ancient hacks to ignore certain opclass names in CREATE INDEX.
Twenty years ago, we removed certain operator classes in favor of
letting indexes over their data types be built with some other
binary-compatible, more standard opclass. As a hack to allow existing
index definitions to be dump
On Mon, Mar 2, 2020 at 3:36 PM Andrew Dunstan
wrote:
>
>
> On 3/2/20 2:05 AM, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> On Sat, Feb 29, 2020 at 10:41 AM Tom Lane wrote:
> >>> Did the buildfarm adjustments get made? (I'm assuming Andrew knows)
> >> It's in Release 11 of the client and is m
Hi Michael,
On 3/5/20 12:13 AM, Michael Paquier wrote:
Avoid -Wconversion warnings when using checksum_impl.h
This does not matter much when compiling Postgres proper as many
warnings exist when enabling this compilation flag, but it can be
annoying for external modules willing to use both.
L
Remove RangeIOData->typiofunc
We used to carry the I/O function OID in RangeIOData, but it's not used
for anything. Since the struct is not exposed to the world anyway, we
can simplify it a bit. Also, rename the FmgrInfo member to match
the accompanying 'typioparam' and put them in a more sensib
18 matches
Mail list logo
