On Friday, December 3, 2021 3:12 PM vignesh C wrote:
> Thanks for the updated patch.
> Currently we are storing the commit count, error_count and abort_count for
> each table of the table sync operation. If we have thousands of tables, we
> will
> be storing the information for each of the tables
On 12/3/21 23:21, Thomas Munro wrote:
>
> Next problem: The below is clearly not the right way to find the
> pg_regress binary and bindir, and doesn't work on Windows or VPATH.
> Any suggestions for how to do this? I feel like something like
> $node->installed_command() or similar logic is need
Chapman Flack writes:
> On 12/03/21 14:12, Tom Lane wrote:
>> This reminds me of something I've been intending to bring up, which
>> is that the "char" type is not very encoding-safe. charout() for
>> example just regurgitates the single byte as-is.
> I wonder if maybe what to do about that lies
On 12/04/21 11:34, Tom Lane wrote:
> Chapman Flack writes:
>> "I am one byte of SQL_ASCII regardless of server setting".
>
> But it's not quite that. If we treated it as SQL_ASCII, we'd refuse
> to convert it to some other encoding unless the value passes encoding
> verification, which is exactl
On 12/03/21 20:22, Tom Lane wrote:
> Seems kinda dangerous to me ...
>
>> AtEOSubXact_SPI can free tuptables retail, but only in the rollback case.
>
> ... precisely because of that. If you wanted to take control of
> the TupTable, you'd really need to unhook it from the SPI context's
> tuptable
On Tue, Nov 16, 2021 at 09:41:58AM -0500, Robert Haas wrote:
> Maybe I'm not understanding you properly here, but it seems like you
> might be forgetting that this is a local variable and thus every
> backend is going to have something different. In the startup process,
> it will be initialized by
On Fri, Dec 03, 2021 at 12:45:34PM -0500, Tom Lane wrote:
> I think it's fine as-is; good belt-and-suspenders-too programming.
> It's not like the extra check inside SysLogger_Start() is costly.
+1.
--
Michael
signature.asc
Description: PGP signature
On Fri, Dec 03, 2021 at 12:42:47PM -0500, Tom Lane wrote:
> On the whole I'd be inclined to leave it alone. Even if the reporting
> mechanisms aren't able to report these events today, maybe they'll
> be able to do so in future. The context of the stats collector
> process, in particular, seems l
I wonder why we're counting the number of dead tuples (or LP_DEAD stub
items) in the relation as a whole in ANALYZE's acquire_sample_rows()
function. Wouldn't it make more sense to focus on the "live vs dead
tuple properties" of heap pages that are not known to be all-visible
when we generate stati
