I saw some strange results:
postgres=# select '1.1'::numeric = '1.1'::float8;
?column?
--
t
(1 row)
postgres=# select '1.1'::numeric = '1.1'::float4;
?column?
--
f
(1 row)
When I looked into it, I saw that the numeric is being cast to a float8,
making the first statement tr
On Thu, Jul 31, 2014 at 1:56 PM, desmodemone wrote:
>
> Hi Amit, thank you for your comments .
> However , about drawbacks:
> a) It's not clear to me why the method needs checksum enable, I mean, if
the bgwriter or another process flushes a dirty buffer, it's only have to
signal in the map that th
On Thu, Jul 31, 2014 at 1:36 PM, Abhijit Menon-Sen
wrote:
> At 2014-07-30 13:27:24 -0400, robertmh...@gmail.com wrote:
> > Is anybody working on closing out the "in progress" CommitFest?
>
> Yes. I was away for a few days, but I'm back at work now and will move
> the patches.
Okay. It makes sens
"Baker, Keith [OCDUS Non-J&J]" writes:
> Since ensuring there are not orphaned back-end processes is vital, could we
> add a check for getppid() == 1 ?
No. Or yeah, we could, but that patch would add no security worth
mentioning. For example, someone could launch a query that runs for
many min
I will on vacation until August 11, I look forward to any progress you are able
to make.
Since ensuring there are not orphaned back-end processes is vital, could we add
a check for getppid() == 1 ?
Patch below seemed to work on QNX (first client command after a kill -9 of
postmaster resulted in
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Bruce Momjian (br...@momjian.us) wrote:
> >> Actually, thinking more, Stephen Frost mentioned that the auditing
> >> system has to modify database _state_, and dumping/restoring the state
> >> of an extension might be tricky.
>
Marti Raudsepp wrote:
> The real point I was trying to convey (in my previous email) is
> that these declarations should be part of the trigger *function*
> not the function-to-table relationship. CREATE TRIGGER shouldn't
> be in the business of declaring new local variables for the
> trigger fun
On Thu, Jul 31, 2014 at 5:26 AM, desmodemone wrote:
> b) yes the backends need to update the map, but it's in memory, and as I
> show, could be very small if we you chunk of blocks.If we not compress the
> map, I not think could be a bottleneck.
If it's in memory, it's not crash-safe. For somethi
On Thu, Jul 31, 2014 at 12:52 PM, Robert Haas wrote:
>> Maybe "abbreviated", "abridged", "minified"?
>
> Yeah, something like that would work for me. I like abbreviated; that
> seems very descriptive.
Abbreviated it is.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hacker
On Thu, Jul 31, 2014 at 8:14 PM, Marti Raudsepp wrote:
> On Thu, Jul 31, 2014 at 9:41 PM, Robert Haas wrote:
>> I certainly like that better than poor-man; but proxy, to me, fails to
>> convey inexactness.
>
> Maybe "abbreviated", "abridged", "minified"?
Surrogate?
Let the bike shedding begin!
On Thu, Jul 31, 2014 at 3:14 PM, Marti Raudsepp wrote:
> On Thu, Jul 31, 2014 at 9:41 PM, Robert Haas wrote:
>> I certainly like that better than poor-man; but proxy, to me, fails to
>> convey inexactness.
>
> Maybe "abbreviated", "abridged", "minified"?
Yeah, something like that would work for
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jul 30, 2014 at 2:49 PM, Alvaro Herrera
> wrote:
> > I think you're making too much of this upgrade issue.
>
> +1.
Alright- if everyone feels that there won't be any migration issues then
I'll drop that concern.
Thanks,
On Thu, Jul 31, 2014 at 9:41 PM, Robert Haas wrote:
> I certainly like that better than poor-man; but proxy, to me, fails to
> convey inexactness.
Maybe "abbreviated", "abridged", "minified"?
Regards,
Marti
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Thu, Jul 31, 2014 at 11:41 AM, Robert Haas wrote:
> I certainly like that better than poor-man; but proxy, to me, fails to
> convey inexactness. Perhaps we can work that idea in somehow. Or
> maybe "pre"-something, to indicate that we do this before comparing
> the regular key, in the hopes o
On Wed, Jul 30, 2014 at 2:49 PM, Alvaro Herrera
wrote:
> I think you're making too much of this upgrade issue.
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Thu, Jul 31, 2014 at 2:00 AM, Amit Kapila wrote:
> On Wed, Jul 30, 2014 at 11:32 PM, Robert Haas wrote:
>> IMV, the way to eventually make this efficient is to have a background
>> process that reads the WAL and figures out which data blocks have been
>> modified, and tracks that someplace.
>
On Wed, Jul 30, 2014 at 7:17 PM, Peter Geoghegan wrote:
> On Wed, Jul 30, 2014 at 3:04 PM, Peter Geoghegan wrote:
>> I don't have a problem with changing the name. But the name that you
>> propose is all about text. This patch is intended to add an extensible
>> infrastructure (a new part of sort
On Wed, Jul 30, 2014 at 11:02 AM, Tom Lane wrote:
> So it seems like we could possibly go this route, assuming we can think
> of a variant of your proposal that's race-condition-free. A disadvantage
> compared to a true file lock is that it would not protect against people
> trying to start postm
On Thu, Jul 31, 2014 at 11:07 AM, Heikki Linnakangas
wrote:
> Ok, thanks. I did post to pgsql-hackers first, see
> http://www.postgresql.org/message-id/53da0ecf.4040...@vmware.com. Admittedly
> I didn't leave much time for discussion between the post and commit; that
> was because I felt quite cer
On Thu, Jul 31, 2014 at 10:01 AM, Fabien COELHO wrote:
>> One of the concerns that I have about the proposal of simply slapping a
>> gaussian or exponential modifier onto \setrandom aid 1 :naccounts is that,
>> while it will allow you to make part of the relation hot and another part of
>> the rel
On 07/31/2014 05:58 PM, Simon Riggs wrote:
On 31 July 2014 15:48, Heikki Linnakangas wrote:
On 07/31/2014 05:19 PM, Simon Riggs wrote:
On 31 July 2014 14:59, Heikki Linnakangas
wrote:
Move log_newpage and log_newpage_buffer to xlog.c.
Got a feeling this wasn't properly discussed because
On 31 July 2014 15:48, Heikki Linnakangas wrote:
> On 07/31/2014 05:19 PM, Simon Riggs wrote:
>>
>> On 31 July 2014 14:59, Heikki Linnakangas
>> wrote:
>>
>>> Move log_newpage and log_newpage_buffer to xlog.c.
>>
>>
>> Got a feeling this wasn't properly discussed because its unlikely
>> anybody w
On 07/31/2014 05:19 PM, Simon Riggs wrote:
On 31 July 2014 14:59, Heikki Linnakangas wrote:
Move log_newpage and log_newpage_buffer to xlog.c.
Got a feeling this wasn't properly discussed because its unlikely
anybody would agree with adding more stuff to xlog.c
Well, they certainly don't b
Hello Robert,
[...]
One of the concerns that I have about the proposal of simply slapping a
gaussian or exponential modifier onto \setrandom aid 1 :naccounts is
that, while it will allow you to make part of the relation hot and
another part of the relation cold, you really can't get any more
On Thu, Jul 31, 2014 at 11:30:52AM +0530, Amit Kapila wrote:
> On Wed, Jul 30, 2014 at 11:32 PM, Robert Haas wrote:
> >
> > IMV, the way to eventually make this efficient is to have a background
> > process that reads the WAL and figures out which data blocks have been
> > modified, and tracks tha
On Wed, Jul 30, 2014 at 2:59 PM, Daniele Varrazzo
wrote:
> Please find attached a small tweak to a couple of strings found while
> updating translations. The %d version is already used elsewhere in the
> same file.
Probably not a bad idea, but aren't these strings pretty awful anyway?
At a minim
On Wed, Jul 30, 2014 at 9:00 PM, Mitsumasa KONDO
wrote:
> Hmm... It doesn't have harm for pgbench source code. And, in general,
> checking script is useful for avoiding bug.
Not if nobody runs it, or if people run it but don't know what the
output should look like. I think anyone who knows enoug
On Wed, Jul 30, 2014 at 4:18 PM, Fabien COELHO wrote:
>> nor am I in favor of patch B.
>
> Yep. Would providing these as additional contrib files be more acceptable?
> Something like "tpc-b-gauss.sql"... Otherwise there is no example available
> to show the feature.
To be honest, it just feels li
log_newpage is used by many index types, as well as for heaps. But for
historical reasons, it's always been in heapam.c, as part of the Heap
resource manager.
We now have a new record type that just contains a full page image,
XLOG_FPI, used to log hint bit updates when checksums are enabled.
2014-07-31 8:26 GMT+02:00 Amit Kapila :
> On Wed, Jul 30, 2014 at 7:00 PM, desmodemone
> wrote:
> > Hello,
> > I think it's very useful an incremental/differential backup
> method, by the way
> > the method has two drawbacks:
> > 1) In a database normally, even if the percent of modi
At 2014-07-30 13:27:24 -0400, robertmh...@gmail.com wrote:
>
> Hi,
>
> Is anybody working on closing out the "in progress" CommitFest?
Yes. I was away for a few days, but I'm back at work now and will move
the patches.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
On Thu, Jul 31, 2014 at 4:07 PM, Simon Riggs wrote:
> Yeh, it looks like you need to do CheckBackupBlock() exactly as many
> times as you do RestoreBackupBlock(), with the sequence of actions
> being RestoreBackupBlock(), apply WAL then CheckBackupBlock(). That
> will work without much code churn,
On 31 July 2014 07:45, Michael Paquier wrote:
>> So I don't see the need for two full page images.
> By doing so you definitely need an additional mode for full-page
> writes: one certifying that process does not apply this FPW because it
> wants to compare it to current page after applying the
On Thu, Jul 31, 2014 at 3:45 PM, Amit Kapila wrote:
> In past, I have seen that we try to make sure that each patch
> gets atleast one review in CF, so do you think we should try
> that this time as well (I think patches which don't have even one
> review are not too many). To be honest, I don't
34 matches
Mail list logo
