> On Jul 5, 2016, at 3:18 PM, David Empson wrote:
>
>
>> On 6/07/2016, at 8:55 AM, Ward WIllats wrote:
>>
>>> I have noticed that when I set max_page_count programatically to 16384 and
>>> read it back with the shell I get 1073741823.
>>> If I
> On 6/07/2016, at 8:55 AM, Ward WIllats wrote:
>
>> I have noticed that when I set max_page_count programatically to 16384 and
>> read it back with the shell I get 1073741823.
>> If I set max_page_count with the shell to 16384 and read it back
>> programmatically,
> On 2016/07/05 10:50 PM, R Smith wrote:
> The page size of the DB doesn't actually change until you repack it (unless
> it is new) - I think.
>
> Try the test running "VACUUM;" after setting the page size to repack the DB
> in that page size and so make it stick outside of the current
Actually - this looks more like a big-endian problem...
1073741823 is exactly 4-bytes left shifted from 16384. So you are
setting/reading the high order bytes of a 64-bit field in stead of the
low-order bytes.
On 2016/07/05 10:50 PM, R Smith wrote:
The page size of the DB doesn't actually
> I have noticed that when I set max_page_count programatically to 16384 and
> read it back with the shell I get 1073741823.
> If I set max_page_count with the shell to 16384 and read it back
> programmatically, the program gets back 1073741823.
> Both the program and the shell can round-trip
The page size of the DB doesn't actually change until you repack it
(unless it is new) - I think.
Try the test running "VACUUM;" after setting the page size to repack the
DB in that page size and so make it stick outside of the current connection.
On 2016/07/05 10:43 PM, Ward WIllats wrote:
I have noticed that when I set max_page_count programatically to 16384 and read
it back with the shell I get 1073741823.
If I set max_page_count with the shell to 16384 and read it back
programmatically, the program gets back 1073741823.
Both the program and the shell can round-trip their own
7 matches
Mail list logo